F2FS and TRIM / discard

Jeebizz · 06-09-2022, 09:05 AM

As I am running F2FS for / on my SSD, I am quite pleased at the performance, but now I just have a question and that is about TRIM. As of now I am just running a default setup, and no special parameters in fstab for /. Has anyone tried the TRIM feature, or is that redundant with F2FS, or is there any sort of recommended parameters for further optimizing F2FS?

fstab:

Code:

                                                                         
/dev/sda2        swap             swap        defaults         0   0
/dev/sda3        /                f2fs        defaults         1   1
/dev/sda1        /boot            ext4        defaults         1   2
/dev/sdb1        /home            xfs         defaults         1   2
#/dev/cdrom      /mnt/cdrom       auto        noauto,owner,ro,comment=x-gvfs-show 0   0
#/dev/fd0         /mnt/floppy      auto        noauto,owner     0   0
devpts           /dev/pts         devpts      gid=5,mode=620   0   0
proc             /proc            proc        defaults         0   0
tmpfs            /dev/shm         tmpfs       nosuid,nodev,noexec 0   0

kjhambrick · 06-09-2022, 09:31 AM

Good Qs Jeebizz

I added noatime to my ext4 fstab entries and I run a weekly TRIM Job every Sunday via Cron.

These habits are from 2011 so maybe they're no longer necessary ???

I'll be watching this thread for A's from more knowledgable LQers

-- kjh

my /etc/fstab

Code:

# cat /etc/fstab

/dev/nvme0n1p5   swap                swap        defaults,noatime                         0   0
/dev/nvme1n1p1   swap                swap        defaults,noatime                         0   0
/dev/nvme2n1p1   swap                swap        defaults,noatime                         0   0
/dev/nvme3n1p1   swap                swap        defaults,noatime                         0   0
/dev/nvme0n1p6   /                   ext4        defaults,noatime                         1   1
/dev/nvme1n1p2   /dld                ext4        defaults,noatime                         1   2
/dev/nvme2n1p2   /home               ext4        defaults,noatime                         1   2
/dev/nvme3n1p2   /opt                ext4        defaults,noatime                         1   2
/dev/nvme0n1p2   /boot/efi           vfat        noauto                                  1   0
/dev/nvme0n1p4   /dos                ntfs3       noauto,fmask=133,dmask=022              0   0
# /dev/cdrom     /mnt/cdrom          auto        noauto,owner,ro,comment=x-gvfs-show     0   0
# /dev/fd0       /mnt/floppy         auto        noauto,owner                            0   0
devpts           /dev/pts            devpts      gid=5,mode=620                          0   0
proc             /proc               proc        defaults                                0   0
tmpfs            /dev/shm            tmpfs       defaults                                0   0
#
# does not seem to work
# debugfs        /sys/kernel/debug   debugfs     defaults                                0   0
#
# mount it manually instead like this
# mount -t debugfs none /sys/kernel/debug

script /root/bin/do-fstrim - runs Sunday morning at 00:01 via cron writes log records to /root/log/do-fstrim.log

Last week's do-fstrim log:

Code:

# grep '^2022-06-05 ' /root/log/do-fstrim.log

2022-06-05 00:01:01 /sbin/fstrim -v /dld
                    /dld: 1.4 TiB (1512451219456 bytes) trimmed
2022-06-05 00:01:31 /sbin/fstrim -v /opt
                    /opt: 1 TiB (1134623129600 bytes) trimmed
2022-06-05 00:01:45 /sbin/fstrim -v /home
                    /home: 1.3 TiB (1468160258048 bytes) trimmed
2022-06-05 00:02:27 /sbin/fstrim -v /
                    /: 1.3 TiB (1454625447936 bytes) trimmed

Jeebizz · 06-09-2022, 09:39 AM

Quote:

Originally Posted by kjhambrick

Good Qs Jeebizz

I added noatime to my ext4 fstab entries and I run a weekly TRIM Job every Sunday via Cron.

These habits are from 2011 so maybe they're no longer necessary ???

I'll be watching this thread for A's from more knowledgable LQers

-- kjh

my /etc/fstab

Code:

# cat /etc/fstab

/dev/nvme0n1p5   swap                swap        defaults,noatime                         0   0
/dev/nvme1n1p1   swap                swap        defaults,noatime                         0   0
/dev/nvme2n1p1   swap                swap        defaults,noatime                         0   0
/dev/nvme3n1p1   swap                swap        defaults,noatime                         0   0
/dev/nvme0n1p6   /                   ext4        defaults,noatime                         1   1
/dev/nvme1n1p2   /dld                ext4        defaults,noatime                         1   2
/dev/nvme2n1p2   /home               ext4        defaults,noatime                         1   2
/dev/nvme3n1p2   /opt                ext4        defaults,noatime                         1   2
/dev/nvme0n1p2   /boot/efi           vfat        noauto                                  1   0
/dev/nvme0n1p4   /dos                ntfs3       noauto,fmask=133,dmask=022              0   0
# /dev/cdrom     /mnt/cdrom          auto        noauto,owner,ro,comment=x-gvfs-show     0   0
# /dev/fd0       /mnt/floppy         auto        noauto,owner                            0   0
devpts           /dev/pts            devpts      gid=5,mode=620                          0   0
proc             /proc               proc        defaults                                0   0
tmpfs            /dev/shm            tmpfs       defaults                                0   0
#
# does not seem to work
# debugfs        /sys/kernel/debug   debugfs     defaults                                0   0
#
# mount it manually instead like this
# mount -t debugfs none /sys/kernel/debug

script /root/bin/do-fstrim - runs Sunday morning at 00:01 via cron writes log records to /root/log/do-fstrim.log

Last week's do-fstrim log:

Code:

# grep '^2022-06-05 ' /root/log/do-fstrim.log

2022-06-05 00:01:01 /sbin/fstrim -v /dld
                    /dld: 1.4 TiB (1512451219456 bytes) trimmed
2022-06-05 00:01:31 /sbin/fstrim -v /opt
                    /opt: 1 TiB (1134623129600 bytes) trimmed
2022-06-05 00:01:45 /sbin/fstrim -v /home
                    /home: 1.3 TiB (1468160258048 bytes) trimmed
2022-06-05 00:02:27 /sbin/fstrim -v /
                    /: 1.3 TiB (1454625447936 bytes) trimmed

I noticed you added noatime for swap, so maybe I will add that for mine since swap is also on my SSD. I will not add it for / for F2FS yet until I get more information; and the manual for mkfs.f2fs does not even reference it. So far I have had one unscheduled shutdown (power loss), and when the system came back up, I didn't get any errors or any issues.

I do have a boot ext4 on my SSD obviously, since f2fs just does not support booting from it (yet - who knows if Samsung will add such a feature), but then again, I can just perhaps opt to comment out "/dev/sda1 /boot ext4 " anyways, so then it becomes a moot point in adding noatime if it is not mounted.

cwizardone · 06-09-2022, 10:34 AM

Quote:

Originally Posted by Jeebizz

......I do have a boot ext4 on my SSD obviously, since f2fs just does not support booting from it (yet - who knows if Samsung will add such a feature),.....

Is this particular to Samsung?
I know lilo cannot boot a f2fs partition, but grub shouldn't have problem with a SSD.
IIRC, this has all been discussed before and, again, IIRC, f2fs will trim itself automatically when it senses the system is idle. I don't remember if you have to be logged on as root for that to happen.

Jeebizz · 06-09-2022, 10:58 AM

Quote:

Originally Posted by cwizardone

Is this particular to Samsung?
I know lilo cannot boot a f2fs partition, but grub shouldn't have problem with a SSD.
IIRC, this has all been discussed before and, again, IIRC, f2fs will trim itself automatically when it senses the system is idle. I don't remember if you have to be logged on as root for that to happen.

Unfortunately I just am not well versed with GRUB; I tried setting up GRUB on a VM of Slackware15, and ended up with a non-bootable VM

; which is also why I am hoping Pat might consider adding the option to have the installer setup GRUB when you are installing Slackware.

As for LILO, I remember opening a thread about not being able to boot from F2FS, and it seems LILO and F2FS just do not play nice, and I haven't bothered and just assumed GRUB would have the same issue. As I am also using my main machine I am not prepared to experiment with GRUB and F2FS, but maybe when I have more time I will try in a VM.

Didier Spaier · 06-09-2022, 11:31 AM

I confirm that GRUB handles f2fs without issues. I just needed to modify rc.S to check the root fs periodically (but not at every boot). GRUB also handles btrfs as root fs, including with sub-volumes and on a crypted device and no dedicated partition for boot, but I digress.

This being said, as long that you use an ext4 fs and boot in Legacy mode, lilo fits the bill

Jeebizz · 06-09-2022, 01:33 PM

Quote:

Originally Posted by Didier Spaier

I confirm that GRUB handles f2fs without issues. I just needed to modify rc.S to check the root fs periodically (but not at every boot). GRUB also handles btrfs as root fs, including with sub-volumes and on a crypted device and no dedicated partition for boot, but I digress.

This being said, as long that you use an ext4 fs and boot in Legacy mode, lilo fits the bill

Ah so I retract my statement about Samsung, I was wrong - LILO just doesn't play nice with F2FS, and yes the workaround (separate /boot partition with any other FS (except for XFS too, since I think LILO doesn't play nice with that either)); and yes I do use legacy, and so I have no need for UEFI , which is another moot point if I did use UEFI, I would have a fat32 EFI partition for boot.

Didier Spaier · 06-09-2022, 05:16 PM

Quote:

Originally Posted by Jeebizz

if I did use UEFI, I would have a fat32 EFI partition for boot.

To be picky: to store the EFI OS loader, not mounted on /boot but usually on /boot/efi (but you may choose another mount point, you just need to tell GRUB which it is as argument of the --efi-directory option of grub-install.

Further it can stay unmounted and mounted only if you want to reinstall GRUB (but this is not necessary to just update the GRUB config file like following a kernel update or installation of another OS as it is not stored in the EFI partition but (usually) in /boot/grub).

Jeebizz · 06-09-2022, 05:19 PM

Quote:

Originally Posted by Didier Spaier

To be picky: to store the EFI OS loader, not mounted on /boot but usually on /boot/efi (but you may choose another mount point, you just need to tell GRUB which it is as argument of the --efi-directory option of grub-install.

Further it can stay unmounted and mounted only if you want to reinstall GRUB (but this is not necessary to just update the GRUB config file like following a kernel update or installation of another OS as it is not stored in the EFI partition but (usually) in /boot/grub).

I dunno, either way I am not planning to use GRUB anytime soon. Just like reading the documentation for encrypted luks on Slackware, my eyes glaze over. I already found out anyways that I can comment out the boot partition in fstab and my system still boots just fine (LILO).

zeebra · 06-10-2022, 03:04 AM

Quote:

Originally Posted by kjhambrick

These habits are from 2011 so maybe they're no longer necessary ???

I'm curious about this too. It's difficult to say. I've been using SSD's since about 2009, and back then it was very important to use/enable trim(discard) for SSD's. Until about 2013ish, ssd's were not that common. But after about 2015 they became quite common.
In any case, I'm pretty sure the Kernel generally knows if a disk is SSD or not, so would it not at some point automatically enable trim? There are even pure SSD drivers like nvme, and I would find it a bit strange if trim is not enabled automatically for them.

I've not used trim the last 4-5 years now, generally speaking, and once in awhile I come over articles or other stuff that mentions using trim, and I'm like dang, perhaps I need to use it. So anyways, I've been doing it manually a few times like you show.

Jeebizz · 06-10-2022, 09:32 AM

Quote:

Originally Posted by zeebra

I'm curious about this too. It's difficult to say. I've been using SSD's since about 2009, and back then it was very important to use/enable trim(discard) for SSD's. Until about 2013ish, ssd's were not that common. But after about 2015 they became quite common.
In any case, I'm pretty sure the Kernel generally knows if a disk is SSD or not, so would it not at some point automatically enable trim? There are even pure SSD drivers like nvme, and I would find it a bit strange if trim is not enabled automatically for them.

I've not used trim the last 4-5 years now, generally speaking, and once in awhile I come over articles or other stuff that mentions using trim, and I'm like dang, perhaps I need to use it. So anyways, I've been doing it manually a few times like you show.

My rationale about this; while you can use technically any FS; the problem with ext* btrfs, xfs, jfs - is that they were developed mostly when conventional drives were still mostly in play; and flash/NAND devices were an after thought with adding of TRIM. This is also why I pushed during the requests for --Current to have at least F2FS added for install support. I kinda also wish we had JFFS / JFFS2 support for comparison too; but I'll take what I can get and just use F2FS; since it is written from-the-ground-up for SSDs. With that in mind, this was the purpose of this thread - is TRIM even necessary at this point if I am using a FS that is purposed for a NAND device?

-edit

So basically, is TRIM redundant / pointless when using F2FS?

zeebra · 06-10-2022, 11:19 AM

Quote:

Originally Posted by Jeebizz

With that in mind, this was the purpose of this thread - is TRIM even necessary at this point if I am using a FS that is purposed for a NAND device?

I hadn't even heard of F2FS before this thread. But from what I know trim is actually a command to the disk to use trim, if it is supported. And if it is included in F2FS, then there is probably a reason for it.
Many things can get optimized for SSD compared to HD, and trim is just one of those things, but technically it isn't a software/FS solution, as far as I understand.

This kind of ties in with trim in general. I've heard alot of he said, she said about trim, and that it basically became redundant as a command (discard) in GNU/Linux when SSD's became popular. That's because the disks themselves would use trim anyways, or some such, and that it was no longer necessary, in most cases, to send a command to the disk to use trim.

And well, these days SSD's are more popular than HD's I think, at least for private individuals and alot has changed in the Kernel too meanwhile. But I don't know if the Kernel sends a message to the disk to use trim if it know that it has support for it. Let's say for a device that use the NVME driver in the Kernel.

But then again, wouldn't trim actually cause more writes to the disk? (which is probably part of what F2FS solves)

Bwah, by the end of the day, it all seems unclear to me.

Quote:

Originally Posted by Jeebizz

which is also why I am hoping Pat might consider adding the option to have the installer setup GRUB when you are installing Slackware.

If he hasn't done it thus far, it seems unlikely he will do it

Jeebizz · 06-10-2022, 11:24 AM

Quote:

Originally Posted by zeebra

I hadn't even heard of F2FS before this thread. But from what I know trim is actually a command to the disk to use trim, if it is supported. And if it is included in F2FS, then there is probably a reason for it.
Many things can get optimized for SSD compared to HD, and trim is just one of those things, but technically it isn't a software/FS solution, as far as I understand.

This kind of ties in with trim in general. I've heard alot of he said, she said about trim, and that it basically became redundant as a command (discard) in GNU/Linux when SSD's became popular. That's because the disks themselves would use trim anyways, or some such, and that it was no longer necessary, in most cases, to send a command to the disk to use trim.

And well, these days SSD's are more popular than HD's I think, at least for private individuals and alot has changed in the Kernel too meanwhile. But I don't know if the Kernel sends a message to the disk to use trim if it know that it has support for it. Let's say for a device that use the NVME driver in the Kernel.

But then again, wouldn't trim actually cause more writes to the disk? (which is probably part of what F2FS solves)

Bwah, by the end of the day, it all seems unclear to me.

Ah yes, I also forgot about discard so I suppose now I should append my question: "Is discard/trim redundant when using F2FS" ?

kjhambrick · 06-10-2022, 04:55 PM

Yes, I had never heard of F2FS until Jeebiz opened this thread.

Been reading about it here: WHAT IS Flash-Friendly File System (F2FS)? and other places.

I'll keep it in mind for 'next time'

Still watching this thread for hints and clues about running modern NVMe Drives on Linux ...

Thanks all.

-- kjh

Didier Spaier · 06-10-2022, 05:54 PM

As I understand it F2FS benefit the most to flash devices like SD cards or eMMC drives. Not surprisingly as it has been initially used mainly on SD cards in mobile phones, cf. https://lkml.org/lkml/2012/10/5/205. Caveat: I have seen reports of damaged file systems in case of sudden loss of power as noted in: https://wiki.archlinux.org/title/F2FS For this reason this is the default when installing Slint64-14.2.1 in "auto" mode only if the device name as reported by lsblk includes "mmc", which tells us that this device is either an SD card inserted in a card reader (i.e. not in an USB enclosure) or an eMMC storage device. This avoid the risk of loss of power caused by an inadvertent un-plugging. In Slint 15 we will probably used BTRFS everywhere if installing in "auto" mode, but I digress ("auto" here means that the installer partition the drives and make the file systems.)