Dick Davies wrote:
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.
Sure, if you want *everything* in your pool to be mirrored, there is no
real need for this feature (you could argue that setting up the pool
would be easier if you didn't have to slice up the disk though).
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).
It could be recommended in some situations. If you want to protect
against disk firmware errors, bit flips, part of the disk getting
scrogged, then mirroring on a single disk (whether via a mirror vdev or
copies=2) solves your problem. Admittedly, these problems are probably
less common that whole-disk failure, which mirroring on a single disk
does not address.
But they raise a lot of administrative issues
Sure, especially if you choose to change the copies property on an
existing filesystem. However, if you only set it at filesystem creation
time (which is the recommended way), then it's pretty easy to address
your issues:
(how many copies do I really have?
whatever you set the 'copies' property to.
Where are they?
If you have multiple disks, they are almost certainly on different
disks. Some tiny fraction of the blocks may have both their copies on
the same disk if enough disks were nearly full.
Have they all been deleted?
No.
If I set this property, how many copies do I have now?
Whatever you set the 'copies' property to.
How much disk will I get back if I delete fileX?
The space you get back is always the space used by the file, as
specified by st_blocks, ls -s, or du. Note that this applies even if
you use compression, or change the 'copies' property after creating the
filesystem.
How much disk do I bill zone admin foo for this month?
That would be up to your policy. You could bill them for the space
used, or divide by the number of copies.
How much disk io are ops on this filesystem likely to cause?
copies * mirror_width * raidz_stripe / (raidz_stripe-1). (this applies
even if you change the 'copies' property after creating the filesystem).
How do I dtrace this?)
The same way you'd dtrace ditto blocks today. Do you have a specific
event in mind that you'd like to trace?
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.
I agree; there is no magic. If you want to survive a drive failure in
your laptop, you need two drives in there.
--matt
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
