From: "Jun'ichi Nomura" <j-nomura@ce.jp.nec.com>
To: Alasdair G Kergon <agk@redhat.com>
Cc: Neil Brown <neilb@suse.de>, Lars Marowsky-Bree <lmb@suse.de>,
device-mapper development <dm-devel@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] sysfs representation of stacked devices (dm/md)
Date: Fri, 17 Feb 2006 20:21:32 -0500 [thread overview]
Message-ID: <43F6769C.5010505@ce.jp.nec.com> (raw)
In-Reply-To: <20060217194249.GO12169@agk.surrey.redhat.com>
Hi,
Alasdair G Kergon wrote:
> I can't speak for the 'mount' code base, but I don't think it'll
> make any significant difference to LVM2 - we'd still have to do
> all the same device scanning as we do now because we have to be
> aware of md devices defined in on-disk metadata regardless of
> whether or not the kernel knows about them at the time the
> command is run.
Actually, as you say, LVM2 already does the relationship analysis
correctly by itself. So it's not 'good' example...
The point was that dm and md have similar dependency
structure but currently we have to scan all devices to
find out the upward relationship using different method
for dm and md.
>>thus we only need to check "holders" directory of the device
>>to decide whether the device is used by dm/md.
>>Also we can walk down the "slaves" directories to collect
>>the devices conposing the given dm/md device.
>
> For device-mapper devices, 'dmsetup deps' and ls --tree already
> gives you this information reasonably efficiently.
Speaking about the efficiency, 'dmsetup ls --tree' works well.
However, I haven't yet found a efficient way to implement
'dmsetup info --tree -o inverted dm-0', for example.
Deps ioctl provides downward information for a given dm device
but there is no method for upward information.
Providing reverse-deps ioctl in dm may be alternative solution.
But it still doesn't provide the holders of non-dm devices.
So I feel sysfs solution is appealing.
> Would others find the proposal useful for non-dm devices?
I would appreciate comments from others as well.
> And rather than adding code just to dm and md, would it be better
> to implement it by enhancing bd_claim()?
It may be possible if I can extend the bd_claim to accept
additional parameter because all dm devices use same 'holder'
signature for bd_claim but actual owner of the claim should
be determined to create symlinks.
--
Jun'ichi Nomura, NEC Solutions (America), Inc.
next prev parent reply other threads:[~2006-02-18 1:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-17 18:00 [PATCH 0/3] sysfs representation of stacked devices (dm/md) Jun'ichi Nomura
2006-02-17 18:01 ` [PATCH 1/3] sysfs representation of stacked devices (dm/md common) Jun'ichi Nomura
2006-02-17 18:44 ` Alasdair G Kergon
2006-02-18 1:03 ` Jun'ichi Nomura
2006-02-18 19:50 ` Alasdair G Kergon
2006-02-21 15:33 ` Jun'ichi Nomura
2006-02-21 15:52 ` Alasdair G Kergon
2006-02-17 18:03 ` [PATCH 2/3] sysfs representation of stacked devices (dm) Jun'ichi Nomura
2006-02-17 18:05 ` [PATCH 3/3] sysfs representation of stacked devices (md) Jun'ichi Nomura
2006-02-17 19:42 ` [PATCH 0/3] sysfs representation of stacked devices (dm/md) Alasdair G Kergon
2006-02-18 1:21 ` Jun'ichi Nomura [this message]
2006-02-18 19:53 ` Alasdair G Kergon
2006-02-21 15:34 ` Jun'ichi Nomura
2006-02-18 6:06 ` Kyle Moffett
2006-02-19 22:04 ` Neil Brown
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=43F6769C.5010505@ce.jp.nec.com \
--to=j-nomura@ce.jp.nec.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lmb@suse.de \
--cc=neilb@suse.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