From: Neil Brown <neilb@suse.de>
To: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: Detecting array parameters
Date: Thu, 17 Jun 2010 15:52:03 +1000 [thread overview]
Message-ID: <20100617155203.0512f6c5@notabene.brown> (raw)
In-Reply-To: <20100612095821.GA14727@lazy.lzy>
On Sat, 12 Jun 2010 11:58:21 +0200
Piergiorgio Sartor <piergiorgio.sartor@nexgo.de> wrote:
> Hi,
>
> thanks for the answer.
>
> The "--export" option is a good advice, unfortunately
> it seems to be quite "conservative" in the amount of
> information, probably it is following some "udev"
> requirements, I guess.
>
> I'll try to explain what I'm trying to do, so, maybe,
> there will be some other good advices.
>
> I've a bunch (10) of different (in size too) HDDs.
> These HDDs are partitioned in a way so that equal
> partitions can compose several RAID-6 arrays.
> So, for example, there are 5x 120GB and 5x 80GB HDDs.
> The firsts are partitioned in 80+40, and there are 2
> RAID-6, one made of 10 80GB "segments" and another
> made of 5 40GB "segments".
> So far, so good.
>
> What I would like to do is a script, which, given an
> HDD as parameter will *properly* add it to the array.
> Where *properly* means, it will partition it properly,
> add the partitions to the respectively arrays, and
> perform, if necessary (non-degraded case) a grow.
>
> My idea would be to go over the several arrays, check
> the partition size, create a partition on the new HDD,
> if possible, then add it and grow the array (if required).
>
> The first step would be to find out the partition size,
> which does seem to be avaialable in:
>
> /sys/class/block/mdX/md/rdX/block/size
>
> I was wondering if this would be the best option to get
> this information, or there are better solutions.
>
> Trying "mdadm -E /dev/sdX" returns also similar information,
> namely the available device size and the offset, which sum
> up to the partition size.
>
> In /sys/class/block/mdX/md/rdX there are also two files,
> carrying similar information: "size" and "offset".
> In this case, strangely, the size is in KiB while the
> offset in sectors (seems a bug to me).
>
> Any suggestions on how to do this in a *correct* way?
>
> Thanks a lot in advance for any advice and, please,
> feel free to ask if you need more information.
I'm not sure there is a "correct" way. Your requirements seem fairly
specific to your system and so you just need to code to match those.
One thought: when deciding how to partition a new device it might make more
sense to look at the partitioning of other devices and try to match that,
rather than to look at md arrays and try to match them.
Maybe. ??
NeilBrown
next prev parent reply other threads:[~2010-06-17 5:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-09 21:13 Detecting array parameters Piergiorgio Sartor
2010-06-09 22:31 ` Neil Brown
2010-06-12 9:58 ` Piergiorgio Sartor
2010-06-17 5:52 ` Neil Brown [this message]
2010-06-10 23:04 ` Leslie Rhorer
2010-06-12 9:59 ` Piergiorgio Sartor
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=20100617155203.0512f6c5@notabene.brown \
--to=neilb@suse.de \
--cc=linux-raid@vger.kernel.org \
--cc=piergiorgio.sartor@nexgo.de \
/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).