automatically running fstrim

Now that the Linux 2.6.39 kernel is out, is there any reason I shouldn't run fstrim out of my crontab? It doesn't seem to slow down my system significantly while it runs.

As I understand fstrim, it walks through the file system free list issuing TRIMs for each entry, and except for whatever load the TRIM commands themselves generate (which is drive dependent) it shouldn't interfere that much with system operation. Correct? Is there any mechanism to issue these commands at a lower priority than regular disk I/O?

Thanks for all the work you guys do on XFS. It is much appreciated.

Phil

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Thanks. My problem is that I've been running some workloads that can gobble up the SSD erased page pool rather quickly. It's a Perl script feeding a large number of email messages to procmail, one at a time. I think this creates and deletes a lot of temporary files. While XFS delayed allocation normally keeps such files from going to disk, I think procmail defeats this with fsync() to keep mail from ever being lost.

So I've simply been running fstrim by hand a lot so I don't have a repeat of the system lockup I had a few days ago that I am pretty sure was due to my OCZ Revo drive not handling garbage collection very gracefully.

Phil

unlinked often). Unfortunately xfs does not have this support yet, but other filesystems do (ext4,btrfs,...) so if you like you might try one of those and mount it with -o discard mount option. What it does is, that it will send a TRIM for every range of freed filesystem blocks.

Generally, in its current state it comes with quite big performance loss (that's why we have fstrim), but in you case it might be actually more convenient than running fstrim all the time. Also it is handled automatically and the only think needed is to pass the "-i discard" mount option.

Quoted 10 lines · Lukas Czerner

unlinked often). Unfortunately xfs does not have this support yet, but other filesystems do (ext4,btrfs,...) so if you like you might try one of those and mount it with -o discard mount option. What it does is, that it will send a TRIM for every range of freed filesystem blocks.

Generally, in its current state it comes with quite big performance loss (that's why we have fstrim), but in you case it might be actually more convenient than running fstrim all the time. Also it is handled automatically and the only think needed is to pass the "-i discard" mount option.

I have thought of using ext4 with the discard option on that device for just this reason. But this OCZ Revo SSD seems to execute TRIM rather slowly. I just timed it at 7 minutes 38 seconds to trim 46 GB of free space on a 90 GB SSD. I wouldn't want that to occur in the foreground while I'm running a program that's generating a lot of garbage blocks.

Intel drives, at least, seem to execute TRIM much faster; I think they can take more blocks in each operation, and I conjecture that the drive controller simply adds them to a "to do" list for later erasure in the background. So there should probably be an option for "real-time" TRIM on those SSDs that can do it without a performance penalty.

It would be nice if the fitrim ioctl were to issue TRIM commands only for newly created garbage blocks that haven't already been trimmed. But I guess that would require some major changes to the file system data structures. At the least, it would require some special record-keeping to keep track of this information.

The Intel drive shows it's possible
to implement a very speedy TRIM, so maybe it won't be such a bad thing to just trim the whole free list every time.

Phil

Quoted 9 lines · Phil Karn

Now that the Linux 2.6.39 kernel is out, is there any reason I shouldn't run fstrim out of my crontab? It doesn't seem to slow down my system significantly while it runs.

As I understand fstrim, it walks through the file system free list issuing TRIMs for each entry, and except for whatever load the TRIM commands themselves generate (which is drive dependent) it shouldn't interfere that much with system operation. Correct? Is there any mechanism to issue these commands at a lower priority than regular disk I/O?

No, not that I know of. But why not to run fstrim from cron lets say every day ? Note that you do not necessarily need to run it "all the time", because if the drive firmware has a lot of space for doing wear-leveling, there is no point of sending TRIM.

Also keep in mind that lot of newer SSD's has some "hidden" space just for wear-leveling, so to get to the point where firmware will have hard time doing it and the drive actually get slower takes even more writes than just filling your drive up to max.

So doing fstrim once or twice a day (it really depends on your work load) is more than enough.

Also, since we have all this in place we might talk to distributions to add the infrastructure to actually recognise "discard enabled" devices and add fstrim into cron job automatically.

Or, since the filesystem
should know the best when is the "right" time to do this, we might try to figure out some kernel logic to trigger it. However it might be a little bit tricky, since every drive behaves differently...

Quoted 22 lines · Lukas Czerner

Quoted 9 lines · Phil Karn

Now that the Linux 2.6.39 kernel is out, is there any reason I shouldn't run fstrim out of my crontab? It doesn't seem to slow down my system significantly while it runs.

As I understand fstrim, it walks through the file system free list issuing TRIMs for each entry, and except for whatever load the TRIM commands themselves generate (which is drive dependent) it shouldn't interfere that much with system operation. Correct? Is there any mechanism to issue these commands at a lower priority than regular disk I/O?

No, not that I know of. But why not to run fstrim from cron lets say every day ? Note that you do not necessarily need to run it "all the time", because if the drive firmware has a lot of space for doing wear-leveling, there is no point of sending TRIM.

Also keep in mind that lot of newer SSD's has some "hidden" space just for wear-leveling, so to get to the point where firmware will have hard time doing it and the drive actually get slower takes even more writes than just filling your drive up to max.

Quoted 6 lines

So doing fstrim once or twice a day (it really depends on your work load) is more than enough.

Also, since we have all this in place we might talk to distributions to add the infrastructure to actually recognise "discard enabled" devices and add fstrim into cron job automatically.

History suggests regularly scheduled preventative maintenance like this can have unintended consequences that don't show up for some time.

When XFS first got it's online defrag tool (xfs_fsr) back on Irix in the late 90s, it was considered a good idea that running it once a week to quickly detect and fix fragementation problems before they got out of hand.

That seems like a good idea, but then 6-12 months later people started reporting XFS filesystems with really severe fragmentation, worse than before xfs_fsr was being run regularly. The majority of the files that had been in the filesystem for some time were not fragmented, but any new file would be badly fragemented and could not be fixed.

It was then discovered that the act of defragmenting files caused the fragementation of free space. That is, for every file with 2 extents that was defragmented into 1 extent, we now have two freespace extents instead of 1. So, the more files you defragment, the more free space fragments you create. If you don't delete files regularly, then eventually you run out of large free space extents. Then you can't defragment files any more, nor can you create unfragemented files.

So, xfs_fsr was then removed from the system weekly cron job, and filesystems that suffered from this went through a dump-mkfs-restore process to defragment them. From that time, xfs_fsr has been recommended as a "run only when fragmentation is causing perf problems" type of tool...

The moral of this story is that running trim as a preventative maintenance tool could have the same sort of unintended long-term consequences. That is, it may look like a good idea to run it often to keep things clean and neat, but we just don't know what it is doing to the underlying device's algorithms and it may take months for such problems to show up. e.g. as a device that performance cannot be restored to except via a secure erase....

Quoted 5 lines

Or, since the filesystem
should know the best when is the "right" time to do this, we might try to figure out some kernel logic to trigger it. However it might be a little bit tricky, since every drive behaves differently...

And that makes it much more likely that it will cause some kind of unintended problem.

Cheers,

Dave.