zfs discuss - Mar 2007 - ditto blocks for use data integrated in b61

Hello zfs-discuss,

  http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6459491

  I guess some people here will be happy :)


  ps. now think about all these questions: what do you think about HW
  RAID5 LUNs with raidz2 on top of this with ditto block set to 3? Or
  maybe 2 would be good enough? :))))))))))))))

  

-- 
Best regards,
 Robert                          mailto:rmilkowski at task.gda.pl
                                     http://milek.blogspot.com

Yes, PSARC 2007/121 integrated into build 61 (and there was much rejoicing :-)
I''m working on some models which will show the affect on various RAID
configurations and intend to post some results soon.  Suffice to say, if
you have a stripe with > 1 disk, you might be able to survive loss of a
disk.  There are some other details which will need to be fleshed out, too.
More importantly, positioning this relative to the other options can be
confusing, and we''re working on clear explainations to help avoid over-
exuberance.
  -- richard

Robert Milkowski wrote:
> Hello zfs-discuss,
> 
>   http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6459491
> 
>   I guess some people here will be happy :)
> 
> 
>   ps. now think about all these questions: what do you think about HW
>   RAID5 LUNs with raidz2 on top of this with ditto block set to 3? Or
>   maybe 2 would be good enough? :))))))))))))))
> 
>   
>

Hello Richard,

Wednesday, March 21, 2007, 1:48:23 AM, you wrote:

RE> Yes, PSARC 2007/121 integrated into build 61 (and there was much
rejoicing :-)
RE> I''m working on some models which will show the affect on various
RAID
RE> configurations and intend to post some results soon.  Suffice to say, if
RE> you have a stripe with > 1 disk, you might be able to survive loss of
a
RE> disk.  There are some other details which will need to be fleshed out,
too.
RE> More importantly, positioning this relative to the other options can be
RE> confusing, and we''re working on clear explainations to help
avoid over-
RE> exuberance.

Also I guess it would be possible to change copies once file system is
created, right? If it''s so then people could get confused about which
data are protected and to what extent and which are not.

Perhaps ''zfs rewrite'' would possibly help (someone working on
this?).

-- 
Best regards,
 Robert                            mailto:rmilkowski at task.gda.pl
                                       http://milek.blogspot.com

Robert Milkowski wrote:
> Hello Richard,
> 
> Wednesday, March 21, 2007, 1:48:23 AM, you wrote:
> 
> RE> Yes, PSARC 2007/121 integrated into build 61 (and there was much
rejoicing :-)
> RE> I''m working on some models which will show the affect on
various RAID
> RE> configurations and intend to post some results soon.  Suffice to
say, if
> RE> you have a stripe with > 1 disk, you might be able to survive
loss of a
> RE> disk.  There are some other details which will need to be fleshed
out, too.
> RE> More importantly, positioning this relative to the other options can
be
> RE> confusing, and we''re working on clear explainations to help
avoid over-
> RE> exuberance.
> 
> Also I guess it would be possible to change copies once file system is
> created, right? If it''s so then people could get confused about
which
> data are protected and to what extent and which are not.
My understanding is that writes use the current copies parameter.  So, yes,
some people could be confused.  A good idea would be to set that policy at
file system creation time.
> Perhaps ''zfs rewrite'' would possibly help (someone
working on this?).
Wouldn''t that fall under the generic rewrite/shrink functionality
we''re also
anxiously waiting for?  Note that this also brings up a nasty edge case where
the rewrite may cause you to run out of space.
  -- richard

Richard Elling wrote:
> Robert Milkowski wrote:
>> Hello Richard,
>>
>> Wednesday, March 21, 2007, 1:48:23 AM, you wrote:
>>
>> RE> Yes, PSARC 2007/121 integrated into build 61 (and there was much
>> rejoicing :-)
>> RE> I''m working on some models which will show the affect
on various RAID
>> RE> configurations and intend to post some results soon.  Suffice to
>> say, if
>> RE> you have a stripe with > 1 disk, you might be able to survive
loss
>> of a
>> RE> disk.  There are some other details which will need to be
fleshed
>> out, too.
>> RE> More importantly, positioning this relative to the other options
>> can be
>> RE> confusing, and we''re working on clear explainations to
help avoid
>> over-
>> RE> exuberance.
>>
>> Also I guess it would be possible to change copies once file system is
>> created, right? If it''s so then people could get confused
about which
>> data are protected and to what extent and which are not.
> 
> My understanding is that writes use the current copies parameter.  So, yes,
> some people could be confused.  A good idea would be to set that policy at
> file system creation time.
That''s right.  Here are the manpage changes:

      copies=1 | 2 | 3

          Controls the number of copies of data stored for this dataset.
          These copies are in addition to any redundancy provided by the
          pool (eg. mirroring or raid-z).  The copies will be stored on
          different disks if possible.

          Changing this property only affects newly-written data.
          Therefore, it is recommended that this property be set at
          filesystem creation time, using the ''-o copies=''
option.

> 
>> Perhaps ''zfs rewrite'' would possibly help (someone
working on this?).
> 
> Wouldn''t that fall under the generic rewrite/shrink functionality
we''re
> also
> anxiously waiting for? 
Correct.

--matt

Hello Richard,

Wednesday, March 21, 2007, 6:23:05 PM, you wrote:

RE> Robert Milkowski wrote:

RE> Wouldn''t that fall under the generic rewrite/shrink
functionality we''re also
RE> anxiously waiting for?  Note that this also brings up a nasty edge case
where
RE> the rewrite may cause you to run out of space.
RE>   -- richard


Yes, we''re waiting for this :)

In most cases rewrite/shrink should inform admin if given operation is
possible in case of free space.
However it won''t be probably possible with ditto block for data block
without actually scanning entire pool...

I guess that in such a case two options should be provided. 1) just to
go ahead and we will see what happens. 2) first scan entire pool and
give the answer.


-- 
Best regards,
 Robert                            mailto:rmilkowski at task.gda.pl
                                       http://milek.blogspot.com