On 13/09/06, Matthew Ahrens <[EMAIL PROTECTED]> wrote:
Dick Davies wrote:
> For the sake of argument, let's assume:
>
> 1. disk is expensive
> 2. someone is keeping valuable files on a non-redundant zpool
> 3. they can't scrape enough vdevs to make a redundant zpool
> (remembering you can build vdevs out of *flat files*)
Given those assumptions, I think that the proposed feature is the
perfect solution. Simply put those files in a filesystem that has copies>1.
I don't think we disagree that multiple copies in ZFS are a good idea,
I just think the zpool is the right place to do that.
To clarify, I was addressing Celsos laptop scenario here - especially the
idea that you can make a single disk redundant without any risks.
(for bigger systems I'd just mirror at the zpool and have done).
Also note that using files to back vdevs is not a recommended solution.
Understood. But neither is mirroring on a single disk (which is what is
effectively being suggested for laptop users using this solution).
> If the user wants to make sure the file is 'safer' than others, he
> can just make multiple copies. Either to a USB disk/flashdrive, cdrw,
> dvd, ftp server, whatever.
It seems to me that asking the user to solve this problem by manually
making copies of all his files puts all the burden on the
user/administrator and is a poor solution.
You'll be being backing up your laptop anyway, aren't you?
For one, they have to remember to do it pretty often. For two, when
they do experience some data loss, they have to manually reconstruct the
files! They could have one file which has part of it missing from copy
A and part of it missing from copy B. I'd hate to have to reconstruct
that manually from two different files, but the proposed solution would
do this transparently.
Are you likely to lose parts of both file at the same time, though?
I'd say you're more likely to have one crap file and one good one.
And you know which file is crap due to checksumming already.
> I'm afraid I honestly think this greatly complicates the conceptual model
> (not to mention the technical implementation) of ZFS, and I haven't seen
> a convincing use case.
Just for the record, these changes are pretty trivial to implement; less
than 50 lines of code changed.
But they raise a lot of administrative issues (how many copies do I really
have? Where are they? Have they all been deleted? If I set this property,
how many copies do I have now? How much disk will I get back if I delete
fileX? How much disk do I bill zone admin foo for this month? How much disk
io are ops on this filesystem likely to cause? How do I dtrace this?)
I appreciate the effort and thought that's gone into it, not to mention
a request for feedback. If I've not made that clear, I apologize.
I'm just worried that it muddies the waters for everybody.
The users (me too!) want mirror-level reliability on their laptops.
I don't think this is the right way to get that feature, that's all.
--
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
