The thing to think about when using modern NVMe or SSD drives is the filesystem has no control over where data gets written to the system. That is all handled by the onboard controller of the NAND device.

F2FS is very beneficial when there isn't a controller onboard (think USB or SD cards), as it is aware of NAND and their write limitations and will handle data accordingly (utilizing wear leveling). For devices with a controller, there is no need to worry about what filesystem you use in regards to write limitations. The filesystem will have no control over where data is written, as the wear-leveling will be handled by the controller.

Outside of those situations, according to this benchmark, there is still no clear winner on performance between F2FS, ext4, btrfs, or xfs. F2FS came out on top more, but there were still several where it didn't do so hot and other FSs did much better.

I'm lazy and just use ext4 on my systems.

All SSDs greatly benefit from trim due to the way the NAND operates. When you "delete" data, with both magnetic storage and NAND, the pointer to the data is removed, however the data still resides on the device, but there are no pointers to it. With magnetic storage, the system is able to just write the new data over the old data, since the magnet can set things on a whim. With NAND storage (SSD, NVMe, USB drives, SD cards, etc), you can't just write over old data... it has to be reset first.

All NAND devices are able to reset data, if needed, directly before a write occurs in that area, but this takes a bit of extra time for each sector that needs to be reset before the data can be written to it. A device is smart enough to use sectors of the device that doesn't need to be reset first, but over time, deletions of other files will start leaving old data that no longer has any pointers to it and has not been reset. When this happens, the performance of the device degrades since it needs to reset all sectors before it can be written.

Trim alleviates this issue by resetting all those sectors and leaving unused space ready to have data written to it. Most filesystems support some form of trim, some working in the background (continuous trim) and some requiring a program to be run (periodic trim), some support both methods (but you're better to just choose one).

F2FS enables continuous trim by default (so unless you're disabling it by the mount option "nodiscard", there is no need to do any further trim events with F2FS drives)... ext4 requires you to add the "discard" mount option if you want continuous trim. Periodic trim can be handled with most filesystems by running fstrim, either manually or setting up a cron job to do it occasionally (weekly is probably a good default for most users unless your drive is close to full). For NAND devices that are mounted with continuous trim, there is point in running periodic trim unless you want to ensure a file is deleted for good immediately after deleting it. In the past, I noticed that discard with ext4 would generally get the sector reset within 5 minutes, but running fstrim was immediate.

Trim is a product of the filesystem driver. The kernel itself doesn't do it.

====================

As for noatime, I think this recommendation for SSDs was a product of older devices that their NAND tend to not be able to withstand excessive writes. Adding noatime would prevent access times from being updated on files whenever they were accessed, which for a main partition that had the OS installed to it, that could minimize writes to the filesystem.

NAND devices have improved immensely over the last decade and is it pretty much impossible for most users to surpass the warrantied TBW (TerraBytes Written -- my 1TB 5 year old NVMe drive is warrantied to 400TB... to hit that number in 5 years, I'd need to write over 100GB per day for 10 years straight). Even if they managed to somehow surpass that crazy number, drives are able to go well past their warrantied amount (this experiment, started in 2013 and ending in 2015, found all drives were able to write well past their warrantied amount, with the earliest drive crapping out at 700TB -- with a drive from 2012). With my drive, I've used it heavily for 5 years with including /tmp, /var, and swap on there, as well as my /home partition, and I've used 5% of the drive's write capacity.

If you are adding noatime (and nodiratime) only to save your drive from writes, personally, I think there is no point. However, many disable noatime due to the slight performance penalty in needing to update the access times of files when they're accessed.

6 members found this post helpful.

I've heard so many times now that the controller handles trim on modern SSD's and manually setting trim with discard often is not necessary.

... and then there is the complication of trim with encrypted drives/partitions as well

As far as I know, automatic and periodic trim is not handled by the controller. It will only trim when necessary to write data, which leads to a performance penalty.

If you fill an encrypted disk with random data (say from /dev/random) before using it (which is the typical recommendation) and then enable trim on a NAND device, it will reset all of that random data back to the default state. This essentially allows potential hackers to see what sections on the drive have encrypted data, which theoretically would give them a better chance of decrypting the data.

The reality of it though is that it is extremely hard to crack disk encryption. It is extremely unlikely anyone would use the resources to try and crack it unless you're a super secret spy (please don't tell me if you are I'd rather stay in the dark).

Whether the performance penalty of needing to reset that NAND before writing to it is worth the increased security will be up to the individual.

Well yeah, that was my impression too. And no, I don't even have an evil maid! I was trying to read up on what the issue was, and it seemed mostly relevant for special cases. I can't even see how it's worth in most cases to even go after unencrypted data on let's say a destroyed partion, unless it's your own, or the owner is paying you to restore it.

Anyways, I was talking more in terms of regular users, since thing like discard and fstrim don't work on encrypted partions and you have to use things like luks trim etc. I haven't used trim much at all the last 5 years and I haven't noticed any trouble, but I would probably use fstrim if I noticed some performance issues with SSD disks. But that brings me back to the point about controllers, because I've really heard alot of talks around 2015 that alot of SSD disks use trim automatically in the controller. But I didn't really care or think much about it. But it would entail the operating system/filesystem telling the disk when removing the data, and the disk knowing where it is and trimming it automatically upon deletion. Not sure that makes any sense..

Yeah, I don't think anyone needs to worry about nefarious doers decrypting data whether or not they have random bits everywhere or just where data resides.

If you happen to come across that info, I'd be interested in reading it. I haven't seen anything on that, but I'd definitely be interested in reading up on it and broadening my knowledge on the subject. I did a bit of searching before writing this comment and these two articles both seem to state it is initiated by the OS and not the controller:

2 members found this post helpful.

It's nothing specific, it's just memories of ALOT of people and others saying those things around that time. I was always insistant on using discard/trim at that time. I do read technical magazines etc (from my small country in Europe), and by people I generally mean people on forums like this.. I do always take things with a grain of salt, but those sayings about fundamental changes to SSD disks were so persistent I started assuming it might be true.

It was probably a contributing factor, alongside encryption (including sometimes /), to why I generally stopped using the "dicard" flag in general, like I had always done up until that point. So I guess I kind of bought into it

Those two quotes clearly counterindicate what "those people" kept telling, as the disk can't determine it on it's own without being notified by the OS specifically with TRIM. I did run fstrim on 2 computers the other day, both with unencrypted /boot and /, and strangely enough, the one with the nvme did trim alot of data, which indicates an SSD only driver(nvme) doesn't do it automatically with the Linux kernel. Secondly, the older Samsung 8xx Evo disk trimmed 0 bytes, nothing, nada, which was quite surprising.

This link describes flash storage specific to embedded devices but the information probably overlaps with SSDs.
https://openwrt.org/docs/techref/flash.layout

1 members found this post helpful.

I believe this is a bit different than SSD or NVMe devices as that page states that they are "raw flash memory" devices, and thus show up as /dev/mtd*. I don't believe they have the controllers that SSDs and NVMes have. The latter devices show up as /dev/sd* and /dev/nvme*, indicating they are perceived differently than raw flash memory devices.

For devices that use embedded flash, it is more likely they will not include memory controllers and you will absolutely want to use a built-from-the-ground-up flash filesystem, as the FS driver should be able to take into account wear-leveling.

2 members found this post helpful.

I posted that link as an example of what seems to be discussed, because I don't think this statement takes into account that most of the flash devices we use have built in controllers, even USB and SD cards.

I believed most the previous discussion was centered on devices that would have controllers built in like SSDs or NVMe devices.

Follow-up: Comments on the output.

• Two systems, each on only one partition of an external SSD: /dev/sdc3 (Slackware64-15.0 converted to Slint64-15.0, ext4) and /dev/sdc5 (Slint64-15.0 installed in auto mode in a beforehand freed space on the drive, btrfs with one volume and 4 sub-volumes)
• Using btrfs with zstd compression level 3 divides by a factor two the space on "disk" needed by the system (same packages with a very few exceptions)

Conclusion: in "auto" mode I will use btrfs also for SD cards, eMMC drives and USB sticks. To be honest, I didn't find any factual information comparing the wear out speed and risks of damaging the file system using btrfs vs f2fs, but I assume that btrfs needing twice less blocks written on disk should help.

Below is /etc/fstab in the system using btrfs:PS. To go back to the trim/discard topic and ease maintenance we will use btrfsmaintenance with the periodicity shown below:I attach /etc/default/btrfsmintenance which leads to that.

Attached Files

btrfsmaintenance.txt (5.1 KB, 19 views)

1 members found this post helpful.