From: Sebastian Riemer <sebastian.riemer@profitbricks.com>
To: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: smarter md minor search than "find_free_devnum" needed
Date: Tue, 24 Jul 2012 17:39:05 +0200 [thread overview]
Message-ID: <500EC199.5040204@profitbricks.com> (raw)
In-Reply-To: <500D4D1C.6070103@profitbricks.com>
Hi all,
I've found a faster solution by reading the names of active MD devices
from sysfs into memory and processing them from there. With 500 devices
this lasts approx. 70 ms instead of 3 s with "find_free_devnum()" in mdadm.
Here I've got it as shell code. In C it can be implemented better.
#!/bin/bash
cd /sys/block
LIST=`ls -1d md* 2>/dev/null | egrep -o '[0-9]*' | sort -n`
LIST_ARR=($LIST)
if [ "$LIST" == "" ]; then
echo "md0"
exit 0
fi
for ((i=0; i<1048575; i++)); do
if [ $i -ge ${#LIST_ARR[*]} ]; then
echo "md$i"
exit 0
elif [ ${LIST_ARR[$i]} -gt $i ]; then
echo "md$i"
exit 0
fi
done
exit 1
Of cause this needs locking until the MD device is created (further 0.8s).
Cheers,
Sebastian
On 23.07.2012 15:09, Sebastian Riemer wrote:
> 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
prev parent reply other threads:[~2012-07-24 15:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-23 13:09 smarter md minor search than "find_free_devnum" needed Sebastian Riemer
2012-07-24 15:39 ` Sebastian Riemer [this message]
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=500EC199.5040204@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.