Re: [PATCH 0/3] sysfs representation of stacked devices (dm/md)

["Jun'ichi Nomura" <j-nomura@ce.jp.nec.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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/