Date: Sat, 30 Apr 2011 10:26:40 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Dag-Erling Smorgrav <des@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r221233 - head/sbin/fsck_ffs Message-ID: <4DBBB9B0.5080307@FreeBSD.org> In-Reply-To: <201104292300.p3TN0N8N019287@svn.freebsd.org> References: <201104292300.p3TN0N8N019287@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smorgrav wrote: > Author: des > Date: Fri Apr 29 23:00:23 2011 > New Revision: 221233 > URL: http://svn.freebsd.org/changeset/base/221233 > > Log: > Add an -E option to mirror newfs's. The idea is that if you have a system > that was built before ffs grew support for TRIM, your filesystem will have > plenty of free blocks that the flash chip doesn't know are free, so it > can't take advantage of them for wear leveling. Once you've upgraded your > kernel, you enable TRIM on the filesystem (tunefs -t enable), then run > fsck_ffs -E on it before mounting it. > > I tested this patch by half-filling an mdconfig'ed filesystem image, > running fsck_ffs -E on it, then verifying that the contents were not > damaged by comparing them to a pristine copy using rsync's checksum > functionality. There is no reliable way to test it on real hardware. > > Many thanks to mckusick@, who provided the tricky parts of this patch and > reviewed the final version. > > Reviewed by: mckusick@ > MFC after: 3 weeks Thank you! Not exactly scientific test, but my laptop survived it fine with 10% and 50% of free space. And it indeed restored the write speed, respecting that I had no kernel TRIM support enabled there before. For additional check of the drive's block remapper behavior I've written all free space with file of zeroes and deleted it -- after reboot I am still here. :) -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DBBB9B0.5080307>