I just read [0] and have some notes and questions to share. [0] http://elinux.org/images/b/b6/EMMC-SSD_File_System_Tuning_Methodology_v1.0.p... Questions: - the FTL is opaque to the user and the OS. Where can I find a mapping of make/models to FTLs? For SSDs that would be the make/model of the SSD, but for SD I believe the FTL is implemented in the reader, not in the SD card. Where can I find honest (i.e. independent) analysis of FTL metrics? - Max claims bonnie++'s functionality is superseded by fio. Russell, you maintain bonnie++, right? What's your opinion of fio? Notes: - p 9 flashbench helps you guess the erase block size. - pp 10-12 lists fs and scheduler optimization knobs. - p 13 btrfs likes -o ssd if device speaks TRIM. ext4 likes noatime/nojournal, CFQ and discard. CFQ is best for most things, then ROW. - p 23 optimal configuration differs between device make/model. optimzation helps r/w loads more than r/o or w/o loads. - p 26 avoid btrfs/f2fs if OS can be reset by unscheduled power outage or hardware watchdog, unless you have a BBU or similar. ext4 survives many more outages than btrfs/f2fs.
On 11/07/13 13:54, Trent W. Buck wrote:
Questions:
For SSDs that would be the make/model of the SSD, but for SD I believe the FTL is implemented in the reader, not in the SD card.
I'm not sure it could be implemented in the reader for SD cards, since the SD cards usually do internal wear levelling. (And I don't think the levelling is in the spec. I mean, it's not a standardised algorithm, but varies between manufacturers.)
- p 26 avoid btrfs/f2fs if OS can be reset by unscheduled power outage or hardware watchdog, unless you have a BBU or similar. ext4 survives many more outages than btrfs/f2fs.
Really? You had them suggesting using nojournal for ext4 just above, but now saying btrfs is less resilient. That's a rather surprising outcome. I would have thought btrfs's copy-on-write system would come out as much safer than ext4 w/out a journal!
On Thu, 11 Jul 2013, "Trent W. Buck" <trentbuck@gmail.com> wrote:
- Max claims bonnie++'s functionality is superseded by fio. Russell, you maintain bonnie++, right? What's your opinion of fio?
Lots of people claim to have superceded Bonnie++/Bonnie. The way you recognise success in free software development is when everyone else claims to have developed something better. Fio appears to have a good feature set. But Bonnie++ is still good for simple tests. For more serious tests I prefer Postal, mail delivery really stresses a system.
- p 13 btrfs likes -o ssd if device speaks TRIM.
No, there's -o discard for BTRFS if you want to use TRIM. I tried it and performance sucked badly, that seems to be the common experience. The ssd option doesn't enable TRIM, it does other things.
ext4 likes noatime/nojournal, CFQ and discard. CFQ is best for most things, then ROW.
Noatime is equally good for all filesystems. I expect that the discard option on ext4 would have some similar performance issues to the same option on BTRFS.
- p 26 avoid btrfs/f2fs if OS can be reset by unscheduled power outage or hardware watchdog, unless you have a BBU or similar. ext4 survives many more outages than btrfs/f2fs.
If you can reproduce a situation where a device commits all data that it claims to have committed and BTRFS has a problem with a power failure then that would be a bug and I'm sure that the developers would make fixing it a priority. The BTRFS developers seem to be good about making their filesystem robust. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
participants (3)
-
Russell Coker -
Toby Corkindale -
trentbuck＠gmail.com