On 1 jan 2010, at 14.14, David Magda wrote: > On Jan 1, 2010, at 04:33, Ragnar Sundblad wrote: > >> I see the possible win that you could always use all the working >> blocks on the disk, and when blocks goes bad your disk will shrink. >> I am not sure that is really what people expect, though. Apart from >> that, I am not sure what the gain would be. >> >> Could you elaborate on why this would be called for? > > Currently you have SSDs that look like disks, but under certain circumstances > the OS / FS know that it isn't rotating rust--in which case the TRIM command > is then used by the OS to help the SSD's allocation algorithm(s).
(Note that TRIM and equivalents are not only useful on SSDs, but on other storage too, such as when using sparse/thin storage.) > If the file system is COW, and knows about SSDs via TRIM, why not just skip > the middle-man and tell the SSD "I'll take care of managing blocks". > > In the ZFS case, I think it's a logical extension of how RAID is handling: > ZFS' system is much more helpful in most case that hardware- / firmware-based > RAID, so it's generally best just to expose the underlying hardware to ZFS. > In the same way ZFS already does COW, so why bother with the SSD's firmware > doing it when giving extra knowledge to ZFS could be more useful? But that would only move the hardware specific and dependent flash chip handling code into the file system code, wouldn't it? What is won with that? As long as the flash chips have larger pages than the file system blocks, someone will have to shuffle around blocks to reclaim space, why not let the one thing that knows the hardware and also is very close to the hardware do it? And if this is good for SSDs, why isn't it as good for rotating rust? /ragge s _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
