Optimizing Linux with cheap flash drives

Posted Feb 19, 2011 21:03 UTC (Sat) by arnd (subscriber, #8866)
In reply to: Optimizing Linux with cheap flash drives by willy
Parent article: Optimizing Linux with cheap flash drives

The NVMHCI concept (thanks for the Link!) makes a lot of sense at the high end where the drives can be smart enough to do a good job at providing high performance and low wear.

However, at the low end that I looked at, most drives get everything wrong to start with: there is too little RAM and processing power to do the reordering that would be needed for ideal NAND access patterns, the drives only do dynamic wear leveling, if any, so they break down more quickly than necessary.
The way that the SD card association deals with the problem is to declare all file systems other than FAT32 (with 32KB clusters) unsupported.

What we'd instead need for these devices is indeed a way to be smarter in the host about what it's doing. The block discard a.k.a. trim logic is one example of this that sometimes works already, but is not really enough to work with dumb controllers. What I'd like to see is an abstraction on segment level, using commands like "open this segment for sequential writes", "garbage-collect this segment now", "report status of currently open segments", "how often has this segment been erased?".

Optimizing Linux with cheap flash drives

Posted Feb 19, 2011 22:40 UTC (Sat) by willy (subscriber, #9762) [Link] (1 responses)

Yes, these are quite different devices ... I would estimate a factor of 100+ difference in price, and probably similar factors in terms of capacity, speed, power, etc, etc.

The API you're suggesting makes a ton of sense for the low end devices. I don't think there's a whelk's chance in a supernova of it coming to anything, though. You'd need the SD association to require it, and I can't see it being in the interest of any of their members. When the reaction to "hey, your cards suck for this other filesystem" is "your filesystem is wrong", I can't see them being enthusiastic about something this radical.

I do see that Intel are members. I'll try to find out internally if something like this could fly.

Optimizing Linux with cheap flash drives

Posted Nov 21, 2016 8:57 UTC (Mon) by Hi-Angel (guest, #110915) [Link]

Did you find?

Optimizing Linux with cheap flash drives

Posted Feb 20, 2011 3:25 UTC (Sun) by Oddscurity (guest, #46851) [Link] (3 responses)

So in summary, if I want to run an ext3 filesystem on a USB stick, I'm better off formatting the stick as FAT32 and then running the ext3 as a loop?

Or would that be the wrong conclusion?

Not that it's all I took away from this great article, but I'm wondering what I can do in the meantime to optimise my use with such devices.

Optimizing Linux with cheap flash drives

Posted Feb 20, 2011 4:07 UTC (Sun) by ewen (subscriber, #4772) [Link] (2 responses)

Alas, no, running ext3 in a loop on FAT32 doesn't magically change your file system access patterns from ext3 access patterns to FAT access patterns. (Eg, in that scenario the FAT would hardly ever change since you allocate a huge file for the loop and then just write within it, versus native FAT32 with it changing with each file change, so the cheap flash drives optimisation for the 4MB holding the FAT would be wasted; and you'd still get random updates frequently in "unexpected" -- by the naive firmware -- locations.)

It appears if you want to run ext3 on a cheap flash drive, you pretty much have to assume that it's going to be slower than advertised (possibly MUCH slower, especially for write), and that there's a very real risk of wearing out some areas of the flash faster than might be expected. Probably okay for a mostly-read workload if you ensure that you turn off atime completely (or every read is also a write!), but not ideal for something with regular writes.

If it's an option for your use case, then sticking with the original FAT file system -- and using it natively -- is probably the least bad option. Certainly that's what I do with all my portable drives that see any kind of regular updates. (It also has the benefit that I don't have to worry about drivers for the file system on any system I might plug it into.)

Ewen

Optimizing Linux with cheap flash drives

Posted Feb 20, 2011 14:11 UTC (Sun) by Oddscurity (guest, #46851) [Link]

Thanks for the comprehensive answer.

I may as well switch to just FAT32 for part of the use cases and the other ones are dominated by reads, so can stay on ext.

Optimizing Linux with cheap flash drives

Posted Nov 21, 2016 9:10 UTC (Mon) by Hi-Angel (guest, #110915) [Link]

I disagree, I think the best one can do is to dump offsets/cluster sizes that in use by the original FAT, and then to use them for formatting in a EXT. More over, one need to do it even for no intention of usage with other FS than FAT — because upon reformatting it's easy to get offsets wrong.

I'm wondering btw, why didn't the article have a chapter about finding out those sizes from the original FS. Last time I searched (½year ago), I only found people trying out timing attacks to the stick for that kind of things, though getting info for FS just after the stick bought would be way simpler. I'll check it out, perhaps below in comments someone mentioned it.