Re: trim/discard success story
On Tue, Apr 03, 2012 at 06:18:43PM -0700, Julian Elischer wrote: for flash drives this is great news.. Now if ZFS would get trim support, that too would be great. I'm working on it. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpnW1D0zD64a.pgp Description: PGP signature
trim/discard success story
Today I had reason to try the UFS trim support on the FreeBSD version of the Fusion-IO driver, and I'm pleased to say that it appears to work just fine.. on a 1.3TB flash card.. the numbers of 'sectors' that the drive considers to hold valid data is reduced after the contents of the drive is erased..: After newfs -E: hw.fusion.fio.fio0.data.stats: [...] 861327 [...] After writing a few GB to the filesystem but BEFORErm -r * pu05# sysctl hw.fusion.fio.fio0.data.stats hw.fusion.fio.fio0.data.stats: [...] 3628354 [...] Afterrm -r * pu05# sysctl hw.fusion.fio.fio0.data.stats hw.fusion.fio.fio0.data.stats: [...] 919690 [...] so from 861,327 packets valid to 3,628,354 packets valid, back to 919,690 packets valid. (since bitmaps etc are allocated as needed the growth is expected but will not grow forever). (yeah I know it never actually reached 1% full but it was a test, ok?) for flash drives this is great news.. Now if ZFS would get trim support, that too would be great. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: trim/discard success story
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. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: trim/discard success story
My experience at Alacritech was that Trim was so expensive timewise that it could not be used in that application space. Instead, SECURITY ERASE on the relatively infrequent reboots cleaned things up pretty well. This should be with a grain of salt because I expect trim timings are not only vendor dependent but firmware release dependent. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: trim/discard success story
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: trim/discard success story
On 4/3/12 8:51 PM, Matthew Jacob wrote: My experience at Alacritech was that Trim was so expensive timewise that it could not be used in that application space. Instead, SECURITY ERASE on the relatively infrequent reboots cleaned things up pretty well. This should be with a grain of salt because I expect trim timings are not only vendor dependent but firmware release dependent. very true. In this case, on this drive, on this version.. it is fast. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
