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:
<< >> - block boundaries
D<x> - data block
P<x> - parity block
N<x> - new parity block
U - unused
* - if offset in I/O request is less that this marker we use four
disks only, if greater - we use five disks
After adding 'NewDisk' to RAIDZ vdev, we have something like this:
Disk0 Disk1 Disk2 Disk3 NewDisk
<<P00 D00 D01 D02 U
P01 D03 D04 D05 U
P02 D06>> <<P03 D07>> U
<<P04 D08>> <<P05 D09 U
P06 D10 D11 D12>> U
<<P07 D13 D14 D15>> U
Then we start moving data, but we need to beging from the start:
Disk0 Disk1 Disk2 Disk3 NewDisk
<<N00 D00 D01 D02 D03
N01 D04 D05 D06>> <<P03
D07>> * U U U U
<<P04 D08>> <<P05 D09 U
P06 D10 D11 D12>> U
<<P07 D13 D14 D15>> U
At the end we have something like this (free space at the end):
Disk0 Disk1 Disk2 Disk3 NewDisk
<<N00 D00 D01 D02 D03
N01 D04 D05 D06>> <<P03
D07>> <<P04 D08>> <<N03 D09
D10 D11 D12>> <<N04 D13
D14 D15>> U U U
U U U U U
The biggest problem for me is a method to traverse allocated blocks
sorted by offset. Any hints how to do it?
--
Pawel Jakub Dawidek http://www.wheel.pl
pjd at FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-code/attachments/20070807/8d7c4e22/attachment.bin>
