Shared publicly  - 
Sweet, a new Linux file system from Samsung that is faster than existing ones when running on flash storage devices, submitted in a clean, easy-to-apply manner.  This will be great for Android-based systems.
This is a new patch set for the f2fs file system. What is F2FS? ============= NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, have been widely being used for ranging from mob...
Fred Richards's profile photoVee Grig's profile photoFelipe Contreras's profile photoMichael Amadio's profile photo
Can't wait. :) I've been looking for something other than FAT on my SD cards and USB drives.
it does.. but it's puzzling then, because eMMC already wear levels etc etc...

ext4, but especially btrfs, will do really well on such hardware already.
Supposedly they tested it out, and benchmarks showed it was much faster than ext4 especially under android-like use cases (sqlite database accesses).  Hey, competition is good to have in this area :)
Don't get me wrong, there's plenty of room for yet another filesystem ;-)
+Arjan van de Ven Write amplification on ext4 on flash can be awful; perhaps that's what this filesystem is trying to avoid.  I don't see any tunables in the code for specifying things like eraseblock size and alignment, wonder if that's in the plan.
Disappointed - I thought the name of the filesystem was "sweet" because of how you started your post :)
It does let you choose between GC algorithms, which I guess means that you're supposed to pick the one that lines up best with what the FTL wants to do.
This seems just simply amazing
+Dave Quigley post review comments on the patches, I'm sure they would be glad to get them and work to address them.
+Je Saist it wasn't written by Samsung USA, but rather, a Korean team of Linux kernel developers at Samsung. The "From" name kind of gives that away :)
I'd love to spend time tuning ext and btrfs for this, but it definitely sounds cool.
Greg: I know, but the only G+ Samsung pages are Samsung Mobile, Samsung Mobile USA, Samsung USA, Samsung Support USA, Samsung Android, and Samsung Nederland. Or at least those are on the only pages that show up in Auto-complete when searching for Samsung. 

Samsung USA seems, so far, the best way to "notify" the Samsung Corporate PR reps. I could be wrong on that though. 
Hrm, need to find how to contact them to submit a few patches to the utils' buildsystem.
+Arjan van de Ven From the quick look of it, I would say it is optimized to minimize the ill effects of cheap flash management.
are there matching patches for e.g. uboot as well?
+Koen Kooi has the right question: can i boot it from uboot? if so, i'll throw it on some kirkwood systems this weekend and see what for!
+Arjan van de Ven The main reason for eMMC was that external SD cards run FAT on them, which is just awful for trying to access/update in a reliable way without making all writes synchronous slowing your phone to a crawl and thrashing your cards number of write cycles, even then, a battery outage can still hose you due to FATs lack of modern consistency mechanisms (logging,journaling, etc). So switching to a real FS (such as ext?fs) was necessary to keep android phones stable and not get bricked every time they suffer a power glitch. once your external cards were no longer compatible with other computers, it didn't make sense to keep them external when it cost more and didn't provide much user benefit.

Hopefully, this will mark the return of external SD cards on phones, a real, free, and open alternative to FAT is needed and this looks like it will fit the bill.
It is very nice when innovative companies invent things. Samsung > Apple


Also this filesystem with NOOP seems like just what I'm looking for. Well, as long as I don't need ionice.

looks very promising indeed ...

having not tried to build the code at this point, what is Android-specific about this FS? or do we just assume that mobile linux == Android these days?
This might be the filesystem +Arnd Bergmann was teasing about, based on a thesis he supervised.
+Aaron Seigo should work with any device running a Linux kernel including a desktop with SSD.
Where are the benchmarks comparing this to EXT4, on an SD card, on a cheap thumbdrive and on different SSD hard drives? How much performance do you get for how much wear on the flash?
+Anisse A. the f2fs file system is not based on the thesis, but it uses a lot of the identical concepts, developed independently. I have to review the code more deeply to see which different trade-offs they made.
Another good feature to have would be a sane filesystem-over-USB protocol.  Even SMB-over-USB would be better than MTP.
+Zeev Tarantov On actual SSDs I don't expect to see much benefit, but on cheap media it will be huge. Have a look at the device list on, anything that has at least "5" in the "# open AUs linear" column should work great with f2fs, much better than any of the existing Linux file systems. For media with smaller numbers (especially less than 3), it will still suck but there isn't much we can do about that.
+Shahidul Alam That was my initial impression but +Greg Kroah-Hartman reckons otherwise. Greg, could you explain where MS FAT fits in this scenario. How will fs2fs work under a windows context etc? Cheers.
+Franklin Nwankwo For interoperability with Windows machines, the filesystem code needs to be ported to Windows (that's a lot of work) and binaries compiled for x86, amd64, armv7 need to be signed by WHQL. Then you place the binaries and an auto-install script into a small FAT partition on each thumbdrive. Inserting the thumbdrive will install the drivers to mount the data partition. Any device that accepts removable media must be able to mount VFAT, at least for the foreseeable future, so manufacturers of such devices cannot avoid paying for VFAT patent licenses. Devices that don't need to mount removable media can avoid using FAT internally and can ship without any FAT support at all, thus avoiding the need for a license.
The much harder part is to get it accepted in the official SD standard. Right now, FAT16 and FAT32 are what all devices support because that's what the standard requires. ExFAT is not widely supported but is required for SDXC cards (larger than 32GB). If we want this to become pervasive, it needs to be freely available to any embedded OS used in mp3 players, cameras and phones, not just Linux and Windows, and there has to be a specification that can get referenced from the (future) SD card standards.
Not sure if Samsung wrote this with that scope. I think their immediate target is Android and maybe Tizen. With Android now only supporting MTP and moving away from removable SD cards, there is no need to get the filesystem directly supported in any OS.
It's very interesting, is there more material to read about it? Maybe its too early to have some benchmarks compared to performance of other file systems, particularly on android smartphones
ExFAT is only "required" on paper. MSFT pushed an update to artificially limit formatting FAT to 32 GB, but will still access formatted media written by other tools. The motivation (othet than lock-in) is filesizes > 4G, but not everyone cares.
+H. Peter Anvin Yes, but the paper has "you can't sell anything that calls itself an SDXC card unless it comes preformatted with exFAT" written on it.

It's true that those of us who ignore the filesystem that comes installed by default can change that, but that's never going to be significant.  It's very frustrating that we weren't able to protest the exFAT decision, or find a way to get a royalty-free license for users of it.
The other thing is that the SD 3.0 standard is actually written in a way that any performance guarantees that are advertised by the card only apply if the OS uses ExFAT on >32GB media /and/ tells the card exactly what the FS does all the time. The cards may e.g. handle block bitmaps in a different way from directory entries based on those request annotations. Using any other FS means the card cannot benefit from optimizations that were put into its firmware. Even using a user-space ExFAT FUSE module will lose the annotations because the block layer doesn't know how to pass them through.
Pretty lame :( Looked at the commit... not a single design document to be seen. We already have an endless pile of crap undocumented file systems in the open source. Who cares about a file system where the only documentation is the kernel specific implementation.

This might actually be the greatest file system ever invented and the lack of documentation is enough to say "screw it!".
+Chris Ball this is then an excellent opportunity to drop another useless source of licensing fees, the required proprietary encryption needed to call yourself a secure digital card. Just create a standard that is fully compatible with sd but without the exfat and crypto requirements and their fees. Give it a fancy name, have a big company support it. Sdxc cards will be compatible with it and in practice they will be compatible with Sdxc cards for most purposes. They may just need to be formatted by the device if they come unformatted.
Lets welcome this 'OPEN' approach from Samsung...
Have they made the actual patches freely available yet?
Saweet.  I have the patches compiled into a kernel on a kvm guest.  It's kinda a bizarro machine, slackware 13.37 userspace with a 3.6.1-ARCH kernel.  The first and last patch didn't want to work cleanly, I didn't really care about #1 and added 16 by hand.  I'm thinking of sometime later this week, taking a 16gb usb flash drive and passing through to the guest... see how it performs.
"log structure file system approach" - does this mean native snapshots, like WAFL? That would be useful for non-phone devices as well.
If anyone wants to play with f2fs and Puppy Linux I have it working well and wrote a little gtkdialog gui to facilitate easy installation to usb flash media. You can even multiboot the stick with other Puppy OS that support f2fs if you install syslinux-4.0.3 from the Puppy Package Manager. Also included is GParted-14.1 patched for f2fs from the Parted Magic developers.
More info: PHATSlacko Puppy. :)
Add a comment...