Defragmentation: Revisited


I spoke about Defragmentation of an exFAT volume.

In my write-up I made a statement that FLASH and SD Media should not be defragmented.

I’m seeing many other blog posts and articles that are actually saying the same thing – and for the same reasons. It even goes further to also include other forms of solid state drives, such as SSD. One of the main reasons why exFAT is considered “flash” friendly is that sine the life a a NAND gate is finite, you should not write unless you have to. That is why the FAT is not used or updated unless actually needed.

 

So, keep in mind the issue of defragmenting an exFAT volume should take into consideration the actual media below the file system. The primary reason/benefit for a defrag is to put data together to reduce the Seek and Latency portions of an I/O, which take forever compared to the actual read/write operation. These are physical components that slow down the I/O. When media, such as flash, is completely electronic, those physical components drop out of the equation and I/O speed should not improve after a defrag.

Another note, is that if you format the media a lot, which is good to rebuild the file system structures, do quick formats and not full or “wipe” formats. A wipe is going to write to all the memory and that could wear it down. Of course, when you d a quick format, any data on the media can be recovered forensically, so wipes may be necessary if you really need to make sure the data is physically destroyed and “wiped out”.

exFAT OEM Parms and the GUID


In my former post https://rshullic.wordpress.com/2010/01/08/sample-c-program-to-parse-out-the-exfat-directory-structure/ where I provided a crude program to parse out the exFAT filesystem I started the definitions with OEM Parameters.

 

In searching for the structure again, I found a copy at http://technet.microsoft.com/de-de/office/ee490605 and it also shows up at other sites today.

One interesting statement is: #define OEM_FLASH_PARAMETER_GUID 0A0C7E46-3399-4021-90C8-FA6D389C4BA2

Now, when I was doing my research back in 2009, I did not have flash memory, did not have Windows CE, and even when the SDXC card came it on 2010, was not able to afford one.

But, a couple of weeks ago I bought two SANDISK 64GB SDXC Media cards and started to browse them using WinHex. Now the OEM Parameters are in a section of the VBR, after the MEBS.

The Main Boot Region of the VBR is composed of five sub-regions of a total of 12 sectors:

  • The Main Boot Sector (MBS)
  • The Main Extended Boot Sectors (MEBS)
  • The OEM Parameters
  • A reserved sector
  • The Checksum Sector

Although the OEM Parameters are defined, they are not being used by the desktop/server exFAT driver. Because of this, until I got my hands on the SDXC card, the OEM PARMS VBR record has always been empty for my research. Then, then I browsed the SDXC card, I came up with one entry with the following GUID:

467EC0C0A99332140 C890FA6D389C4BA2

So, I contacted SANDISK and asked them for the format of this GUID because if you look at the structure, and you look at the WinHex dump, there was only one value, it looked like a big value. Also, when I searched, I could find anything.

SANDISK cam back with an interesting response, which was essentially that this confidential information and they can’t tell me.

Well, sorry SANDISK, if it was confidential, it isn’t anymore.

But, if you are doing research, here is something you may need to know:

Part of the GUID is little endian, and part is not. That is why I could not find it on a search. I had read this somewhere else as well, but I thought I’d mention it here.

The proper notation for the GUID is 5 sections, where the first 4 are little endian, and the last is a string.

{0A0C7E46-3399-4021-90C8-FA6D389C4BA2}If you compare it to the number above, you will see what is reversed and what is not.