From: Sebastian Riemer <sebastian.riemer@profitbricks.com>
To: Linux RAID <linux-raid@vger.kernel.org>
Subject: smarter md minor search than "find_free_devnum" needed
Date: Mon, 23 Jul 2012 15:09:48 +0200 [thread overview]
Message-ID: <500D4D1C.6070103@profitbricks.com> (raw)
Hi list,
I'm thinking about creation of many MD RAID 1 devices by automatic
scripts. The MD minor numbers should be auto-determined. But if I do
this with mdadm 3.2.5 and kernel 3.4.2 without udev, then it gets slower
the more devices I create. I also had to patch mdadm to make
"--symlinks=no" really work (preventing "/dev/md/*" symlinks to be created).
Looks like this:
# MDADM_NO_UDEV=1 mdadm -C auto --symlinks=no --assume-clean --force -l
1 -n 2 /dev/loop$i /dev/loop$j
Btw.: With udev it hangs for some seconds.
With this it is fast but can't use it for production (I only have the
UUIDs):
# MDADM_NO_UDEV=1 mdadm -C /dev/md$k --assume-clean --force -l 1 -n 2
/dev/loop$i /dev/loop$j
What about caching the next free minor number in kernel space, taking
it, finding the next free and updating it?
Or is there another possibility (putting this into a custom daemon
should be avoided)?
If I identify the MD devices by UUID, I don't want to care which minor
number they actually have upon creation/assembly.
Cheers,
Sebastian
--
Sebastian Riemer
Linux Kernel Developer
ProfitBricks GmbH • Greifswalder Str. 207 • 10405 Berlin, Germany
www.profitbricks.com • sebastian.riemer@profitbricks.com
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B
Geschäftsführer: Andreas Gauger, Achim Weiss
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2012-07-23 13:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-23 13:09 Sebastian Riemer [this message]
2012-07-24 15:39 ` smarter md minor search than "find_free_devnum" needed Sebastian Riemer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=500D4D1C.6070103@profitbricks.com \
--to=sebastian.riemer@profitbricks.com \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).