On 13/09/06, Matthew Ahrens [EMAIL PROTECTED] wrote:
Dick Davies wrote:
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
On 9/13/06, Matthew Ahrens [EMAIL PROTECTED] wrote:
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).
Not necessarily. Implementing this
On 12/09/06, Celso [EMAIL PROTECTED] wrote:
...you split one disk in two. you then have
effectively two partitions which you can then create
a new mirrored zpool with. Then everything is
mirrored. Correct?
Everything in the filesystems in the pool, yes.
With ditto blocks, you can
Celso wrote:
Hopefully we can agree that you lose nothing by adding this feature, even if
you personally don't see a need for it.
If I read correctly user tools will show more space in use when adding
copies, quotas are impacted, etc. One could argue the added confusion
outweighs the
On 12/09/06, Celso [EMAIL PROTECTED] wrote:
I think it has already been said that in many peoples experience, when a disk
fails, it completely fails. Especially on laptops. Of course ditto blocks
wouldn't help you in this situation either!
Exactly.
I still think that silent data
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
