Treatise on Formatting FLASH Storage Devices

[david at lang.hm]

On Wed, 4 Feb 2009, david at lang.hm wrote:

> On Wed, 4 Feb 2009, Benjamin M. Schwartz wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> Umm, what?
>>
>> "To alleviate the "wear out" problems, the FTL must move data around so
>> that repeated writes to a given sector don't cause too many writes to the
>> same NAND page."
>>
>> "UBIFS was designed to work on top of raw flash, which has nothing to do
>> with block devices. This is why UBIFS does not work on MMC cards and the
>> like - they look like block devices to the outside world because they
>> implement FTL (Flash Translation Layer) support in hardware, which simply
>> speaking emulates a block device"
>
> so if the device is performing wear leveling, then the fact that your FAT
> is on the same eraseblock as your partition table should not matter in the
> least, since the wear leveling will avoid stressing any particlar part of
> the flash.
>
> as such I see no point in worrying about the partition table being on the
> same eraseblock as a frequently written item.
>
> as for the block boundry not being an eraseblock boundry if the partition
> starts at block 1
>
> if you use 1k blocks and have 256k eraseblocks, then 1 out of every 256
> writes will generate two erases instead of one
>
> worst case is you use 4k blocks and have 128k eraseblocks, at which point
> 1 out of every 32 writes will generate two erases instead of one.
>
> to use the intel terminology, these result in write amplification factors
> of approximatly 1.005 and 1.03 respectivly.
>
> neither of these qualify as a 'flash killer' in my mind.
>
> now, if a FAT or superblock happens to span an eraseblock, then you will
> have a much more significant issue, but nothing that is said in this
> document refers to this problem (and in fact, it indicates that things
> like this follow the start of the partition very closely, which implies
> that unless the partition starts very close to the end of an eraseblock
> it's highly unlikely that these will span eraseblocks)
>
> so I still see this as crying wolf.

A far more significant problem would be the use of a journal on flash. 
since there are generally two writes to the journal for every write to the 
storage (one write to put the data in the journal and one write to mark 
the journal entry as completed), and frequently each write to the journal 
gets pushed out immediatly (rather than waiting to consolodate writes) for 
safety, the journal gets _far_ more writes than anything else on the 
storage device.

so using a full journaling filesystem (ext3 with data=journaled for 
example) would produce a write amplification factor of at least 3.

David Lang

> as for ubifs, that is designed for when you have access to the raw flash,
> which is not the case for any device where you have a flash translation
> layer in place, so it is really only useful on embedded system, not on
> commercially available flash drives of any type.
>
>> As for the author only being familiar with FAT, that is hilarious.  Mitch
>> implemented JFFS2 support in OFW, and wrote this page to explain how he
>> produced optimal ext2 formatting of FTL FLASH.  Indeed, that is the
>> subject of
>> http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device#Screwed-Up_Formatting
>
> I didn't read carefully enough before I made that comment. my apologies.
>
> David Lang
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>