linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* smarter md minor search  than "find_free_devnum" needed
@ 2012-07-23 13:09 Sebastian Riemer
  2012-07-24 15:39 ` Sebastian Riemer
  0 siblings, 1 reply; 2+ messages in thread
From: Sebastian Riemer @ 2012-07-23 13:09 UTC (permalink / raw)
  To: Linux RAID

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: smarter md minor search  than "find_free_devnum" needed
  2012-07-23 13:09 smarter md minor search than "find_free_devnum" needed Sebastian Riemer
@ 2012-07-24 15:39 ` Sebastian Riemer
  0 siblings, 0 replies; 2+ messages in thread
From: Sebastian Riemer @ 2012-07-24 15:39 UTC (permalink / raw)
  To: Linux RAID

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-07-24 15:39 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-23 13:09 smarter md minor search than "find_free_devnum" needed Sebastian Riemer
2012-07-24 15:39 ` Sebastian Riemer

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).