On Tue, Sep 11, 2018 at 12:25:07AM +0200, Andreas Klauer wrote:
> In practise it seems few people use this option. When I tried it,
> with six 100M-loopdevs just for testing it, the kernel oopsed out.
> (unable to handle kernel NULL pointer dereference in r10buf_pool_alloc)
So I updated my slightly dated kernel today (4.16.12 to 4.18.7)
and the kernel panic didn't happen again. :-)
So create a raid10 with n3 layout for testing purposes:
# truncate -s 100M a b c d e f
# for x in a b c d e f; do losetup --find --show $x; done
/dev/loop0
/dev/loop1
/dev/loop2
/dev/loop3
/dev/loop4
/dev/loop5
# mdadm --create /dev/md42 --level=10 --layout=n3 --raid-devices=6 /dev/loop{0..5}
# for ((i=0; i>=0; i+=16)) ; do printf "%015x\n" $i; done | pv > /dev/md42
# hexdump -C /dev/md42 | head
00000000 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0a |000000000000000.|
00000010 30 30 30 30 30 30 30 30 30 30 30 30 30 31 30 0a |000000000000010.|
00000020 30 30 30 30 30 30 30 30 30 30 30 30 30 32 30 0a |000000000000020.|
So that's each 16-byte block populated with its hex offset.
That way we can grep where each data block ended up and how
many copies there are:
# grep -a -b 000000000100000 *
a:1572864:000000000100000
b:1572864:000000000100000
c:1572864:000000000100000
# grep -a -b 000000000180000 *
d:1572864:000000000180000
e:1572864:000000000180000
f:1572864:000000000180000
# grep -a -b 000000000200000 *
a:2097152:000000000200000
b:2097152:000000000200000
c:2097152:000000000200000
# grep -a -b 000000000280000 *
d:2097152:000000000280000
e:2097152:000000000280000
f:2097152:000000000280000
So each data block exists three times on either side (abc or def).
It switches sides every 0x80000 (512K) bytes.
Regards
Andreas Klauer
