F2fs file system to use or not. Moving from HDD to SSD and F2FS
Among modders and Android enthusiasts, as in any sect, there are several shrines that are customary to revere no matter what. These are optimized custom kernels, scripts and applications for system optimization, sound "improvers" and much more. Recently, the F2FS file system has been added to them, which, according to many testimonies, significantly raises the performance of working with NADN memory and saves it from wear and tear. But is it really so?
Start
F2FS (Flash Friendly File System) first appeared in the public eye in October 2012, when Samsung published patches with its implementation for the Linux kernel. According to the developers, the FS was designed from scratch specifically for flash memory and made it possible to increase the read / write performance of such drives and use their features for some optimizations and wear protection.
By the end of the year, F2FS became an official part of Linux 3.8, and some time later its support appeared in CyanogenMod 10.2 and TWRP custom recovery. Since then, modders and optimizers include it in all their custom kernels, write a lot of laudatory reviews, publish screenshots with proof of the phenomenal performance of the file system.
From the outside, all this looks more than encouraging, so newcomers to Android unanimously join the ranks of those who have touched the beauty and have this beauty in their smartphone. But few people think about why Samsung, which gave birth to a miracle, does not use F2FS even in its latest flagships.
And the reason is simple: F2FS is practically no better than the default ext4 file system used in Android. In order not to be unfounded, I will analyze two main myths regarding F2FS: performance and respect for flash drives.
Performance
There are plenty of examples on the web comparing ext4 and F2FS performance. They are very similar and very often show a huge gain of the latter in data writing speed. For example, here are the AndroBench comparison results for the Sony Experia Z1 smartphone:
 |
Looks weird, doesn't it? Random write speed has increased by 150 times compared to ext4 and six times compared to read speed. For the first time, Phoronix journalists noticed such an anomaly when they tested F2FS in early 2013:
Then they reasonably assumed that in fact F2FS does not write data to disk immediately, but instead caches them for later writing. If you look at the F2FS architecture, it becomes obvious that this is indeed the case. F2FS works with data blocks of 4 KB, combining them into segments of 2 MB, and those, in turn, are combined into sections, which can be up to six pieces.
Why such a system is needed, we will talk later, but for now we will focus only on the fact that sections must be filled with blocks before being written to memory. In other words, F2FS collects the 4K blocks of data to be written into larger chunks and then flushes them to disk at the same time. This is the reason for the abnormally high performance of F2FS in the write speed of a random 4-kilobyte block and the performance of sequential writes of many blocks quite comparable to ext4.
Phoronix's latest tests also confirm that the performance of both file systems is almost equal. F2FS noticeably pulled ahead only in the test for simultaneous work with thousands of files, which is due to its internal optimizations. However, no smartphone works simultaneously with so many files. This situation is rare even on the desktop and is specific to servers.
Taking good care of your storage
The second misconception about F2FS is related to a more careful attitude to flash memory. We all know that flash memory is fragile and can withstand only a few thousand data write/erase cycles. For this reason, it is recommended to place data on a flash drive in a log format, when new blocks do not overwrite old ones, but instead are written to an unused area, after which the old block is marked as unused and subsequently cleared, freeing up space.
This is how F2FS works, which is why many people consider it a better choice for flash than ext4, which uses the classic in-place modification scheme. But there is one caveat. The fact is that absolutely any modern flash memory, from USB flash drives to server SSDs, contains an FTL (Flash Translation Layer) controller, which is responsible for presenting flash memory that is completely different from magnetic disks as a regular disk. , to which a certain number of blocks of data can be written.
In addition to things like combining multiple flash memory chips into a single "disk" and performing a TRIM operation that cleans up unused blocks, the FTL is also responsible for choosing the physical location of the block being written to in memory. And here he uses (surprise!) a log-structured mini-FS. In other words, any modern flash memory itself is engaged in increasing its service life, regardless of what file system you create on it: F2FS, ext4, FAT32 or any other, the result will be the same.
In fact, the reason why F2FS is called "flash friendly" (Flash Friendly) is not at all in respect for memory, but because it knows how to take into account some of its features in order to make working with memory more efficient. One example of increasing efficiency is the same mechanism for combining data into partitions.
The fact is that many flash memory chips include not one, but several independent drives. And writing to each of them can occur simultaneously. By combining data in sections, F2FS can send them for writing at the same time, which in theory will lead to an increase in write performance by a multiple of the number of drives.
But not everything is so simple here either. All F2FS optimizations require individual file system settings for each flash memory model. A file system will only be as efficient as it is fine tuned. And this should be done not by the user of custom firmware, but by the memory manufacturer himself, because as soon as he can know all the nuances of its device.
Total
F2FS is a great file system. This is evidenced at least by the fact that, only having been born, it is already able to successfully compete with ext4, which has been licked for years and hundreds of people. However, do not expect miracles from her and run to format your device. Yes, many people claim a noticeable increase in performance even without tests, but again, most likely, these effects are caused by the same lazy write mechanism and in fact there is no significant increase in speed.
Good afternoon. First, let's figure out what F2FS is and what it is for.
F2FS (Flash-Friendly File System) is a file system introduced in 2013, optimized for use on flash drives, including SSDs, memory cards, and memory chips built into various devices. In general, this is a file system that initially takes into account constant access time and a limited number of memory cell rewriting cycles, so its use is desirable.
Preparing the Device for File System Installation
Support for this file system has been included in the Linux kernel since version 3.8. In its raw form, CyanogenMOD does not allow the use of this file system, so it needs to be finished. But, fortunately, comrade dimfish has already done everything for us, and now we just have to install the operating system correctly. I immediately warn you that absolutely all data from the phone will be erased, so it’s better to think about all kinds of backups in advance (Google account for contacts, Titanium backup for the application and hands to extract important photos). If you have already saved everything important and are confident in the directness of your hands, then proceed. But I remind you that phone firmware is to some extent always a lottery, and only you are responsible for your phone. You can break it!
When writing the instructions, I had Paranoid Android installed, and I didn’t manage to install F2FS the first time, I did a factory reset, and after that the firmware got up like home. The only option for saving data is if you currently have a regular CM11. In this case, you need to make a backup / data, through TWRP, which is available below, and restore after installation. If you have any other ROM, including stock, restoring / data is not recommended.
Alexey Fedorchuk
Ubuntu’s passions, 06/12/2013
The f2fs file system (Flash-Friendly File System - “Flash-Friendly File System”) is designed specifically for placement on SSD and similar solid-state storage media. It is natively supported by the Linux kernel, starting with version 3.8.0 - the same one that is included with Ubuntu 13.04.
It is easy to verify the fundamental support of f2fs with the command
$ ls /lib/modules/3.8.0-23-generic/kernel/fs/f2fs
in the output of which we will see the module
However, it is not enabled by default. Therefore, you can try to load it in the usual way:
$ sudo modprobe f2fs
The attempt will be successful, as the command will inform us
$ lsmod | grep f2fs f2fs 109231 0
Interestingly, the output of the command
Dmesg | grep -i f2fs
will still be empty. And after the reboot, no hint of this module will be found. So you need to ensure that it is loaded manually at system startup. To do this, just add the line to the /etc/modules file
What can be done on behalf of the superuser either in a text editor or by a sequence of commands like
$ sudo -i $ echo f2fs >> /etc/modules $ exit
As you might guess, this achieves the mandatory loading of the corresponding module at the stage of system initialization.
However, there is little joy in supporting any file system in itself if there are no appropriate tools for working with it. And for working with f2fs, we don’t have them in Ubuntu yet.
However, obtaining this toolkit is not a great job. And it consists in checking the availability of the universe repository with the following command
sudo apt-get install f2fs-tools
However, the entire toolkit for working with f2fs is currently reduced to a single command - /sbin/mkfs.f2fs and related documentation - man (8) mkfs.f2fs .
Creating an f2fs on a partition or raw device is done in the usual way:
Mkfs.f2fs /dev/sdf1
in response to which the following output will follow:
F2FS-tools: Ver: 1.1.0 (29-Nov-2012) Info: sector size = 512 Info: total sectors = 30308319 (in 512bytes) Info: zone aligned segment0 blkaddr: 256 Info: This device doesn't support TRIM Info : format successful
The above example refers to a flash drive, which is why we also see a message about the lack of TRIM support - of course, it will not be on any modern SSD.
The mkfs.f2fs command has several options. One of them -l sets the label for the corresponding partition or device, which is very useful when using f2fs on removable media such as flash drives. The rest define the block allocation policy (-a), the size of the provisioning area (-o), the number of segments per partition (-s) and partitions per zone (-z). However, their effect is not documented anywhere, and I did not have the opportunity to experiment. So it remains to rely on the defaults, which, except for Aunt Mani, can also be viewed by giving the mkfs.f2fs command without an argument:
A heap-based allocation -o overprovision ratio -s # of segments per section -z # of sections per zone
After creating the f2fs file system, there is a natural desire to try it out. Why is it desirable to mount it somewhere. It is not automatically recognized by the system, despite the fact that the required module is loaded. That is, unlike other file systems on external media, by default it is not visible in file managers like Nautilus or Thunar.
However, this does not mean that partitions or devices with f2fs must be mounted by hand, and even more so from root. It is enough to create a mount point in the user's home directory (for example, $HOME/test) and enter the line in /etc/fstab
/dev/sdb1 $HOME/test f2fs user,noauto 0 0
Of course, do not forget to substitute the value of the $HOME variable and specify the name of the existing device. After that, the device with f2fs appears among the entry points of Nautilus or Thunar when it is connected (as a label - if one was set). This applies to removable media - for example, flash drives or SD cards. It is advisable to mount internal devices (SSD drives) in the usual way “on a permanent basis”.
Unfortunately, it is currently not possible to place the root of the file hierarchy on f2fs. The Ubuntu installer does not provide this option. And "workarounds" like those used when installing rooted on ZFS rest on the fact that grub-probe does not recognize f2fs, and no "fixers" like GRUB for Native ZFS yet (?) exist.
On 250Gb and began to think about how I could transfer the system to it.
First of all, I was puzzled by the choice of the file system most suitable for SSD. After a short googling, I decided to install on a relatively fresh FS developed by Samsung specifically for flash F2FS (Flash Friendly File System) media.
F2FS is a fairly young FS, but nevertheless it is supported by the Linux kernel since version 3.8
The task looked like this:
- Teach the system to understand F2FS
- Partition and format SSD in F2FS
- Copy data
- Set up fstab and grub
Enable F2FS support in Kubuntu
In kubuntu 14.04 and 14.10 the f2fs support module is present but not enabled. So to enable support, just type:
sudo modprobe f2fs
Check if the module is connected
sudo lsmod | grep f2fs
Now the system can work with f2fs, but only until reboot. In order for the module to be loaded automatically at each boot, add the f2fs entry to the end of the /etc/modules file
sudo -i
echo f2fs >> /etc/modules
We also teach initramfs to support f2fs. To do this, add f2fs to the end of the file and update.
In kubuntu 16.10 with kernel 4.8, you also need to add the module crc32 otherwise the system will not boot.
sudo -i
echo f2fs >> /etc/initramfs-tools/modules
echo crc32 >> /etc/initramfs-tools/modules
update-initramfs -u
To create f2fs, install the f2fs-tools and gparted packages
sudo apt-get install f2fs-tools gparted
The KDE partition manager cannot create f2fs, but gparted can.
For support on 14.04, you also need to update the util-linux package to version 2.25 or higher.
sudo add-apt-repository ppa:xeron-oskom/util-linux && sudo apt-get update && sudo apt-get dist-upgrade -f
We connect the SSD, create partitions and format in F2FS
Since I only had a laptop without a desktop computer, I connected the SSD as an external drive via USB. To do this, I took an old external HDD, disassembled and connected my SSD instead of a regular external drive and connected the whole thing to usb.
Surprisingly, neither the system nor the disk partition manager saw it. But after booting from the installation flash drive with kubuntu 14.04, the disk was seen and I successfully created an empty partition, after which the disk became visible in the main system, in which I partitioned and formatted.
I did the partitioning in gparted, since the KDE partition manager f2fs does not yet understand.
Personally, I marked it like this:
/Boot ext2 768Mb
/Root f2fs 20Gb
/Home f2fs 210Gb
The swap will be in a file managed by .
Copy data from HDD to SSD
Transferring data from /home
On the SSD in the / home partition, create a folder with your username, assign yourself its owner
sudo mkdir $USER && chown "$USER":"$USER" $USER
and copy everything we need, remembering to copy the main configuration files and folders, such as:
.kde
.local
.config
.mozilla
To transfer data from the home directory, you can use a simple copy with the preservation of attributes and file rights. I did selective copying from the home folder, since my HDD was exactly twice the size of the new SSD, and everything simply would not fit, and there was a decent amount of "garbage" accumulated there.
I copied like this:
sudo cp -ar /home/dm/.kde/* /media/f2fs/home/dm
Copy /root and /boot
To copy c data from /root, boot from liveusb kubuntu, enable f2fs support, mount the necessary partitions and copy data from the partitions.
Enable f2fs support
sudo modprobe f2fs
Create a folder to which we will mount
sudo mkdir /media/f2fs_root
See what discs are available to us
sudo fdisk -l
Mount the f2fs root partition. Replace sdx with your partition.
sudo mount /dev/sdx /media/f2fs_root
Copy /root from HDD to SSD
sudo cp -ar /media/kubuntu/root/* /media/f2fs_root
We do the same with the /boot partition.
Setting up fstab and grub
We reboot into our system.
Setting up fstab
Find out the UUID of partitions on an SSD
sudo blkid
And edit fstab on SSD
sudo nano /media/f2fs/root/etc/fstab
For me it looks like this now:
UUID=хххххххх-хххх-хххх-хххх-хххххххххх / f2fs rw,noatime,discard 0 2
UUID=хххххххх-хххх-хххх-хххх-хххххххххх /home f2fs rw,noatime,discard 0 2
UUID=хххххххх-хххх-хххх-хххх-хххххххххх /boot ext2 auto,noatime 1 2
Making a chroot SSD to configure grub
sudo mount /dev/sdx /media/f2fs/root/boot
sudo mount /dev/sdx /media/f2fs/root/boot/efi
sudo mount --bind /dev /media/f2fs/root/dev
sudo mount --bind /proc /media/f2fs/root/proc
sudo mount --bind /sys /media/f2fs/root/sys
sudo chroot /media/f2fs/root
Then install the bootloader
sudo grub-install /dev/sdx
sudo update-grub
Where sdX- name of the SSD device (for example /dev/sdb)
Without leaving the chroot we edit grub.cfg on the SSD
Open /boot/grub/grub.cfg
sudo nano /boot/grub/grub.cfg
And looking for records like:
linux /vmlinuz-3.16.0-25-generic root=/dev/sdb2
in which we change / dev/sdb2 on the /dev/sda2
That's it, turn off the HDD and connect the SSD.
Materials used:
The performance of the file system is a very important thing, in this article we will find out which file system is running faster at the moment, and also how performance depends on the version of the Linux kernel. We will be comparing Ext4 vs F2FS vs Btrfs performance on SSD and will be using 4.4, 4.5, 4.6 and 4.7 kernels.
All three filesystems have been tested on each of the latest stable kernel versions. All tests were performed on a Samsung 950 PRO M.2 NVM Express SSD.
The nightly build of Ubuntu 16.10 was used as the operating system for testing, as well as kernels taken from the Ubuntu Mainline Kernel PPA. The tests were carried out in a fully automated and reproducible manner using the Phoronix Test Suite software. To test each of the file systems, the partition was clean formatted. Also, formatting was performed for each version of the kernel. The default mount options were used to mount each of the filesystems.
The first test was a SQLite database performance test. The speed of copy-on-write in Btrfs is slightly lower than in Ext4 and F2FS. ext4 showed the best result in this test. The performance of Btrfs has indeed improved noticeably in the Linux 4.5 and Linux 4.6 kernels, while for the rest of the file systems it has remained at the same level.
In the FIO random read test, all three filesystems have shown regression since Linux kernel version 4.4.
Sequential read results have a very different result compared to slower read speeds on newer cores.
The random write test is not that interesting.
In the FS-Mark test, the F2FS came out on top. Work was tested with 1000 files of 1 MB in size. The performance of Ext4 and Btrfs is about the same.
Flash-Friendly File-System continues to deliver great results. This time 4000 files, 32 subdirectories, 1 megabyte in size.
In the multi-threaded test, FS-Mark did not reveal much difference in the performance of Ext4 vs F2FS vs Btrfs filesystems.
F2FS again takes first place in reading speed in the BlogBench test. In second place is Btrfs.
Best write speed by BlogBench in ext4.
F2FS returns to the top in the Dbench test.
EXT4 and F2FS performed better than Btrfs in the PostgreSQL benchmark.
conclusions
These are all the test results of Ext4 vs F2FS vs Btrfs that we will review today. As you can see, F2FS is a pretty promising file system, but Ext4 and Btrfs are holding up pretty well. As for the cores, there is an increase in overall performance, but this increase is not very large.
