Re: SSD "trim" support

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Mar 05, 2012 at 07:10:24PM +0100, Matthias Drochner wrote:
 > > How does that interact with fsck? (both with and without wapbl)
 > 
 > I didn't try wapbl yet, but since the trim stuff happens within
 > ffs_blkfree() which is only called at the end when a transaction
 > gets committed (as I understand the code), it should just work -
 > in theory.

I know for softupdates it should be ok, not that it matters any more;
but for traditional ffs I'd have to look at the specification and I
was hoping you or someone else would. :-)

 > Didn't see any problems with fsck yet. The filesystem did always
 > check cleanly after unmount.

Right, the question is whether it will DTRT if it gets turned off
somewhere in the middle of an operation. (But after the TRIM, since
before obviously isn't an issue.)

I also idly wonder what happens if you disconnect power from the thing
while the TRIM is running, but that's not something we can do anything
about.

 > The amount of free blocks which gets queued for TRIM might need
 > some consideration and tuning. On a disk I checked one can have
 > 256 vectors with 64k-1 (disk) blocks each within one TRIM
 > command. This would be about 8Gb (with 512-byte blocks), in the
 > (unlikely) case that that many contiguous ranges are freed. But
 > anuway, it is a significant fraction of the disk and might lead
 > to strange behavior if the disk gets full. So some extra flushes,
 > timer based or on space shortage, might be a good idea.

Yeah, I don't know. I expect there's guidelines or advice on how often
to run TRIM operations, but I have no idea what it is.

-- 
David A. Holland
dholland%netbsd.org@localhost