zfs code - Mar 2007 - roundup in vdev_raidz.c

Hi guys,

There seems to have been some discussion about this before
(http://mail.opensolaris.org/pipermail/zfs-discuss/2006-September/013050.html)
but  I don''t *quite* understand why the roundup is necessary.

Using Bill''s notation, if there isn''t a roundup (writing 4k fs
blocks
to a 4 device RAID-Z) wouldn''t you get something like this:

    Disk   0   1   2    3
--------------------
LBA  0   A.  A   A   A
        1   A.  A   A   A
	2   A.  A   A   B.
	3   B   B   B   B.
	4   B   B   B   B.
	5   B   B   C.  C
      etc.

Where writing the 4k of B blocks starts at offset 5.5k and finishes at 9k.
i.e for B (as seen in vdev_raidz_map_alloc):
f = 11 % 4 == column 3 (0 indexed)
q = 8 / (3) == 2
r = 8 - (2 * (4-1)) == 2
bc = 2 + 1 == 3
Then the for loop the first 3 columns (starting from column 3 and
wrapping) will be marked as big columns (storing an extra block each)
and the final column, column 2 will only store 2 blocks...  The
map_alloc function can then set the asize to be 5.5k and a subsequent
writes of C can start at offset 11.  Can anyone explain what it is I''m
missing?

Many thanks,

James

Hey James,

> Using Bill''s notation, if there isn''t a roundup (writing
4k fs blocks
> to a 4 device RAID-Z) wouldn''t you get something like this:
> 
> Disk     0   1   2   3
> ----------------------
> LBA  0   A.  A   A   A
>      1   A.  A   A   A
>      2   A.  A   A   B.
>      3   B   B   B   B.
>      4   B   B   B   B.
>      5   B   B   C.  C
>      etc.
You''re right: that strategy would work fine, but it does have an
unfortunate
side effect. Let''s say you then delete the file associated with B and
write
a bunch of 1 sector files; you''ll end up with something like this:

Disk     0   1   2   3
----------------------
LBA  0   A.  A   A   A
     1   A.  A   A   A
     2   A.  A   A   D.
     3   D   E.  E   F.
     4   F   G.  G   H.
     5   H   X   C.  C
     etc.

In this case, the sector marked ''X'' is a) unused, b)
unallocatable (since a
single sector on a single disk is insufficient to meet the replication
requirements), and c) unassociated with any file (the space is unaccounted
for). In the degenerate case, you could fragment your RAID-Z stripe in such
a way that all "free" space was unallocatable and unassociated with
any file
(i.e. there would be no way to determine how that free space could be
reclaimed).

By rounding space allocations up to a multiple of the minimum allocatable
size, we ensure that any wasted space is associated with a specific data
object.

Adam

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl