sudo mdadm --build /dev/md0 --level=linear --raid-devices=3 /dev/loop0 /dev/sda1 /dev/sda2
After running the above command, /dev/md0 is smaller than /dev/loop0 + /dev/sda1 + /dev/sda2. Why is that happening, and how can I make it the correct size? /dev/sda1 is a very small partition needed by the /dev/sda2 Windows 7 partition in order for Windows to boot properly. /dev/loop0 is a loop back device I created using this command: sudo losetup /dev/loop0 boot.mbr. boot.mbr is an image file which is a copy of the first 2048 sectors that appear at the beginning of my /dev/sda disk just before the start of the first partition, /dev/sda1. Those sectors contain the Grub bootloader. This is the command I ran to create that image file: dd if=/dev/zero of=boot.mbr count=2048. The reason it needs to be the same size, is I am trying to setup the /dev/md0 virtual hard disk to mimick the layout of the Grub bootloader and those 2 partitions, but I run out of bytes when trying to setup the last partition because there are not enough bytes on the /dev/md0 disk. If you need more context, here is a link to my other question that explains why I am doing this: https://superuser.com/questions/931645/with-linux-mint-as-main-os-dual-boot-windows-7-and-have-a-windows-7-virtual-mac/937491#937491
Technical specs:
- Linux Mint 17.2 64 bit with Cinnamon
- mdadm – v3.2.5
- dd (coreutils) 8.21
More details:
fdisk shows /dev/sda1 as being 1572864000 bytes. It shows /dev/sda2 as being 229318000128 bytes. My file system shows boot.mbr as being 1048576. So if you add those three numbers together, the /dev/md0 drive should be at least 230891912704 bytes. But fdisk shows /dev/md0 as being 230891847680 bytes. So /dev/md0 is somehow 65024 bytes smaller than it needs to be.
Speculation:
I thought perhaps the problem was with the loop back device /dev/loop0. But fdisk -l /dev/loop0 shows the device as having 1048576 bytes, so it does match the size of the image file. However, fdisk complains about /dev/loop0 not having any cylindars. Could that be the problem somehow? I am just grasping at straws here.
If /dev/md0 is a virtual hard disk created by software RAID, what does that really mean? For one thing where is its data stored? Perhaps I am running out of memory or storage space somewhere?
Best Answer
Normally, Linux
mdadmRAID devices are always a little smaller than the size of the component devices (or their sum in the case of RAID 0), because MD devices store metadata.In this case you have used
--build, which invokes a manual assembly mode that does not use metadata. Nevertheless, a linear array might be smaller than the sum of the sizes of the component devices because MD devices use a chunk size. Please note the following output or similar which you should get from your command:This means that the array works with chunks of 65536 bytes. For example, if it were a RAID0 array (which it isn't) then the data would be interleaved with 65536 bytes on one component, 65536 bytes on the next, and so on.
If there are extra bytes on the end that do not make up a full chunk, then the array cannot use them.
In linear mode, I am not sure whether MD will round down the size of each component to the nearest multiple of 65536 bytes, or only round down the size of the whole array. Either way, the size of one of your components if not a multiple of 65536 bytes (the other 2 are), resulting in a round-down of 65024 bytes — exactly the discrepancy you saw.
The best way to show the exact size of a block device is:
So if you take the sum of:
And the usable size of the resulting array which can be seen with:
By the way, I think that the array you are trying to build here is pretty weird and possibly dangerous. The usefulness of an array made up of two physical block devices and a virtual block device backed by a file is weird. More importantly, you say:
It certainly sounds like you will destroy Windows 7 but if you overwrite those partitions with a Linux MD RAID device then Windows cannot use it anymore!