On Wed, 25 May 2011, Phil Karn wrote: > 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 > Interesting, system lockup really ? I have never seen problems like this and I have been doing a lot of SSD testing. Looks like that the drive is really crappy :), have you tried to look up for firmware update ? Anyway, if running fstrim more often solves the problem, it is fine. But I wonder if the other approach (periodic discard) would do better in this case (it might not since the files are really small and are 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. Thanks! -Lukas _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
