It is hard to say, 90% or 80%. SSD has already reserved overprovisioning places for garbage collection and wear leveling. The OS level only knows file LBA, not the physical LBA mapping to flash pages/block. Uberblock updates and COW from ZFS will use a new page/block each time. A TRIM command from ZFS level should be a better solution but RAID is still a problem for TRIM at the OS level.
Henry ----- Original Message ---- From: Jim Klimov <jimkli...@cos.ru> Cc: ZFS Discussions <zfs-discuss@opensolaris.org> Sent: Tue, July 12, 2011 4:18:28 AM Subject: Re: [zfs-discuss] Pure SSD Pool 2011-07-12 9:06, Brandon High пишет: > On Mon, Jul 11, 2011 at 7:03 AM, Eric Sproul<espr...@omniti.com> wrote: >> Interesting-- what is the suspected impact of not having TRIM support? > There shouldn't be much, since zfs isn't changing data in place. Any > drive with reasonable garbage collection (which is pretty much > everything these days) should be fine until the volume gets very full. I wonder if in this case it would be beneficial to slice i.e. 90% of an SSD for use in ZFS pool(s) and leave the rest of the disk unassigned to any partition or slice? This would reserve some sectors as never-written-to-by-OS. Would this ease the life for SSD devices without TRIM between them ans the OS? Curious, //Jim _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
