Matthew Ahrens wrote:
Matthew Ahrens wrote:
Here is a proposal for a new 'copies' property which would allow different levels of replication for different filesystems.

Thanks everyone for your input.

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.)

Given the overwhelming criticism of this feature, I'm going to shelve it for now.

This is unfortunate. As a laptop user with only a single drive, I was looking forward to it since I've been bitten in the past by data loss caused by a bad area on the disk. I don't care about the space consumption because I generally don't come anywhere close to filling up the available space. It may not be the primary market for ZFS, but it could be a very useful side benefit.



Out of curiosity, what would you guys think about addressing this same problem by having the option to store some filesystems unreplicated on an mirrored (or raid-z) pool? This would have the same issues of unexpected space usage, but since it would be *less* than expected, that might be more acceptable. There are no plans to implement anything like this right now, but I just wanted to get a read on it.

I don't see much need for this in any area that I would use ZFS (either my own personal use or for any case in which I would recommend it for production use).

However, if you think that it's OK to under-report free space, then why not just do that for the "data ditto" blocks. If one or more of my filesystems are configured to keep two copies of the data, then simply report only half of the available space. If duplication isn't enabled for the entire pool but only for certain filesystems, then perhaps you could even take advantage of quotas for those filesystems to make a more accurate calculation.


--matt
_______________________________________________
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

Reply via email to