All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: Bug? Determining the holders of partitions shadowed by dm-multipath.
Date: Wed, 11 Feb 2009 09:18:55 +0100	[thread overview]
Message-ID: <499289EF.80305@suse.de> (raw)
In-Reply-To: <20090211080334.GH9512@mail.oracle.com>

Hi Joel,

Joel Becker wrote:
> On Wed, Feb 11, 2009 at 08:32:20AM +0100, Hannes Reinecke wrote:
>> Hi Joel,
>>
[ .. ]
>> Well, yes.
>> That's because you have _two_ parent-child relationship in sysfs.
>>
>> The one (as you already noted) is the holders / slaves directories in sysfs.
>> However, partitions are handled differently; they are listed under
>>
>> /sys/block/sda/sda2
>>
>> (note the subdir) and do not appear under holders / slaves. So the correct algorithm
>> is to
>> a) check the holders / slaves
>> and
>> b) check if the parent directory starts with the same name and if so, check for
>> the holders / slaves relationship there.
> 
> 	Why not just setup holders in sda2?  It's held, after all.
> It's just very counterintuitive to look at an empty holders and discover
> that it's empty yet held.

We don't need to, as sda2 is by definition held by sda.
So adding a 'holders' directory here which just points to the parent
directory is quite pointless.
(And it will become even more absurd for the 'slaves' directory in sda ...)

Remember, partitions precede the holders / slaves abstraction by years.
The former abstraction was only introduced to map device-mapper / md
device relationships onto sysfs.

> 	Btw, do we absolutely guarantee that all block devices, forever,
> will have partitions in sysfs named
> "/sys/block/<parent>/<parent><more>"?
> 
Yes, quite so. This is one relationship I would _not_ touch.

However, I'm all for it to optionally disable the partitions detection
within the kernel and have it all done in userspace by kpartx.
Then we'll be getting the 'holders/slave' relationship automatically
and won't be bothered by a separate partition scheme anymore.

Looks like it's time to dig out the patch again.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

      reply	other threads:[~2009-02-11  8:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-10  0:49 Bug? Determining the holders of partitions shadowed by dm-multipath Joel Becker
2009-02-10 14:49 ` Romanowski, John (OFT)
2009-02-10 21:32   ` Joel Becker
2009-02-11  1:14     ` Romanowski, John (OFT)
2009-02-11  7:32     ` Hannes Reinecke
2009-02-11  8:03       ` Joel Becker
2009-02-11  8:18         ` Hannes Reinecke [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=499289EF.80305@suse.de \
    --to=hare@suse.de \
    --cc=dm-devel@redhat.com \
    /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.