On Tue, Sep 12, 2006 at 03:56:00PM -0700, Matthew Ahrens wrote: > The problem that this feature attempts to address is when you have some > data that is more important (and thus needs a higher level of > redundancy) than other data. Of course in some situations you can use > multiple pools, but that is antithetical to ZFS's pooled storage model. > (You have to divide up your storage, you'll end up with stranded > storage and bandwidth, etc.)
For me this feature is something I would use on a laptop. I'd set copies = 2. The idea is: bad blocks happen, but I don't want to lose data because of random bad blocks. Dead disks happen also. This feature won't help with that. to deal with bad disks I'd like laptops to have two disks. Alternatively, I would (but don't) plug-in a USB disk from time to time as a mirror vdev. > Given the overwhelming criticism of this feature, I'm going to shelve it > for now. I don't see why. The used/free space UI issues need to be worked out. And you need to give guidance for when to use this (e.g., "ditto blocking is primarily intended for use on laptops" -- if you have mirroring/raid-5/raid-Z then you probably wouldn't care for ditto blocking). Beyond that you do need to introduce a generic filesystem-level "scrub" or re-write option for dealing with changes to fs properties that would otherwise only apply to data/meta-data created/changed after the property change. But this was needed before this case, so I don't see why this case should have to add that feature. Plus, I can imagine that such scrubbing could be difficult to implement, since it must appear to leave everything untouched, including snapshots and clones, yet actually have COWed everything that existed prior to the scrub. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
