Alright, you just got that fast NVMe SSD, or even a couple…
You hope this drive, the size of a pack of chewing gum, will feed your need for speed.
So, you install it in your system… and notice that your system is noticeably more responsive; but there’s something that makes you feel as though you might have missed something. What is it?

Well, for starters, most likely, the one thing most people tend to overlook, is the filesystem they choose to format their new NVMe SSD with. Two of the most popular filesystems on Linux are “The Fourth Extended Filesystem” or as it is also known: “ext4”, and XFS, which is a 64-bit journalling file system created by Silicon Graphics, Inc

EXT4 and XFS are robust, journalling filesystems, and very well known and supported in the Linux world. They are also given as options for formatting hard drives, during installation of the various Linux distributions. But what is not as well known, is that EXT4 and XFS, like most other filesystems, were never intended to be used on anything other than spinning hard drives.
There was no NAND flash-based media when they were developed.

Granted, it works fine, can be grown or shrunk, depending on the needs of the user or system administrator. Why then, you ask, did I even write this tutorial? I’ll tell you.
SSDs and NVMe PCIe drives, are flash-based; and do things quite a bit differently than rotational hard drives. In short, the filesystem I’m about to suggest, Flash Friendly Filesystem (F2FS), has been designed from the ground up, specifically NAND flash-based SSDs, by Samsung. Static binaries start up noticeably faster on this filesystem. And in this tutorial, I will be using a pair of Samsung EVO PLUS 970 NVMe SSDs which offer sequential performance at read/write speeds of up to 3,500/3,300 MB/s. And as a bonus, the 970 EVO Plus includes an AES 256-bit hardware-based encryption engine; a nice touch for those who like to encrypt their data.

Why two? Because my motherboard has two M.2 slots, while some have three or more; and because I prefer at least two drives in my setup. This means that in your case, one drive might get a Windows installation, and the other Linux, or a Virtual Machine (VM) if you’re into that sort of thing.

Personally, I advise installing the ‘/’ (root) on drive 1, and ‘/home’ (user files) on drive 2. Or maybe you’re a video editor, and the Operating System (OS) is on drive 1, and drive 2 for your video editing and rendering software, etc. Or perhaps you’re a gamer, and place the OS on drive 1, and your games on drive number 2. The point is, when possible, place your OS on drive 1, and the programs you install yourself, on the second drive. And should you have three or more drives, which you can use from within your OS, even better. This will allow you to interleave commands between the drives, and as a result, you end up not noticing any slowdowns in your perceived performance of the system.

Even though NVMe drives are way faster than rotational drives, it’s still more efficient to separate large programs from the OS, even though some might say it’s not really necessary, because the drives are so fast with a lot of throughput. It all depends on how you will be using the system.

Anyway, let’s get to the meat of this tutorial.

F2FS stands for “Flash Friendly File System”, and was developed at Samsung Electronics Co., Ltd.
And F2FS is also a filesystem designed to make the most of the performance capabilities of modern NAND flash-based devices. It was designed from the ground up, for that purpose.

While it is possible to use it on rotational hard drives, it would defeat the purpose; as you would not allow the filesystem to show you what it can do. It really should be used on NAND flash-based drives.
My personal layout I will describe below.

First the hardware specifications:

CPU Intel i9-9900k
MOTHERBOARD Asus TUF-Z390 PLUS GAMING
RAM 32GB DDR4

NVMe SSDs 2x Samsung 970 EVO PLUS 250GB

SATA SSDs 2x Samsung 860 EVO 1TB

SATA HDD 1x Western Digital 3TB 5400rpm

Linux OS Slackware -current 64 bit (August 30, 2019)

You will need F2FS tools: f2fs-tools-1.12.0-x86_64-1.txz (latest version at the time of this writing)
You may download it from https://slackware.pkgs.org, or any of the other repositories.

Since I desired to get the most user perceived speed out of the system, I used a combination of filesystems for the system, temp, and home partitions.
Like this:

Swap is the first partition, and also the smallest, at 8GB.

The OS root partition (/) at 32GB, is formatted with F2FS (programs start fastest with F2FS)

The temp partition (/tmp) at 40GB, is formatted with EXT4 (fastest when compiling software)

The user files partition (/home) at 150GB, is formatted with XFS (speedy for large and random files)

Here is a link with a speed test comparison between BTRFS, EXT, F2FS, XFS, on Linux:
https://www.phoronix.com/scan.php?pa...esystems&num=1

Now, one last thing: the drive space is setup under LVM (Logical Volume Management)
This makes it much simpler to shrink and or expand partition sizes on the fly.
I created the following:

1 Physical Volume (PV)
1 Volume Group (VG)
3 Logical Volumes (LVs)

So far this is fairly straightforward.
I forgot to mention that the other NVMe SSD was used for a Windows 10 installation, *before* I started with the install of Slackware Linux. This prevents Windows from overwriting the boot loader.

Now, for those unfamiliar with creating an LVM setup, I'll give generic instructions, which should work on most Linux systems. Some of the instructions are lifted from alien Bob's slackware LVM. Read all the instructions before you begin. Let's go.

To create a new Logical Volume (LV), this has to happen before you run the part of the installer, where you actually install the OS. Start by creating the partition where you will place the LVM with fdisk for BIOS, or gdisk for GPT disks. After creating the partition, then change the type to "8e", which is Linux LVM. Reboot the system, and continue with setting up the LVM.

Now I will leave the partition sizes up to you, but in this example, I will be dividing a 250GB SSD, over 2 partitions; swap, and the rest of the space for system install.
Start as follows:

1. pvcreate /dev/nvme0n1p2 (<-- the second partiton after swap)

2. vgcreate slackware /dev/nvme0n1p2 (<-- slackware is the name I chose, can be anything)

3. lvcreate -L 32GB -n root slackware

4. lvcreate -L 40GB -n temp slackware

5. lvcreate -l 100%FREE -n home slackware (this command uses all the remaining space for home)

Now you can continue with the OS installation.
Make sure you choose "/dev/slackware/root" as the "/" partition, when asked where to install to; and format it with F2FS.
Then make sure you choose "/dev/slackware/temp" to mount as the "/tmp" partition, and choose to format it with EXT4. And lastly, choose "/dev/slackware/home" to mount as the "/home" partition, and format it with XFS.

When the installer finishes, it will ask you to reboot. But select "no" and go with the option to let it drop you into a command prompt.
To boot this setup, you need to add the F2FS modules to your initrd, if using LILO, and install the F2FS tools in your OS, before you reboot.

I previously downloaded the f2fs-tools-1.12.0-x86_64-1.txz on a partition of one of the other SSDs, which I simply mounted, located the binary, and ran "installpkg f2fs-tools-1.12.0-x86_64-1.txz".

Now, chroot into the installed OS, by typing: chroot /mnt (<-- Slackware specific instructions YMMV)

Here's the command to create the initrd for kernel version 4.19.69 with modules for LVM and F2FS:
(is a single line)
mkinitrd -c -k 4.19.69 -m crc32:libcrc32c:crc32c_generic:crc32c-intel:crc32-pclmul:f2fs -f f2fs -r /dev/slackware/root -L

For a system using LILO, edit the lilo.conf file, so lilo uses the initrd, and add the following:
image = /boot/vmlinuz-generic-4.19.69
initrd = /boot/initrd.gz
root = /dev/slackware/root
label = linux
read-only

Run /sbin/lilo when you are done editing lilo.conf.

If using GRUB, after installing the F2FS tools, you need to make sure the LVM modules load before the rest of the system.
Edit /etc/default/grub, find the following line:
GRUB_PRELOAD_MODULES="... " (<-- there might be other modules already there)

And add the required modules between the quotation marks at the end.
Like so:

GRUB_PRELOAD_MODULES="... lvm f2fs"

Then run update-grub (or grub-mkconfig -o /boot/grub/grub.cfg), wait for it to complete, and you should be set.
If at this point you reboot, and you can boot into your shiny new system without error... Congratulations!
You are done.

Cheers!

For suggestions on improving this tutorial, please email to:
wisesoniam@gmail.com
or simply reply to this thread

=========================================================================
DISCLAIMER:

If your computer explodes, any part of it gets damaged, you lose data, or Earth is destroyed as a result of you following these instructions... I am not responsible for anything other than providing you with the instructions on how to setup a system, with user-perceivable increased speed. Understand this before you go through with it.

Nice write up.

One thing though - you don't mention RAID setup. While I prefer to separate OS and other filesystems as you mentioned I would not do it at the cost of RAID redundancy of the drives. Rather I'd put both drives into a RAID1 setup (NVME hardware or meta disk) then use that as the PV for the VG then create separate LVs for the OS and other filesystems. Of course I'd lose space availability of the equivalent of one drive but wouldn't have to worry about one drive going down blowing me out of the water as I would in a non-RAID config.

We made the mistake of using a single SSD card in a system because it claimed to do "internal redundancy" by duplicating data from one memory spot to another. It bit us when the controller on the SSD card itself died - that particular item was not redundant so we lost the drive and the data on it.

2 members found this post helpful.

Hi,

You are right.
An LVM in a RAID SETUP, RAID 1 at least, would provide the minimum required redundancy.
Though I must confess, I have never setup a RAID array before. However, since most of the new motherboards come with a halfway decent raid chip, and the UEFI includes automated RAID array creation, it has become rather easy.

While I familiarize myself with the RAID documentation, I will also add something that is of use for those with UEFI/GPT setups: I successfully installed Slackware, GRUB on the GPT initialized NVMe SSD. It turned out to be very simple as well. I'll edit the instructions to include the updated information.

Thanks for the heads up

Cheers!

Exellent work.

I would not draw too many conclusions based on phoronix benchmarks though. File system performace and usability
wary wildly between every kernel release (even "maintenance" releases). The best is always to do some simple
tests yourself, with the software you intend to use, and for your use case.

While designing a file system specifically with the underlying media in thought might seem like a good idea, I
can't help but to wonder if the manufacturers of these devices thought: "Someone will probably come up with a
file system that actually works well with these devices, one day" or if they are well suited for the file systems
that were available at the time of their introduction.

Anyways; f2fs is (as of 5.2.15 on current) not really up to par in my tests. Heres an exerpt from one of my
benchmark logs:

Benchmarking wd 250G ssd on 5.2.15, 32G AMD 9590 sata, current of 10sept 2019.
All tests are done on newly formatted and trimmed (ssd) media. File systems
were loaded with hardware accelerated routines where applicable.
Hot cache copying ~50G (a few ftp archives and ~30 kernel source trees)
from ssd (ext4) to ssd. Reads were never close to exhaustion in any of these.
Measured time is return time, variance is around 10 sec. Actual time to
unmount readiness is ~20 +seconds for xfs, a little bit less for the others.

mkfs.btrfs -L d5 -m single -d single /dev/sde1:

root@trooper~# time cp -r /usr/local/src/system /mnt/d5/

real 5m34.001s
user 0m4.620s
sys 1m29.392s
root@trooper~# time rm -rf /mnt/d5/system

real 0m42.177s
user 0m0.797s
sys 0m40.454s

mkfs.ext4 -L d5 -O 64bit -E lazy_itable_init=0,lazy_journal_init=0 /dev/sde1:

root@trooper~# time cp -r /usr/local/src/system /mnt/d5/

real 5m10.676s
user 0m4.432s
sys 1m26.711s
root@trooper~# time rm -rf /mnt/d5/system

real 0m27.748s
user 0m0.912s
sys 0m25.331s

mkfs.xfs -L d5 /dev/sde1:

root@trooper~# time cp -r /usr/local/src/system /mnt/d5/

real 4m50.607s
user 0m4.642s
sys 1m22.464s
root@trooper~# time rm -rf /mnt/d5/system

real 1m5.594s
user 0m0.915s
sys 0m38.763s

mkfs.f2fs -l d5 /dev/sde1:

root@trooper~# time cp -r /usr/local/src/system /mnt/d5/

real 7m25.367s
user 0m4.171s
sys 1m22.977s
root@trooper~# time rm -rf /mnt/d5/system

real 1m1.034s
user 0m0.846s
sys 0m26.094s

While test installing "current" systems on f2fs root I've also had some nasty surprises:
#1 mkinitrd does not include dependencies for f2fs (crc32c) when you build an initrd.
#2 fsck while booting on f2fs always claim corruption.

Many years ago - well before the turn of the century we had a very bad time with an early log structured enterprise SAN (mainframe). I've always been leery about them ever since - especially the garbage collection.
And given the changes constantly incorporated for flash support into the tradition filesystems, I see no requirement in normal operation for f2fs.

Each to their own though, and good to see documentation efforts like this.