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.


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?

1 Answer 1


Normally, Linux mdadm RAID 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:

mdadm: chunk size defaults to 64K
mdadm: array /dev/md0 started.

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:

blockdev --getsize64 /dev/sda1

So if you take the sum of:

blockdev --getsize64 /dev/sda1
blockdev --getsize64 /dev/sda2
blockdev --getsize64 /dev/loop0

And the usable size of the resulting array which can be seen with:

blockdev --getsize64 /dev/md0

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:

/dev/sda1 is a very small partition needed by the /dev/sda2 Windows 7 partition in order for Windows to boot properly.

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!

  • 1
    This is true when you use --create but not --build, which does not store any metadata and instead relies on you doing a --build again every time you want the array assembled.
    – psusi
    Commented Jul 19, 2015 at 23:43
  • I didn't notice the --build (and I have never used that option myself). That makes my answer wrong. I will change it.
    – Celada
    Commented Jul 20, 2015 at 0:41
  • I agree what I am trying to do is weird and possibly dangerous. However others have reported success with it. The end result I am going for is certainly unusual. That is why I am trying to get this all correct before I move on to the next step. This is the only output I get from my mdadm command: "mdadm: array /dev/md0 built and started." Commented Jul 20, 2015 at 17:24
  • 1
    I will admit that I didn't research this completely: when I saw the difference was exactly 65024 bytes off which is exactly the number you'd get by rounding down to a chunk size, I looked no further. Now you've found a reference that the chunk size is supposed to make no difference. When reality seems to conflict with the docs, it's time to pull out the source code. The result? It does round down the size of each component device to a multiple of the chunk size even in linear mode, and here is where it does it.
    – Celada
    Commented Jul 20, 2015 at 19:23
  • 1
    Instead of MD RAID linear mode, you may have better luck with a device-mapper linear mapping. It's more "modern", seems more suited to your use case of creating a virtual concatenated device, and probably does not have this chunk size rounding limitation.
    – Celada
    Commented Jul 20, 2015 at 19:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .