| |||||||||||||
An f2fs teardownAn f2fs teardownPosted Oct 12, 2012 16:06 UTC (Fri) by Aissen (subscriber, #59976)In reply to: An f2fs teardown by cmccabe Parent article: An f2fs teardown
I'm not sure the primary usage is to prevent the "FAT" tax. Sure, it could be useful on SD cards to replace exFAT. But I think the primary goal is to replace ext4 for eMMCs embedded in smartphones (and tablets, or any other smart device). This limitation could then make (a little bit) sense. With current technology we have 64GB eMMCs, with 128GB in the pipes. With capacity doubling every 2 years, it would take ~15 years to reach the filesystem limit. Let's hope that by then non volatile memory use will be pervasive.
The thing I don't understand, is why work isn't done to make btrfs fit this use case. It already has less write amplification than ext4 or xfs due to it's COW nature (I think Arnd Bergmann did some research on that). It would use the years of experience and higher performance of btrfs (vs a newly developed filesystem). It would also fit the Linux philosophy of running on anything from the tiniest devices to TOP500 computers.
Is it because btrfs as a high CPU overhead ? Consumes lots of disk space ? Or just because every btrfs developer is working on "big data" server-side use cases ?
(Log in to post comments)
An f2fs teardown Posted Oct 14, 2012 18:38 UTC (Sun) by cmccabe (guest, #60281) [Link]
> The thing I don't understand, is why work isn't
> done to make btrfs fit this use case. It already > has less write amplification than ext4 or xfs > due to it's COW nature (I think Arnd Bergmann > did some research on that).
It's not obvious that btrfs is the best choice for SSDs. Ted T'so posted some information on this earlier: http://lwn.net/Articles/470553/
There is currently some work going into btrfs to make it a better match for SSDs. That would probably make an interesting LWN article of its own. Also keep in mind that the type of SSD you see on a desktop is much different than what you see in a mobile phone. The firmware is much fancier and so an optimization for one may be a pessimization for the other.
An f2fs teardown Posted Oct 15, 2012 8:18 UTC (Mon) by Aissen (subscriber, #59976) [Link]
In the link you point to (very interesting BTW), Ted says that btrfs will be at a disadvantage in "fsync()-happy workload"s. So it varies between workloads.
I didn't use the work "SSD", and that's because (as you said) it might refer to different things. I talked about eMMCs and SD cards, which are the target use case of f2fs, and used in mobile phones.
An f2fs teardown Posted Oct 17, 2012 14:26 UTC (Wed) by arnd (subscriber, #8866) [Link]
I believe btrfs has improved significantly in this area, but its design means that it won't be as good as f2fs on the media that f2fs optimizes for. The issue with b-tree updates that Ted mentions in the link is something that f2fs avoids by having another level of indirection that is not copy-on-write, and btrfs suffers more from fragmentation because it intentionally does not garbage-collect.
On a lot of flash devices, btrfs starts out significantly faster than ext4 after a fresh mkfs, but it's possible that btrfs performance degrades more as the file system fragments with aging. I don't have any data to back that up though.
An f2fs teardown Posted Nov 16, 2012 15:33 UTC (Fri) by oak (subscriber, #2786) [Link]
Nobody mentioned compression, but I think BTRFS can use e.g. LZO compression. What's the situation with that?
|
|||||||||||||