Displaying 3 results from an estimated 3 matches for "vdev_raidz_map_alloc".
2007 Aug 07
5
Extending RAIDZ.
Yeah:)
I''d like to work on this. Here are my first observations:
- We need to call vdev_op_asize method with additonal ''offset'' argument,
- We need to move data to new disk starting from the very begining, so
we can''t reuse scrub/resilver code which does tree-walk through the
data.
Below you can see how I imagine to extend RAIDZ. Here is the legend:
2007 Mar 12
1
roundup in vdev_raidz.c
...ing 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_...
2012 Jan 15
22
Does raidzN actually protect against bitrot? If yes - how?
"Does raidzN actually protect against bitrot?"
That''s a kind of radical, possibly offensive, question formula
that I have lately.
Reading up on theory of RAID5, I grasped the idea of the write
hole (where one of the sectors of the stripe, such as the parity
data, doesn''t get written - leading to invalid data upon read).
In general, I think the same applies to bitrot of