Btrfs / EXT4 / F2FS / XFS Benchmarks On The Linux 4.12 Kernel

[starshipeleven]

Not until SATA is at least as fast as PCIe, which I doubt will ever happen.

Yeah, that's a nope. Sata was born for and will also die with hard drives.

Anyone have an idea what would be best setup for the Operating System on NVMe solid state devices please? I do a little bit of everything, gaming, encoding, file transfers, archive, extract archives, write iso's to usb, copy/paste from one partition to the other, copy/paste from one system to the other, lots of browsing the net, image editing, lots of videos, plex, youtube, music, lots of cloud syncing, etc etc. What would be the best file system setup and scheduler for my immediate future?

probably F2FS, but according to the benchmark here http://www.phoronix.com/scan.php?pag...-960-evo&num=1 also ext4 will be fine. Consider that SSD controllers are designed to deal with NTFS anyway (because Windows reasons), so even a less-good filesystem choice won't be that bad.

For NVMe storage, you might do better with no scheduler at all, see here http://www.phoronix.com/scan.php?pag...x-412-io&num=4

EDIT: I just realized that I have to use the Clover UEFI bootloader and I don't think it supports F2FS. So, not exactly sure it can boot my Fedora install or not.

You'd need to check where Fedora places its kernel. If it is in the UEFI system partition (it's the same partition you put Clover into so it can sure see it), then it's fine for Clover. If Fedora's GRUB was f2fs-aware you could use Clover to boot that GRUB (since it's in the UEFI partition for sure) and then from there you'd boot Fedora.

Seems that Clover can use standalone EFI drivers (from the wiki https://clover-wiki.zetam.org/What-is-what#EFI-drivers , in the drivers64UEFI folder), but with rEFInd I could use the f2fs driver from here http://efi.akeo.ie/ and it would detect and boot an Antergos linux from f2fs. Download the x64 bundle and just place the f2fs.efi file in the right folder as described in the wiki.
The drivers from there are for EFI, for the board firmware, not for a specific bootloader. Clover or rEFInd are just programs running inside the UEFI board firmware mini-OS environment to do their job, they aren't like GRUB that fully takes over and uses its own specific drivers.

If that fails you can always make a separate /boot partition like 300 MB in size and formatted as ext4 or whatever (from the Manual partition selection in the installer, you can do that). Stuff in /boot folder is read only at boot or on kernel updates, it won't impact performance.

[starshipeleven]

Ah come on. vbullettin has blocked my reply for SkOrPn above. It will appear after a little while.

[SkOrPn]

Yeah, that's a nope. Sata was born for and will also die with hard drives.

Yeah I am well aware what sata was built for and that is why it is disabled on my system because I am moving on from that old tech, again at least for my immediate system. Of course I am forced to use it for probably a long while on my NAS (actually a Home Server). I don't see cheap 4TB PCIe SSD's any time soon, and even if we did where are the connections going to come from? Maybe have to get a Highpoint SSD7101A. THIS is why AMD's move into more PCIe lanes is so very much needed. OR, we need a seriously new SATA revision that drastically tries to catch up, something along the lines of being directly serviced from the CPU, and something with about the same capabilities of about 4-8 lanes of PCIe 2.0 minimum. You can only get so many M.2 connectors on one board, and again where are the lanes? I mean if your on Skylake or something like that forget about it. That's why I want Threadripper for my next system, as AMD knows we need more lanes asap.

probably F2FS, but according to the benchmark here http://www.phoronix.com/scan.php?pag...-960-evo&num=1 also ext4 will be fine. Consider that SSD controllers are designed to deal with NTFS anyway (because Windows reasons), so even a less-good filesystem choice won't be that bad.

I been using F2FS ever since it was first introduced onto my Nexus 7, which was at least 5 years ago. It has come a long way since but I surely thought it would be a selectable filesystem by now considering who is developing it and how successful their SSD's and mobile devices are.

For NVMe storage, you might do better with no scheduler at all, see here http://www.phoronix.com/scan.php?pag...x-412-io&num=4

Yeah, I am thinking the same thing, but with PCIe 2.0 I was wondering about noop, bfq, blk-mq or even kyber for that matter. Seems either blk-mq or none at all is the popular choices. I'm not yet familiar with noop, but it seems to be the recommended choice for Arch Linux for their Performance section on SSD's in the wiki.

You'd need to check where Fedora places its kernel. If it is in the UEFI system partition (it's the same partition you put Clover into so it can sure see it), then it's fine for Clover. If Fedora's GRUB was f2fs-aware you could use Clover to boot that GRUB (since it's in the UEFI partition for sure) and then from there you'd boot Fedora.

Seems that Clover can use standalone EFI drivers (from the wiki https://clover-wiki.zetam.org/What-is-what#EFI-drivers , in the drivers64UEFI folder), but with rEFInd I could use the f2fs driver from here http://efi.akeo.ie/ and it would detect and boot an Antergos linux from f2fs. Download the x64 bundle and just place the f2fs.efi file in the right folder as described in the wiki.
The drivers from there are for EFI, for the board firmware, not for a specific bootloader. Clover or rEFInd are just programs running inside the UEFI board firmware mini-OS environment to do their job, they aren't like GRUB that fully takes over and uses its own specific drivers.

If that fails you can always make a separate /boot partition like 300 MB in size and formatted as ext4 or whatever (from the Manual partition selection in the installer, you can do that). Stuff in /boot folder is read only at boot or on kernel updates, it won't impact performance.

Clover is a UEFI bootloader based on the work from Tianocore/Intel. I have it installed onto a Sandisk Extreme 3.0 flash drive, but connected to a USB 2.0 port on the back of the mobo. This lets me boot NVMe devices on my old Legacy BIOS only system as if it were a newer UEFI board. Without it (or DUET) I wouldn't be able to run Windows 10 or Fedora on this SM961. Surprisingly it works PERFECTLY on my Intel Xeon system. I have customized the configuration to only show Windows and Fedora entries, and I have it set to auto boot Windows at the moment. Yes, it has an EFI boot folder and there is a folder for drivers, its actually /EFI/CLOVER/drivers64/ since I am using a legacy BIOS system and Clover is aware of that.

When I installed Fedora I did so like you normally do by putting GRUB into the Windows created efi/boot partition (or is that the other way around? boot/efi lol), which I believe is only 100 MB. I expected to see GRUB when I first reboot the system after the install, but NOPE, Clover fully kept the reins somehow. So now Clover automatically gives me two options Windows 10 EFI or Fedora 26 EFI, with Windows booting in 1 second if I do not hit a key. I purposely edited the config.plist to do this as 5 seconds was unbearable. Besides, after disabling many things in my BIOS and setting to plug and play OS, I have reduced the boot time from 30 seconds to 22. Another thing I was not expecting. I thought for sure time was going to be added because of the Clover layer, but no, my system now gets to desktop faster than it ever has. Even with four Samsung 840 Pro's in RAID0, this one NVMe disk being launched by Clover gets me to desktop 8 seconds quicker, go figure. One thing I want to mention is the fact that GRUB has always been sorta laggy and slow. Clover is fast and it also respects my displays native resolution, so I am now preferring Clover over GRUB. It just seems to work much better as a bootloader.

So, you think all I need to do is find the f2fs.efi file and drop it into my drivers64 folder? That should make Clover F2FS aware, since Clover wont let GRUB take over? Never crossed my mind to look for a f2fs.efi driver, lol. Come to think about it, I am glad Clover has kept control because I don't want a 3rd layer barging in. BIOS > Clover > GRUB would be even more of a pain in the arse. What Linux distros have a working F2FS selection during install? Antergos? Arch based distros? Although I am a huge fan of both Antergos and Manjaro, I chose Fedora because on Arch I keep failing to get some proprietary software working. Fedora has better support, not as good as Debian, but its better than Arch.

I am enjoying this Fedora 26 install, so I will probably just keep ext4 for now and test drive some schedulers, and or none at all. I am starting to wonder if F2FS will ever be superior to ext4, or if any FS will be for general computing. Maybe Samsung should force the issue and request Microsoft get involved with developing a F2FS driver for Windows. That would certainly change things.

[SkOrPn]

Oh, and I just finally figured out that "noop" and "none" are one and the same thing, hahahaha. Live and learn...

EDIT: I just read that the NVMe protocol automatically bypasses the default scheduler, and uses "none" as default. Since my scheduler shows CFQ, I am not sure how to verify if this is true or not. But both Arch documentation and Debian documentation along with many comments around the net all seem to say the same thing. NVMe does not use a scheduler, it bypasses it altogether. Hmmm

Not sure where my other reply above went, but I made an extensive reply to starshipeleven, but its not here now?

[Uqbar]

Something we need with file systems benchmarks is about resilience.
I mean, how to those FSs behave with power loss or spindles and SSDs?
I understand it's not easy to plan for such tests, but it's still doable.
I say this because I think that performances are one of the parameters you take into account when choosing a FS, but shouldn't be the only one.