Help with mdadm to build a RAID 1 array on an ARM NAS
 

Hello, I'm new to LQ, I hope this is the right section to post in.

I have an ARM NAS with Linux. It is a Western Digital MyBook World, ARM EABI.
This Linux box has a SATA disk and a USB port.
I connected a new hard disk on the USB port and I want to setup a RAID 1 on this for one of its partitions. In the past, when I was using another (older) disk, I had no problem to do this. However, now this is the error message I receive:

The error message isn't saying what's actually wrong. I don't know what to do to diagnose the real problem. I'm not a Linux guru and I know very little about Linux RAID. Although I have some Linux experience.

I searched the web a lot: I found many pages about similar "Invalid argument" problems, but none of them seems to be my own problem.

Can anyone help with this? Is this the right forum section to post in?

Thanks a lot in advance,
Mauro.

could you post the result of

Hi!
Here it is:

The problem may be related to the fact that /dev/sdb has 4k sectors. Could you also post the result of
But it could also be that mdadm doesn't like that the partitions are not on a cylinder boundary.
which version of mdadm are you using.

and

Regarding the mdadm version:

However, I don't think that the problem is related to cylinder boundaries, because the array are working fine with the /dev/sda* partitions and were working fine with the old drive. Partitions were created with the same boundaries, because /dev/sdb is meant to be a clone copy of /dev/sda.

The new disk is in fact a Western Digital Caviar Green with Advanced Format. Maybe this is related to the 4k sectors. By the way, the 4k sectors were chosen automatically by the OS when partitioning the drive.

So, does this mean that Linux RAID does not support 4k sectors drives? Or is it a limit of my Linux kernel version?

Thanks for your help!

The partition table for dev/sdb doesn't seem right the disk has 15200 cylinders and you manage to let the partition end on cylinder 121601 can you changes to sectors with u in fdisk. Then you might be able to create equally sized partitions as dev/sda.

I understand the problem, but I'm not sure I clearly understood the solution.

First of all, if I type fdisk -ul to see sizes in sectors instead of cylinders I see:

Once again, it says I have 244,190,646 sectors but the last partition ends on sector 1,953,520,064. This doesn't surprises me too much, since partitions were created by a tool that tries to replicate the partition table of /dev/sda on /dev/sdb. This tool seems not to be taking account of the different sector sizes. However, I don't know how I should proceed to delete all the partitions and recreate them in order to be the exact same sizes of /dev/sda partitions.

More precisely, I'm pretty sure that /dev/sdb1, /dev/sdb2 and /dev/sdb3 must be equal to /dev/sda1, /dev/sda2 and /dev/sda3 respectively, since I now that they will be used in pairs to create RAID-1 arrays in order to replicate contents in /dev/sda* into /dev/sdb*. The last partitions, instead, I mean /dev/sda4 and /dev/sb4, won't be put together in a RAID, since they only contain user data which will be replicated by other techniques. In fact, I previously used a 120 GB hard disk as /dev/sdb (that is, a smaller disk than /dev/sda) and all worked perfectly: the first 3 partitions were the same as in /dev/sda, but the last one was obviously much smaller than /dev/sda4.
The reason for which the tool I mention needs to create a RAID-1 array on /dev/sdb4 with a missing device is not perfectly clear to me, but I think it's just to way to replicate the system state of the first disk, whenever the second disk needs to totally replace the first in case of failure, even if /dev/sdb4 can actually be sized differently than /dev/sda4.

So, now, could you give me some hints on how should I proceed to recreate /dev/sdb partitions correcly?

I appreciate your help very much!
Mauro.

With fdisk started in sector mode for /dev/sdb you can delete the partitions with d and then the number of the partition sdb1 that is 1. Repeat that for the partitions 2 to 4. As you can see a unit of /dev/sdb is 8 times so big as a unit of /dev/sda. 4096 vs 512. So the number of blocks occupied by the different partitions needs to be 8 times so small. the starting sector also needs to be 8 times so small. Type n for a new partition then it ask for a start sector 64320 div 8 is 8040. So the start sector is 8040. Then it asks for the last sector or size. the size of sda1 is 1959936 blocks div 8 is 244.992 blocks a block is 2 sectors so multiply with 2 to get the size in sectors is 489.984 . Type +489983 to give the size. Then press t to set the type of partition 1 to fd. Check with p if the partition is what you want. Repeat for partition 2 to 4. The dots are only for clarity do not type them.

If you have added all the partitions and they are what you want type w to write the changes to the partition table. Else you can start all over again ;-).

Hi whizje,
thank you very much again for your help. I will certainly do what you suggest.
However, I have a more difficult (I think) question now.

Some background. Western Digital My Book World Edition is sold in two versions:
- the 1 disk version
- the 2 disk version, which uses two disks in RAID configuration
The 1 disk version (the one I have) at O.S. level is actually a 2 disk version with one disk missing. This means that, as you could see from my mdadm outputs, it's using RAID arrays /dev/md0, /dev/md1, /dev/md2 and /dev/md3 with just one partition each (/dev/sda1, /dev/sda2, /dev/sda4 and /dev/sda3 respectively).
This fact is exploited by a little tool (which consists of a set of scripts) to allow the cloning of the primary disk to an external disk (connected to the USB port) in order to have a full system backup on a secondary disk, which could then replace the primary one in case of failure, by simply unplugging the broken disk and plugging the new one instead.

Now, my primary disk has a sector size of 512 bytes, while my secondary disk has a sector size of 4 Kbytes. I'm going to create partitions on the secondary disk as you suggested, so that they are sized equally. In this way I should be able to:
- add /dev/sdb1 to /dev/md0 to replicate /dev/sda1
- add /dev/sdb2 to /dev/md1 to replicate /dev/sda2
- add /dev/sdb3 to /dev/md3 to replicate /dev/sda3
(the copying of /dev/sda4 to /dev/sdb4 is performed differently, since this last partition is actually the "data partition", and backup is made using rsync, so that I may even "clone" the primary disk to one of different size).

So far so good.

The question is this: once I have /dev/sda "cloned" to /dev/sdb using this technique, does replacing the primary disk with the secondary one let me boot the system? I mean, as long as I know, sector addresses are used by the boot manager to find the partitions to boot. If I just use the disk that is now /dev/sdb as the boot disk (with its MBR having all the information copied from /dev/sda, which has a different sector size hence different partition boundaries in sector units), will the system be able to boot?

Searching for the boot device used by the system, I see:

So, it seems like it's using the logical RAID device /dev/md0 to boot the system. Hence, I would expect that the Linux RAID driver takes care of translating any "logic" sector count (written in the MBR) to the correct "physical" sector count on the fly and so let me boot the system from either of the two disks, even if they have different sector sizes.

Am I correct? Or am I in trouble?

Thanks again in advance!!

I think it should work. Try it and post the result.

Hi whizje,
I'm still in trouble. First of all, I had some problems creating the partition table. The first three partitions were created with no problems, following your advices. For the fourth one, I thought: "I'll let fdisk create the partition starting at the sector I want and extending till the end of the disk". So, I first specified 809272 as the starting sector and hit enter (without typing anything) as the ending sector. I realized later that however fdisk set the last sector somewhere at 1953504000, which would be the sector count of my disk if it had sector of 512 KB in size!! When I realized this, I divided the last sector by 8 and re-created the ending partition by specifying that value - 1... However, doing fdisk -l I saw that the ending cylinder was then set one above the last one (so: the last cylinder of /dev/sdb4 was 15201, while the disk has only 15200 cylinders). So I did this: took 15200, multiplied by 16065 to get the last sector and subtracted 1. So, this is the partition table I ended with:

Or, in sectors:

This seems correct to me and the block count of the corresponding partitions 1, 2 and 3 on the two disks seems perfect.
The fourth partition seems to end in the last cylinder of the disk, so I think (and I hope) it's correct now (as I said, I couldn't say "calculate the end yourself" to fdisk in sector mode).

However, another strange thing is that I can't use parted to do operations on the new disk:

And, if I try "mklabel msdos" on /dev/sdb I get the following:

Anyway, this doesn't disturb me too much.

I was then able to create the /dev/md5 array correctly, with the command that gave me problem at first:

Good!
However, the problem comes next. If I try to format /dev/md5 as xfs, I get the following error:

Any idea on why? :-(

And, by the way... why is this disk giving me so much trouble to use?

Ok, I could format the partition adding "-s size=4096" command parameter:

However, any suggestion on the way I created the last partition and on the error message of parted is still appreciated...