A flash filesystem tuning guide

[Posted July 2, 2013 by corbet]

From:		"Bird, Tim" <Tim.Bird-/MT0OVThwyLZJqsBc5GL+g-AT-public.gmane.org>
To:		"celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l-AT-public.gmane.org" <celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l-AT-public.gmane.org>
Subject:		Flash File system Tuning Guide - available now
Date:		Mon, 1 Jul 2013 20:33:17 +0200
Message-ID:		<E12ED16DF2DF754897A674F2B0E8F6C44292B3102A@seldmbx01.corpusers.net>

I am happy to announce the availability of a document describing methods
of tuning Linux filesystems for eMMC/SDD-based block devices.

This is the culmination of several months of effort, to determine the results
of using different tuning options in the Linux kernel, with different filesystems
running on flash-based block devices.  The document was prepared by
Cogent Embedded, and funded by the CE Workgroup of the Linux Foundation.
In addition to describing different tuning options available, the document 
also gives methodologies for measuring performance on the filesystems
and has extensive graphs showing the results of the different tuning
options.


The work is available on the elinux wiki at (direct doc link):
http://elinux.org/images/b/b6/EMMC-SSD_File_System_Tuning...

It is linked to from the File_Systems page of the elinux.org wiki site, in the
comparison of flash filesystems section:
http://elinux.org/File_Systems#Comparison_of_flash_filesy... 

Please see the sub-section entitled "Cogent Embedded Tests (2013)"

It is hoped that this document will provide valuable insights into the different
options available to tune a Linux filesystem for flash-based devices, as
well as give a comparison of block-based filesystems used on such devices.

Regards,
 -- Tim Bird

Architecture Group Chair, CE Workgroup
Senior Software Engineer, Sony Mobile

A flash filesystem tuning guide

Posted Jul 2, 2013 15:37 UTC (Tue) by ibukanov (subscriber, #3942) [Link] (3 responses)

Very nice benchmarking! The results simulating power failure are rather depressing - among ext4, btrfs and f2fs only ext4 was able to recover. Perhaps it indicate that Samsung (company behind f2fs) is going to stop producing devices with removable batteries...

A flash filesystem tuning guide

Posted Jul 3, 2013 3:32 UTC (Wed) by alankila (guest, #47141) [Link] (2 responses)

I wish the recovery attempt had been done with mount -o recovery, apparently it can fix things the fsck can't.

A flash filesystem tuning guide

Posted Jul 3, 2013 5:03 UTC (Wed) by Darkmere (subscriber, #53695) [Link] (1 responses)

I believe its unfeasible to mount with special options after a power loss. And I think there's a general rule that you shouldn't use -o recovery for day-to-day business.

A flash filesystem tuning guide

Posted Jul 3, 2013 8:46 UTC (Wed) by sionescu (subscriber, #59410) [Link]

Do you have a reference for such a rule ? I've been using -o recovery by default without noticeable issues.

A flash filesystem tuning guide

Posted Jul 2, 2013 17:24 UTC (Tue) by karim (subscriber, #114) [Link] (2 responses)

This is most certainly welcomed. However, I was most looking forward to test results for SSD wear measurements because that's where the problems really lie :/

A flash filesystem tuning guide

Posted Jul 3, 2013 3:35 UTC (Wed) by alankila (guest, #47141) [Link] (1 responses)

Why do you say that?

Isn't the data generally written once, and it is usually much larger part of the writes landing on a device? To the tune of 100:1 or so?

A flash filesystem tuning guide

Posted Jul 3, 2013 13:17 UTC (Wed) by karim (subscriber, #114) [Link]

My experience (and that of people I work with) is that SSD performance degrades over time, sometimes severally. There is, however, no study that I've found that quantifies/qualifies this degradation.

A flash filesystem tuning guide

Posted Jul 3, 2013 2:49 UTC (Wed) by pabs (subscriber, #43278) [Link] (1 responses)

each medium has its own performance profile.

I wonder if distro installers should use their tools to determine the right filesystem/parameters to use during installation.

A flash filesystem tuning guide

Posted Jul 3, 2013 3:45 UTC (Wed) by alankila (guest, #47141) [Link]

The mediums in question were apparently SD cards which are hardware-wise much simpler than, say, SSDs. Typical SSD performance is close to the raw flash chip data rate for random and sequential read/write loads.

I can't say that I would recommend using Linux installation from a SD card. I've experienced data loss just from suspending and resuming a laptop. My *guess* is that in my case, the suspend cut power from the SD card controller while the card is internally still doing something after the last write, perhaps mid-GC cycle. Where I expected my data to be, there were chunks of it and runs of 2 MB of zeroes scattered around.

Btrfs Power-Fail Tolerance

Posted Jul 3, 2013 8:27 UTC (Wed) by nirbheek (subscriber, #54111) [Link] (2 responses)

The test for power-fail tolerance on Btrfs (Section 5.2.2) is suspect. Their criteria for corruption seems to be whether `fsck` finds errors, not whether files were corrupted on-disk.

Btrfs's fsck is distinct from traditional fsck tools, and is not meant to be used at boot time to check for consistency. AFAIK, it will warn on inconsistencies that would be automatically corrected when the filesystem would get mounted, and seeing `btrfsck` errors after a dirty reboot is expected behaviour.

If my understanding is correct, then that section needs to be revised.

Btrfs Power-Fail Tolerance

Posted Jul 3, 2013 11:04 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (1 responses)

The authors write that

"fsck finds errors which it is not able to auto-recover"

Is it the case that when Btrfs's fsck warns "on inconsistencies that would be automatically corrected [if you hadn't run fsck]" it requires manual confirmation from the user? If so what's the justification for this bizarre design choice?

If not, then the authors have done exactly as they said, detecting situations where auto-recovery isn't possible. For all but the most technical users a single prompt asking some low-level jargon based question like e.g.

"Bazingle nerrubishment fondangoloro 564600? Y/n?"

is enough for them to conclude that all their data is forfeit and they'll need to start over (hopefully from a backup, if they kept backups) unless somebody technical is available to help them push the enter key and see what happens next. A filesystem or filesystem configuration that's _more likely_ to cause these failures will result in more warranty calls, less customer satisfaction and higher costs, so it's bad, even if it's technically very clever indeed.

Btrfs Power-Fail Tolerance

Posted Jul 3, 2013 16:51 UTC (Wed) by Thom (guest, #73471) [Link]

From the btrfs wiki, "The btrfsck tool in the git master branch for btrfs-progs is now capable of repairing some types of filesystem breakage. It is not well-tested in real-life situations yet."

This paper touches on the important points for an embedded file system - it seems to me that btrfs is more of a desktop or server alternative. For embedded use, protecting file system metadata and allowing drives to mount is quite important in "real-life situations".