Bug 18972
Summary: | mdadm won't make an array with more than 27 raid devices | ||
---|---|---|---|
Product: | IO/Storage | Reporter: | Rich Ercolani (rercola) |
Component: | MD | Assignee: | Neil Brown (neilb) |
Status: | RESOLVED DOCUMENTED | ||
Severity: | normal | CC: | neilb |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.35 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Rich Ercolani
2010-09-22 22:07:07 UTC
I found what's catching me in mdadm, at least. md_p.h: #define MD_SB_DISKS 27 mdadm.c: int max_disks = MD_SB_DISKS; /* just a default */ and then, later mdadm.c: if (raiddisks) { if (raiddisks > max_disks) { fprintf(stderr, Name ": invalid number of raid devices: %d\n", raiddisks); exit(2); } ... } So it's at least a hardcoded value in mdadm. My question is whether Linux MD also breaks if I screw with that value. Try man 4 md search for '28'. With mdadm, try --metadata=1.2 or if you particularly need the metadata to be at the end of the device, --metadata=1.0 NeilBrown Or to put it another way, this is a known issues with the original metadata format (0.90), which is one of the reasons that a new format (1.x) was created. mdadm is supposed to automatically choose 1.x if too many devices are requested, but it looks like I didn't check that code properly. Though it is moot now, as most recent mdadm defaults to 1.x... Does it? I tried using 3.1.4, so unless you mean git HEAD, it certainly didn't do the Right thing without explicitly being told --metadata 1.0 or --metadata 1.2... |