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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.