f2fs – Flash File System – Is A Disk Hog

There is a file system that is more “Flash Memory Friendly” for use on things like SSD drives and uSD cards. It is named f2fs on Linux.

I won’t go into how it works other than to say it tries to reduce how often blocks are re-written on flash memory so that it doesn’t wear it out.

I installed it on Devuan (or Debian) with:

apt-get install f2fs-tools

Then used gparted to create an f2fs partition on the uSD card on the Odroid XU4. (This is running the system I made via grafting Devuan UserLand onto an Ubuntu kernel and boot process).

I saved the Ubuntu firmware, and kernel modules into partitions named:

Filesystem    1K-blocks    Used Available Use% Mounted on
/dev/mmcblk1p3   999320  531548    415344  57% /Ub/firmware
/dev/mmcblk1p5   999320   55932    890960   6% /Ub/modules

So that I could then copy them back into the Devuan image and boot the /boot image of the kernel from Ubuntu, it would find the expected modules and firmware, and all would be good. It worked.

But now I thought “Hey, I don’t need those partitions as a staging / saving area anymore, I can play with them”. And proceed to make “big enough” (I thought) f2fs replacements.

Well, I made /f2/modules about 100 MB that was almost double the 53 MB used, figuring that would be plenty. It wasn’t. During the copy, I got “out of space” errors.

OK… Deleted the f2fs partitions, remade /f2/modules as about another double in size, and did the copy again:

Filesystem    1K-blocks    Used Available Use% Mounted on
/dev/mmcblk1p5   999320   55932    890960   6% /Ub/modules
/dev/mmcblk1p7   210944  139616     71328  67% /f2/modules

So a measured 54 MB of data that takes 56 MB of ext3 space, now occupies 139 MB of flash space. That’s more than double.

I’m going to copy /Ub/Firmware next and see if it more than doubles too. Files are stored in “blocks”, and a file of, say, 100 bytes, will take one whole block. Originally these were 512 bytes minimum, and up to 4k. Over time, the minimum has moved to 1k, and in some cases 4k bytes. This makes it more efficient to retrieve large files (fewer blocks, seeks, reads) but less efficient at storing a lot of very small files.

It is possible that the f2fs file system just uses a Very Large Block size. Potentially it tries to match it to the Flash Block Size that IIRC is often 16k bytes. That would make sense since only whole blocks are read / written at once; so limiting it to one item of data would reduce “read / modify / write” operations on that block. (IF, for example, 4 Linux 4k blocks mapped onto 1 16k flash block, then change any one of those four and the whole 16k block gets read, modified, re-written).

In that case, really LARGE files will not show this “bloat” issue, but lots of little files will.

Note that file fragments can also cause some of this, though to a lower degree. Say you have a 12.8 K file and write it to 4 K blocks. 3 x 4 or 12 K of the file will fill blocks, but the 0.8 K will be left. It will be stuck, as a fragment, into a 4 K block, leaving 3.2 K of empty space in that block.

In prior decades folks would specify a ‘fragment’ size smaller than the block size (essentially 2 different block sizes) so that less space was wasted. You could have a 4 K block / 512 Fragment, and the leftover 0.8 K would be put in a 512 byte sized space wasting less. This has become less common as storage has become much larger and cheaper. I suspect this is not being done on Flash and it is aligning all writes to full flash blocks.

Doing the same thing on the /lib/firmware contents (saved into /Ub/firmware) also grew in size, but not nearly as much. IIRC it has more files of large size in it:

Filesystem    1K-blocks    Used Available Use% Mounted on
/dev/mmcblk1p3   999320  531548    415344  57% /Ub/firmware
/dev/mmcblk1p8   831488  673620    157868  82% /f2/firmware

So “only” from 531 MB to 673 MB. A “mere” 27% larger.

Which I think confirms the notion that this is an issue of block size / fragment size being very large.

Conclusion

The key takeaway here is that if you are going to move some file system from ext to f2fs, do a trial copy first to see how much space expansion is going to happen, then size your final target file system.

Because “reasonable” guesses of “about the same” are not likely to succeed.

Does the “wasted space” matter? Depends on how big your Flash device is and how much you care about reducing wear on it. Also on how many small files your system / directory has in it, so how much is wasted. Measuring is your friend here.

Subscribe to feed