[SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

skyer · 2013-12-25 10:09:53

I have a problem with discard option on my ssd drive. The root partition is mounted with discard:

[root@sigma /]# mount |grep sda1
/dev/sda1 on / type ext4 (rw,relatime,discard,data=ordered)

Yet, using fstrim I can trim unused blocks:

[root@sigma /]# fstrim -v /
/: 5.6 GiB (5985071104 bytes) trimmed

Same goes for my /home partition, which is on sda too, but it usually trims about 44GBs.

//edit: interestingly enough, it seems that / has always 4-5GB of unused blocks and /home/ 44-45GB, regardless of when I run it. (Except for immediately after).

//edit2: I did check with this tutorial http://nedoboi.wordpress.com/2011/11/12 … -it-works/ and discard seems to be working, yet fstrim keeps trimming a lot of data.

I'd gladly provide more information if I knew what to provide.

Thanks for any help.

Last edited by skyer (2013-12-28 11:03:58)

stqn · 2013-12-25 13:51:49

I guess fstrim just trims all free blocks no matter if they’ve already been trimmed or not. Here it trims more than the available free space reported by df…

Source code of fstrim: http://sourceforge.net/p/fstrim/code/ci … e/fstrim.c (not sure if it’s the latest version)

ioctl(fd, FITRIM, opts->range)

range is initialized by default to the biggest possible number (ULLONG_MAX) so I guess it just trims the whole filesystem.

Mr.Elendig · 2013-12-25 22:03:45

fstrim in cron is generally a better way to do trim than discard,

stqn · 2013-12-26 00:05:14

Mr.Elendig wrote:

fstrim in cron is generally a better way to do trim than discard,

From what I just gathered some people say discard might sometimes make deleting files slower, but that’s about it. The Arch wiki states discard is preferable.

skyer · 2013-12-27 13:07:08

@stqn that makes some sense, since:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.8G  4.2G  5.1G  45% /
/dev/sda2        59G   16G   41G  27% /home

Would you explain the mechanism a little further? If all free blocks are trimmed, (for /home) I just successfully trimmed 43G while only 41G is free.

And just to make sure - if I understand it right, fstrim just forces TRIM to every block that is supposed to be free, disregarding the fact that it's empty already, right?

@Mr.Elendig Just like stqn said, the Arch wiki says that discard is preferable. Would you explain why do you prefer fstrim in cron over discard option?

stqn · 2013-12-27 14:03:53

skyer wrote:

Would you explain the mechanism a little further? If all free blocks are trimmed, (for /home) I just successfully trimmed 43G while only 41G is free.

Sorry, no idea. Here it trims 6.4 GiB when only 5.5 GiB are free! I can’t explain this difference of almost 20%.
The man page of fstrim says something about the reported size, but I don’t understand it very well:

fstrim man page wrote:

fstrim will output the number
of bytes passed from the filesystem down the block stack to the
device for potential discard. This number is a maximum discard
amount from the storage device's perspective, because FITRIM
ioctl called repeated will keep sending the same sectors for
discard repeatedly.

skyer wrote:

And just to make sure - if I understand it right, fstrim just forces TRIM to every block that is supposed to be free, disregarding the fact that it's empty already, right?

fstrim asks the filesystem to trim everything, but…

fstrim man page wrote:

fstrim will report the same potential discard bytes each time,
but only sectors which had been written to between the discards
would actually be discarded by the storage device.

thiagowfx · 2013-12-27 16:53:19

I used to use discard, like you, but I had the same 'problem' as yours.

So recently I adopted this suggestion. It works flawlessly and without annoying me. I added it to the wiki recently.

Last edited by thiagowfx (2013-12-27 16:54:42)

WonderWoofy · 2013-12-27 17:12:14

I just want to quickly point out that the TRIM feature was introduced to better clear the memory cells of SSDs when they were new/young and had shitty garbage collection. These days, the quality of SSDs have improved vastly, and often times TRIM is not actually necessary. In fact, vendors of good high quality SSDs will tell you that the garbage collection is now sufficient.

But what the article that thiagowfx linked fails to mention is that TRIM commands are blocking. This means that while these TRIMs are being carried out, other disk access cannot take place. So besides the fact that mounting with 'discard' and using fstrim is pointless (assuming all is working correctly), you are also just potentially blocking access to your disks that much more. Fortunately, in the latest SATA 3.2 makes some improvments.

thiagowfx · 2013-12-27 20:28:47

WonderWoofy wrote:

[...]that TRIM commands are blocking. This means that while these TRIMs are being carried out, other disk access cannot take place. So besides the fact that mounting with 'discard' and using fstrim is pointless (assuming all is working correctly), you are also just potentially blocking access to your disks that much more. Fortunately, in the latest SATA 3.2 makes some improvments.

You mean, blocking the disks increases the boot time? Yeah, a little, but not that much. From my current boot:

$ systemd-analyze blame | grep trim
2.641s fstrim.service
36ms fstrim2.service

There are two services for two partitions, / and /boot, respectively.

I like this systemd solution, but I should probably change it to execute weekly or so.

WonderWoofy · 2013-12-28 01:32:42

Yeah, if you have it run on boot, it will increase the boot time. I was just saying that there is no point in having both discard and fstrim since that just increases the amount of potential time the disks will be inaccessible by other processes. If you have the discard mount option, it will block every time you delete a file, and thus file deletion will take far longer. So that is typically why the periodic fstrim is often considered a good alternative.

But in reality, if you have a new, good quality disk then doing either of those things is probably not necessary anyway... though admittedly, I still have an fstrim anacron job in place.

frostschutz · 2013-12-28 03:33:24

WonderWoofy wrote:

But in reality, if you have a new, good quality disk then doing either of those things is probably not necessary anyway... though admittedly, I still have an fstrim anacron job in place.

I use a weekly fstrim task myself. It helps with the wear leveling. Even if new SSDs come with a sufficiently large sector reserve (128G drives that let you use only 120G and the like) it's still preferable to have an even larger pool of free sectors to choose from, and TRIM is the only (reliable) way of telling the SSD what is free. It's not important enough to make a religion out of it. It's like partition alignment, most people don't notice but it doesn't cost anything to get it right; running fstrim once a week or once a month is completely sufficient. And if fstrim is too slow for you, it has an option to skip free blocks below a certain size, which speeds up the process a lot.

skyer · 2013-12-28 11:01:28

Thanks for the answers,
so I guess I'll just try some other solution (either fstrim in cron or fstrim at boot) and let it go. Still, this 'weird fstrim behavior' kind of scared, didn't expect it

Lockheed · 2014-01-05 09:33:14

I wonder how fstrim should be run on disk that uses LUKS+LVM. Say, sda3 is encrypted, and is the host of LVM containing 3 LVM partitions.
Should fstrim be run on /dev/sda, /dev/sda3, on /dev/MyStorage/rootvol (and other LVs), or on each mountpoint individually?
And does it matter if the filesystem is encrypted?

@WonderWoofy, what do you mean by "a new, good quality disk"? I have a Samsung 830

Last edited by Lockheed (2014-01-05 09:37:29)

frostschutz · 2014-01-19 20:44:53

fstrim works on filesystems, not blockdevices, so you have no other option than to run it on the individual mount points.

The cryptsetup container has to be opened with --allow-discards, if your initramfs opens the crypt then you need to add this option to your initramfs. It is possible to add the --allow-discards flag at runtime however the method is dangerous and the cryptsetup author doesn't want to add support for it ( http://code.google.com/p/cryptsetup/iss … ail?id=196 )

From a security point of view, using fstrim on encryption will reveal how much data you have stored, and possibly which filesystem you are using (you can guess from the metadata locations). If your cipher is insecure it could also make you more vulnerable to attacks like this http://www.jakoblell.com/blog/2013/12/2 … artitions/ (which is why you don't use such ciphers in the first place). In practice, this isn't a problem whatsoever. For example if your /boot is on the same disk, people will just hack your initramfs to get your passphrase instead. Much less hassle this way...

As for fstrim at boot time, I do not recommend it. fstrim still issues discards and discards still cost performance; at boot time you want to have that performance available for booting and starting up various programs immediately after logging in. have fstrim run in the background sometime later once everything is loaded, so it won't be noticable.

stqn · 2014-01-19 21:25:14

frostschutz wrote:

As for fstrim at boot time, I do not recommend it. fstrim still issues discards and discards still cost performance; at boot time you want to have that performance available for booting and starting up various programs immediately after logging in. have fstrim run in the background sometime later once everything is loaded, so it won't be noticable.

If I launch fstrim after boot, *then* it will be noticeable, because it will happen while I’m trying to do something with my computer. Running it during the boot is a better option IMO. I don’t care if the boot takes 2 or 3 more seconds. I do care if my computer is not responsive, or if shutdown takes a long time (although 2 more seconds wouldn’t be a big deal).

frostschutz · 2014-01-19 21:52:26

stqn wrote:

If I launch fstrim after boot, *then* it will be noticeable, because it will happen while I’m trying to do something with my computer.

Most of the time you "do" something with your computer (such as writing a forum post), the SSD actually does absolutely nothing. So no, you do not notice fstrim unless you call it at a time you know your SSD will be busy.

Still, it's your decision.

WonderWoofy · 2014-01-19 22:51:36

I have to agree with frostschitz here. You are asking the system to fstrim on boot when the SSD is gauranteed to be active. Fstrim is a blocking process unless you have SATA 3.2, so the system will be able to literally do nothing else while it waits for the TRIM to finish if you do it on boot.

Doing it while the system is running on the other had will probably be hardly noticeable unless you are trying to access the disk while the operation is happening. So if you run fstrim and then try to immediately launch a program, then you might notice. But as far as writing is concerned, there is a dirty writeback cache anyway, which allows writes to take place all at once. So typically if you are trying to write something, it will be first "written" to RAM anyway before being pushed to the physical disk.

Like I have said before though, most manufacturers of quality SSDs with good controllers have improved garbage collection to the point where they no longer even recommend running TRIM. So it is likely not necessary in either case. (Though again, I'll admit that I have a weekly fstim anacron job set up.)

Arch Linux

#1 2013-12-25 10:09:53

[SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

#2 2013-12-25 13:51:49

Re: [SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

#3 2013-12-25 22:03:45

Re: [SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

#4 2013-12-26 00:05:14

Re: [SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

#5 2013-12-27 13:07:08

Re: [SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

#6 2013-12-27 14:03:53

Re: [SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

#7 2013-12-27 16:53:19

Re: [SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

#8 2013-12-27 17:12:14

Re: [SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

#9 2013-12-27 20:28:47

Re: [SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

#10 2013-12-28 01:32:42

Re: [SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

#11 2013-12-28 03:33:24

Re: [SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

#12 2013-12-28 11:01:28

Re: [SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

#13 2014-01-05 09:33:14

Re: [SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

#14 2014-01-19 20:44:53

Re: [SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

#15 2014-01-19 21:25:14

Re: [SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

#16 2014-01-19 21:52:26

Re: [SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

#17 2014-01-19 22:51:36

Re: [SOLVED] ext4 discard option not working (fstrim=non-zero GB values)

Board footer