hi, > Here is a prototype implementation for TRIM (or DELETE or how you > call it) support for ffs. > It is inspired by the FreeBSD implementation as this is done > asynchronously in ffs_blkfree(), before the blocks are actually > marked free in the filesystem. > Since ffs (at least NetBSD's) frees blocks in reverse order > I thought it was a good idea to collapse adjacent blocks > already at the ffs level where this a-priori knowledge is > present. This is different from FreeBSD; whether this is worth > the effort is subject to research. > This implementation handled only a single block range > per transaction. SSDs can handle at least 64 vectors with > one command. Extending the code should be simple. > > I've given this some testing on an Intel and a Kingston > SSD. Anyone interested in reviewing this, or more tests > and optimizations? > (The md(4) backend is for testing only, nothing serious.)
thanks for working on this. what's the expected behaviour when you read DIOCTRIM'ed blocks? YAMAMOTO Takashi > > 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
