Date: Tue, 03 Apr 2012 22:19:13 -0700 From: Julian Elischer <julian@freebsd.org> To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us> Cc: FreeBSD Current <current@freebsd.org>, fs@freebsd.org Subject: Re: "trim/discard" success story Message-ID: <4F7BD9D1.80504@freebsd.org> In-Reply-To: <alpine.GSO.2.01.1204032046130.1678@freddy.simplesystems.org> References: <4F7BA173.6050903@freebsd.org> <alpine.GSO.2.01.1204032046130.1678@freddy.simplesystems.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/3/12 6:50 PM, Bob Friesenhahn wrote: > On Tue, 3 Apr 2012, Julian Elischer wrote: >> >> for flash drives this is great news.. >> Now if ZFS would get trim support, that too would be great. > > The major unknown issue with trim is how well the drives > schedules/defers the trim operation so that it does not interfer > with other I/Os. Also, it would be really bad if the drive applied > trim after the block had been re-allocated for a write. It would > also be really bad if the drive loses unrelated data if there is a > power fail during trim. > > If writes get blocked by a pending trim, then trim would not help > very much. well since I work for the "drive manufacturer" I can say that in this case it really is worth it. :-) But I'm glad that it is getting out there that trim aint as easy as it seems. The hard part about trim is making it so that if you get a power failure, the trimmed data says trimmed. In some cases, it is not important. For example when a filesystem is used, trimmed data will never be accessed again without first writing new data to that address. but for any application that assumes that trimmed data will return zero's it is a critical feature. > > Bob
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F7BD9D1.80504>