Re: SSD "trim" support

[Matthias Drochner <M.Drochner%fz-juelich.de@localhost>]

dholland-tech%netbsd.org@localhost said:
> 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.
Didn't see any problems with fsck yet. The filesystem did always
check cleanly after unmount.
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.

best regards
Matthias



-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

Kennen Sie schon unsere app? http://www.fz-juelich.de/app