Hello,
I have some problems and I need to be sure of what to do?
I'm not sure if I have understood everything about chunks, superblocks and other disk structure of raid level 5.
I will try to write what I think to understand and I'd like to be corrected if I made any error in following, please.
Lets take an exemple:
If the information I have is:
0100 1011 0101 0100 0101 0100 1011 1011 0111 0101 0111 0101
If I use 1 byte chunks, my chunks will be:
0100 1011 0101 0100 0101 0100 1011 1011 0111 0101 0111 0101
\-------/ \-------/ \-------/ \-------/ \-------/ \-------/
so:
chunk0: 0100 1011
chunk1: 0101 0100
chunk2: 0101 0100
chunk3: 1011 1011
chunk4: 0111 0101
chunk5: 0111 0101
A question now: is the chunk splited on the different disks or not?
I mean is it like that:
| disk0 | disk1 | disk2 |
+---------------+---------------+---------------+
| chunk0 | chunk1 | chunk0^chunk1 |
| chunk2 | chunk2^chunk3 | chunk3 |
| chunk4^chunk5 | chunk4 | chunk5 |
| chunk6 | chunk7 | chunk6^chunk7 |
| chunk8 | chunk8^chunk9 | chunk9 |
etc. with ^ the bitwise xor (^=circumflexe (in case on mistransmission))
Are the chunk splited in (n-1) parts distributed on the (n-1) disks?
Are "parity chunks" first on disk2 then on disk1 next on disk0 next on disk2 next on disk1 next on disk0... or order is another?
In this case, I understood everything right until now, the disks should like that:
| disk0 | disk1 | disk2 |
+-----------+-----------+-----------+
| 0100 1011 | 0101 0100 | 0001 1111 |
| 0101 0100 | 1110 1111 | 1011 1011 |
| 0000 0000 | 0111 0101 | 0111 0101 |
without XORed chunk you should read information "horizontally"?
| disk0 | disk1 | disk2 |
+-----------+-----------+-----------+
| 0100 1011 | 0101 0100 | |
| 0101 0100 | | 1011 1011 |
| | 0111 0101 | 0111 0101 |
Here come my real problem: I must move the disks in another computer after processor burning. I'm not sure on disk order (cause of master,slave,cable select). But if what I said before is correct, even if I now move the disks let's say:
| disk2 | disk1 | disk0 |
+-----------+-----------+-----------+
| 0001 1111 | 0101 0100 | 0100 1011 |
| 1011 1011 | 1110 1111 | 0101 0100 |
| 0111 0101 | 0111 0101 | 0000 0000 |
for resyncing you only do the same because xor is commutative and so:
disk0 = disk2^disk1
| disk2 | disk1 | disk0 |
+-----------+-----------+-----------+
| 0001 1111 | 0101 0100 | |
| 1011 1011 | 1110 1111 | |
| 0111 0101 | 0111 0101 | |
be resynced as:
| disk2 | disk1 | disk0 |
+-----------+-----------+-----------+
| 0001 1111 | 0101 0100 | 0100 1011 |
| 1011 1011 | 1110 1111 | 0101 0100 |
| 0111 0101 | 0111 0101 | 0000 0000 |
If everything is correct until now this should be non destructive? (is that not the goal of raid5?)
I think that is all about real data part of the disk?
Now other questions about structure of the disk:
(I tried to read sources of the kernel but I didn't understand everything...)
what is inside the raid5 partition?
What I think to understand is:
+-------partition------------------------------------------------
| offset 0 +-------usable part-------------------------------
| offset 1 | informations accessible after /dev/mdX mounting
| offset 2 | a little scrambled...
| ... |
| offset sb-1 +---end of usable part----------------------------
| offset sb +--suberblock-------------------------------------
| offset sb+1 |
| offset sb+2 |
| ... |
| offset end +---end of sb-------------------------------------
+-----end of partition-------------------------------------------
Is there other parts?
Does the "usable part" begins at the beginning of the partition?
Where begins the superblock? Is that the end of the "usable part"? (In case I need to "manually" reconstruct the informations)
Is the end of the superblock the end of the partition?
Does the resync only resync the usable part?
If:
-disks are physically good (I think) and
-resyncing bad ordered disks don't corrupts data and
-the resync only resync the usable part and
-superblock were crush (by bad advises on moving disks found on web)
I can try to mount read-only without corrupting data?
This is the end, my friend...
Thanks for helping,
Loris
