Re: automatically running fstrim

[Phil Karn <karn@ka9q.net>]

On 5/25/11 4:47 AM, Lukas Czerner wrote:


> 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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs