[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: SSD "trim" support
Matthias Drochner wrote:
> 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?
Good stuff! I'd gotten as far as printing a boot message if a disk
supported TRIM or not, but no time to go any further.
I've tried this on my 64GB OCZ Vertex 3, and it seems to have worked as
# cp /test .
# ls -l
-r--r--r-- 1 simonb wheel 104880 Apr 15 2008 test
# rm test
I did need to adjust the TRIMDEBUG printfs to use "PRId64" instead of
"lld" to get it to compile on my amd64.
One comment - the use of the name "TRIM" in the UFS layer could be a
bit more generic. This same VOP could be used for example to handle
freeing up blocks with a flash device backing a UFS filesystem. Maybe
use something like DIOCFREEBLOCKS instead of DIOCTRIM?
Main Index |
Thread Index |