On 30 dec 2009, at 22.45, Richard Elling wrote: > On Dec 30, 2009, at 12:25 PM, Andras Spitzer wrote: > >> Richard, >> >> That's an interesting question, if it's worth it or not. I guess the >> question is always who are the targets for ZFS (I assume everyone, though in >> reality priorities has to set up as the developer resources are limited). >> For a home office, no doubt thin provisioning is not much of a use, for an >> enterprise company the numbers might really make a difference if we look at >> the space used vs space allocated. >> >> There are some studies that thin provisioning can reduce physical space used >> up to 30%, which is huge. (Even though I understands studies are not real >> life and thin provisioning is not viable in every environment) >> >> Btw, I would like to discuss scenarios where though we have over-subscribed >> pool in the SAN (meaning the overall allocated space to the systems is more >> than the physical space in the pool) with proper monitoring and proactive >> physical drive adds we won't let any systems/applications attached to the >> SAN realize that we have thin devices. >> >> Actually that's why I believe configuring thin devices without periodically >> reclaiming space is just a timebomb, though if you have the option to >> periodically reclaim space, you can maintain the pool in the SAN in a really >> efficient way. That's why I found Veritas' Thin Reclamation API as a >> milestone in the thin device field. >> >> Anyway, only future can tell if thin provisioning will or won't be a major >> feature in the storage world, though as I saw Veritas already added this >> feature I was wondering if ZFS has it at least on it's roadmap. > > Thin provisioning is absolutely, positively a wonderful, good thing! The > question > is, how does the industry handle the multitude of thin provisioning models, > each > layered on top of another? For example, here at the ranch I use VMWare and > Xen, > which thinly provision virtual disks. I do this over iSCSI to a server > running ZFS > which thinly provisions the iSCSI target. If I had a virtual RAID array, I > would > probably use that, too. Personally, I think being thinner closer to the > application > wins over being thinner closer to dumb storage devices (disk drives).
I don't get it - why do we need anything more magic (or complicated) than support for TRIM from the filesystems and the storage systems? I don't see why TRIM would be hard to implement for ZFS either, except that you may want to keep data from a few txgs back just for safety, which would probably call for some two-stage freeing of data blocks (those free blocks that are to be TRIMmed, and those that already are). /ragge _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
