James Dickens wrote:
though I think this is a cool feature, I think i needs more work. I
think there sould be an option to make extra copies expendible. So the
extra copies are a request, if the space is availible make them, if
not complete the write, and log the event.
Are you asking for the extra copies that have already been written to be
dynamically freed up when we are running low on space? That could be
useful, but it isn't the problem I'm trying to solve with the 'copies'
property (not to mention it would be extremely difficult to implement).
It the user really requires guaranteed extra copies, then use mirrored
or raided disks.
Right, if you want everything to have extra redundancy, that use case is
handled just fine today by mirrors or RAIDZ.
The case where 'copies' is useful is when you want some data to be
stored with more redundancy than others, without the burden of setting
up different pools.
It seems just to be a nightmare for the administrator, you start with
3 copies and then change to 2 copies, you will have phantom copies
that are only known to exist to the OS, it won't show in any reports,
zfs list doesn't have an option to show which files have multiple
clones and which dont. There is no way to destroy multiple clones
without rewriting every file on the disk.
(I'm assuming you mean copies, not clones.)
So would you prefer that the property be restricted to only being set at
filesystem creation time, and not changed later? That way the number of
copies of all files in the filesystem is always the same.
It seems like the issue of knowing how many copies there are would be
much worse in the system you're asking for where the extra copies are
freed up as needed...
--matt
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
