| |||||||||||||
An f2fs teardownAn f2fs teardownPosted Oct 11, 2012 19:16 UTC (Thu) by skitching (subscriber, #36856)Parent article: An f2fs teardown
Thanks for the great analysis Neil.
Unfortunately, it is sad to see that f2fs is *so* coupled to an underlying FTL. I presume that where you say "leaves it to the FTL", this means that f2fs is simply rewriting data at a fixed address, and relying on the FTL to relocate that address to perform wear-leveling. And given that flash is supposed to be efficient at random writes (in units of an erase block) it is a shame that f2fs spendsg so much effort grouping writes into larger operations to help the FTL layer perform.
So we have a choice of filesystems that only work well on "raw" flash (jffs2, ubifs, logfs) or a filesystem that only works well on managed flash (f2fs).
AIUI, FTL is a solution invented to make it possible to put filesystems like FAT32 onto a flash device without quickly killing it. Are we really still going to be stuck with FTL decades from now?
If the industry is going to provide a "raw" interface to removable flash media in the near future, then f2fs will only be a short-term solution, yes? And interestingly, Samsung are exactly the people who could get a "raw flash interface" happening...
(Log in to post comments)
An f2fs teardown Posted Oct 11, 2012 21:11 UTC (Thu) by arnd (subscriber, #8866) [Link]
A few replies to each of your comments:
* Wear leveling usually works by having a pool of available erase blocks in the drive. When you write to a new location, the drive takes on block out of that pool and writes the data there. When the drive thinks you are done writing to one block, it cleans up any partially written data and puts a different block back into the pool.
* f2fs tries to group writes into larger operations of at least page size (16KB or more) to be efficient, current FTLs are horribly bad at 4KB page size writes. It also tries to fill erase blocks (multiples of 2MB) in the order that the devices can handle.
* logfs actually works on block devices but hasn't been actively worked on over the last few years. f2fs also promises better performance by using only 6 erase blocks concurrently rather than 12 in the case of logfs. A lot of the underlying principles are the same though.
* The "industry" is moving away from raw flash interfaces towards eMMC and related technologies (UFS, SD, ...). We are not going back to raw flash any time soon, which is unfortunate for a number of reasons but also has a few significant advantages. Having the FTL take care of bad block management and wear leveling is one such advantage, at least if they get it right.
An f2fs teardown Posted Oct 16, 2012 21:01 UTC (Tue) by travelsn (guest, #48694) [Link] But are there processor out there that can boot from FTL enabled flash don't we still need raw NAND for boot device?
An f2fs teardown Posted Oct 16, 2012 23:53 UTC (Tue) by neilbrown (subscriber, #359) [Link]
> But are there processor out there that can boot from FTL enabled flash
The OMAP3 in my phone boots from the micro-SD card. It reads from the blocks that a file would be stored in if it were the first file copied onto a newly formated VFAT partition (it doesn't parse the FAT, it just *knows* what to read).
So yes: processors can boot from all sorts of things.
An f2fs teardown Posted Oct 17, 2012 12:14 UTC (Wed) by etienne (subscriber, #25256) [Link]
> So yes: processors can boot from all sorts of things.
In fact OMAP3 boots from an internal ROM and can chain-load other boot device.
An f2fs teardown Posted Dec 22, 2012 22:38 UTC (Sat) by marcH (subscriber, #57642) [Link]
> It reads from the blocks that a file would be stored in if it were the first file copied onto a newly formated VFAT partition (it doesn't parse the FAT, it just *knows* what to read).
To avoid this kludge, starting from version 4.3 e-MMC chips feature two 128K boot partitions with a simplified access procedure: simplified for ROMs.
JEDEC specifications are free (registration required)
An f2fs teardown Posted Oct 11, 2012 21:15 UTC (Thu) by neilbrown (subscriber, #359) [Link]
One point that I didn't emphasise in the article, and maybe should have, is that those locations where f2fs writes to fixed addresses are all at the start of the device, the same region that a FAT filesystems uses for the "FAT" (File Allocation Table).
As the FAT is also updated by writes to fixed addresses, that part of the device is often optimised for that sort of access pattern.
So if you manage to align the "meta" area to the "fat"-dedicated area, and align the sections and zones as already described, f2fs should be fully optimised for the device.
As for whether we'll be stuck with FTL for decades: that is really a question of economics. For a better product to appear, there needs to be a big enough market.
|
|||||||||||||