2

How do you create a mdadm RAID10 with both near and far layout options?

The wiki indicates it is doable.

The "near" and "far" options can be used together...

The man pages for mdadm don't mention it.

I am only able to find this post where someone's mdadm --detail is showing a RAID10 using the near and far layout options. And another post with someone asking if it was supposed to say "near=2,far=1". Unfortunately neither show how their arrays were created.

I've tried playing with the syntax when creating my array. But it gives this error everytime:

mdadm: layout for raid10 must be 'nNN', 'oNN', or 'fNN' where NN is a number, not n2f2(or whatever syntax I tried)

I can create the array using near or far without any issue.

sudo mdadm --verbose --create /dev/md127 --level=10 --layout="What should go here to create an array using near=2 & far=2 layouts?" --chunks=512 --raid-devices=5 /dev/sd[b-f]1

What am I missing? Is the wiki out of date and this is not possible anymore?

Linux Mint 17.3 Cinnamon 64bit; 5x 3.0TB Seagate NAS HDDs (only used for RAID); 8GB RAM.

3
  • have you tried adding multiple --layout options, e.g. --layout=n2 --layout=f2 ? BTW, did you read the rest of that paragraph in md(4)? "If an array is configured with 2 near copies and 2 far copies, then there will be a total of 4 copies of each block, each on a different drive. This is an artifact of the implementation and is unlikely to be of real value."
    – cas
    Commented Apr 30, 2016 at 23:46
  • I did see the rest of the paragraph.
    – terrelsa13
    Commented May 3, 2016 at 15:50
  • And yep I tried what you have above. Didn't work for me.
    – terrelsa13
    Commented May 3, 2016 at 16:08

1 Answer 1

2

Judging from mdadm-3.4 source code, it does not accept any other inputs. As for the near=2,far=1 output, that's the default and nothing changed but values =1 are simply no longer printed because that essentially means "no additional copy" (counting starts at 1). In case both near and far equal 1, it prints NO REDUNDANCY. However you're not actually able to create such either, the kernel rejects it directly with an error message.

The only way I managed to do it is by hexediting the metadata directly. This is a RAID-10 of 4x 128MiB loop devices with near=2, far=2 copies.

# mdadm --detail /dev/md42
/dev/md42:
        Version : 1.2
  Creation Time : Sun May  1 01:47:59 2016
     Raid Level : raid10
     Array Size : 129024 (126.00 MiB 132.12 MB)
  Used Dev Size : 129024 (126.00 MiB 132.12 MB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Sun May  1 01:48:00 2016
          State : clean 
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : near=2, far=2
     Chunk Size : 512K

           Name : EIS:42  (local to host EIS)
           UUID : 7fa3ba1e:dd0f2db9:aaf3977f:0e6dc2cb
         Events : 17

    Number   Major   Minor   RaidDevice State
       0       7        0        0      active sync   /dev/loop0
       1       7        1        1      active sync   /dev/loop1
       2       7        2        2      active sync   /dev/loop2
       3       7        3        3      active sync   /dev/loop3

It actually seems to work too. (Warning, destructive test method)

# yes > /dev/md42
# echo Hello World. > /dev/md42
# grep 'Hello World' -a -b --only-matching /dev/loop[0-3]
/dev/loop0:1048576:Hello World
/dev/loop1:1048576:Hello World
/dev/loop2:67108864:Hello World
/dev/loop3:67108864:Hello World

I wrote this string to the beginning of the RAID and on two devices it's at the 1MiB position (which happens to be the metadata offset) which should be the near copy and the other is at the 64MiB position (half disk capacity) which I guess is the far copy...

Even so I would not recommend editing RAID metadata for anything. If you do this, nobody else is testing it... or maybe there is something obvious we're all missing, who knows.

Replacing disks in such a RAID seems to work. Growing, however, does not.

# mdadm --grow /dev/md42 --raid-devices=8 --add /dev/loop[4567]
mdadm: Cannot reshape RAID10 in far-mode

I think there are too many downsides. Stick to standard RAID layouts unless you have very good reason not to.

1
  • Looks like I will stick with the standard offset layout for critical data. Thanks! This has been bugging me for a while.
    – terrelsa13
    Commented May 3, 2016 at 16:05

You must log in to answer this question.

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