[email protected] 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
