Hello,

On Thu, Jan 13, 2011 at 11:19:21AM +0900, Jun'ichi Nomura wrote:
> > "block: simplify holder symlink handling"
> >
> > dm linear just claims device in table constructor, I don't think it is bug in DM code.
>
> The patch assumes only one holder disk for a claimed dev, which is not true.
> E.g. if there are multiple LVs on a PV.
>
> In addition to that, since claiming is done in table constructor,
> there can be 2 claim instances for a slave/holder pair at a time
> when you load a table while there's already an active one.
> E.g. if you do lvresize.
> We need consideration for this, too.

Urgh... gees, so there actually was a user using all that cruft.
Sorry about the breakage, I'll see how multiple symlinks can be
restored. I'm curious why this was added at all tho. What was the
rationalization? It's not like two subsystems can share the same
block device so marking the currently owning subsystem should have
been enough at the block layer. There is no reason for block devices
to present information which is of no use to itself. All that's
necessary is "this is taken by dm or md for more information, query
those". dm and md need their own conf/representation layer anyway.

Thanks.

--
tejun

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Hello,

On Thu, Jan 13, 2011 at 01:27:01PM +0100, Karel Zak wrote:
> We also use holders/slaves links in libblkid to evaluate dependencies
> between devices (since 2008).
>
> > Whatever changes are needed, please keep this functionality, it
> > can be useful.
>
> Definitely.

Yeah, sure, it's not like I can afford to avoid fixing it at this
point anyway, but I still want to point out it's at the wrong layer
and shouldn't have been added like this, really. If you want blkid to
identify it, the proper thing to do would be querying blk device for
the claimer and then use claimer-specific method to query them. It's
not like the current method would make sense for btrfs or whatnot.

So, yeap, I definitely am fixing it but let's not do things like this
in the future.

Thanks.

--
tejun

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Hello, Karel.

On Thu, Jan 13, 2011 at 02:26:37PM +0100, Karel Zak wrote:
> > Yeah, sure, it's not like I can afford to avoid fixing it at this
> > point anyway, but I still want to point out it's at the wrong layer
> > and shouldn't have been added like this, really. If you want blkid to
> > identify it, the proper thing to do would be querying blk device for
> > the claimer and then use claimer-specific method to query them. It's
>
> It seems that dependencies (holders/slaves) between devices is pretty
> generic thing. Why do you think that we need claimer-specific method?
> The /sys filesystem is better that ictls in many ways.

Because sysfs is already complex enough without representing
dependency information without strictly defined strcture in it. It's
for exporting the device tree to users. We have developed interesting
ways to exploit it but it generally has proven to be a bad idea to add
symlinks without clearly defined structure beneath it. People end up
using them differently and often they don't understand how the kobject
sysfs things are wired and it ends up with a lot of cruft exporting
something which is designed by small number of people without really
considering what's going on in the rest of the hierarchy.

> > not like the current method would make sense for btrfs or whatnot.
>
> Could you be more verbose, please?

If the symlinkery was something which could properly replace
configuration and query, sure, let's standardize it and share it among
all possible claimers of block devices, but it's not. md, dm, btrfs
need to export and process way more information than can be represnted
in these symlinks and it's there more as a pretty thing than anything
which is actually necessary and useful. And the original
implementation directly played with kobjects (in an unnecessarily
complicated way too) and allowed any kobject to be linked. Things
like that just never end up pretty.

So, just don't do it. Sysfs is for device hierarchy. Don't try to
shove pretty looking things there (unless it's something widely agreed
on and necessary, of course).

Thanks.

--
tejun

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

On Thu, Jan 13, 2011 at 02:37:22PM +0100, Tejun Heo wrote:
> > It seems that dependencies (holders/slaves) between devices is pretty
> > generic thing. Why do you think that we need claimer-specific method?
> > The /sys filesystem is better that ictls in many ways.

Also, one more thing. In btrfs, there's no block device for the
master device. You can add the slaves directory somewhere and your
choice would be as good as any other's but it just will not be generic
while being superflous exactly the same way it's superflous for md and
dm devices.

Thanks.

--
tejun

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Hello,

On Thu, Jan 13, 2011 at 02:58:23PM +0100, Milan Broz wrote:
> On 01/13/2011 02:37 PM, Tejun Heo wrote:
>
> > So, just don't do it. Sysfs is for device hierarchy. Don't try to
> > shove pretty looking things there (unless it's something widely agreed
> > on and necessary, of course).
>
> I think that it is exactly what holders/slaves do - displaying device
> hierarchy. So application can check which underlying device are related
> and ask them for more info if needed (=> with system specific call,
> it can be simple sysfs attribute, ioctl, whatever).

Yeah, sure but in a completely unrestrained and non-standard way.
First of all, it wasn't even necessary to begin with and I don't
really see anyone else other than md/dm using it. I mean, where are
you gonna you put that slaves directory? Sure you can put it
somewhere but really it would be just that - somewhere. All this
doesn't even matter. It wasn't even necessary to begin with.

> So the only request here is to keep these symlinks correct, nothing more.
> Or am I missing anything?

Yeah, I'm fixing that. Don't worry. I just wanna say it wasn't such
a brilliant idea to add it in the first place and hope that people
would restrain from doing similar things in the future.

So, as a general rule, when in doubt, just create an attribute. Let's
refrain from custom symlinkery in sysfs, please. In this case too, a
holder attribute containing strings like ext[3|4], md, dm or whatnot
would have been _much_ simpler and actually more useful.

Thank you.

--
tejun

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

On Thu, 13 Jan 2011 09:45:54 -0500 Theodore Tso <tytso@MIT.EDU> wrote:

>
> On Jan 13, 2011, at 9:30 AM, Tejun Heo wrote:
> >>
> >
> > Yeah, that's the most bothering part for me. The biggest customers of
> > bd_claim are filesystems and all these custom symlinkeries don't do
> > nothing for them. It just doesn't make a whole lot of sense to me.
> >
>
> Well, if there's better way to do things, we can send patches to libblkid to switch away from using sysfs, assuming it's using a new enough kernel.
>
> The primary problem that we're trying to solve is to know whether a particular device contains a file system that should potentially mounted (or fsck'ed, or used as a external journal device, etc.)
>
> If the file system is located on a raid 0 device created using devicemapper, the first physical block device could look like a file system. So what we want is a very easy way of determining, "is this device being used by the device mapper layer"? If it is, then it's probably not the droids we are looking for. We'll keep looking at the rest of the block devices in the system, and when we find the dm-concatenated devices, we can properly identify it.
>
> Can you suggest a better way doing what it is we need to do?

open(O_EXCL) will fail on a block device if it is being used by anything else
- a filesystem or a dm target or an md array or ....

So if the *only* thing you want is "is this currently an active part of
something else", then O_EXCL works since 2.6.0 (I think).

NeilBrown

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

On Fri, Jan 14, 2011 at 07:18:58AM +1100, NeilBrown wrote:
>
> open(O_EXCL) will fail on a block device if it is being used by anything else
> - a filesystem or a dm target or an md array or ....
>
> So if the *only* thing you want is "is this currently an active part of
> something else", then O_EXCL works since 2.6.0 (I think).

Unfortunately, that won't distinguish between a currently active file
system, and a device which is being used by a dm target, which is what
we want to do.

- Ted

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Hello, Ted, Neil.

On Thu, Jan 13, 2011 at 03:41:45PM -0500, Ted Ts'o wrote:
> On Fri, Jan 14, 2011 at 07:18:58AM +1100, NeilBrown wrote:
> >
> > open(O_EXCL) will fail on a block device if it is being used by anything else
> > - a filesystem or a dm target or an md array or ....
> >
> > So if the *only* thing you want is "is this currently an active part of
> > something else", then O_EXCL works since 2.6.0 (I think).
>
> Unfortunately, that won't distinguish between a currently active file
> system, and a device which is being used by a dm target, which is what
> we want to do.

Hmmm... that's already possible with the existing holders symlinks,
right? As Kay said in another message, I don't think we can do
anything about the symlinks at this point. It already has userland
users, so we'll have to maintain them and there's no reason to create
something else for the same functionality.

It's silly that there's no way to tell whether the device is mounted
from a given block device but then again we've been working around it
by reverse mapping it till now so unless there's a new requirement
maybe it's okay as it is now.

Ideally, it would have been nice and more fitting with the whole bd
claim API if we just exported single attribute which identifies the
current holder supplied at the time of claiming (just the kernel
identifier in string), so that we can forward-map the exclusive opener
in general instead of having to reverse-map it for everything other
than md/dm.

Thank you.

--
tejun

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Hello,

On Thu, Jan 13, 2011 at 03:49:50PM +0100, Milan Broz wrote:
> So listing block device tree using ONE interface (sysfs) to check
> and display device tree for ALL subsystems seems to be good idea for
> me. In this exactly defined case.
>
> I am not saying that symlinks are perfect, just that generic
> interface here is not superfluous.

I'm not saying finding out the current owner is superflous. That
actually is useful but what's implemented now doesn't satisfy that in
any generic manner. It only works for md/dm and is designed in such
way that it can't be used out of that scope.

So, it's only useful for md/dm and for those two cases it tries to
show information which doesn't really belong there using an overly
complex mechanism.

Block device open allows _nesting_ by the claiming device. It is
never meant to track different nested claimers and it shows in the
implementation and interface. The holder tracking doesn't fit
anywhere. It's a completely separate piece of logic which doesn't mix
with anything else in the block layer.

If you consider its only user - dm-table, the whole picture is
somewhat uglier. dm-table tracks how it uses block devices but only
within a single target, so there are two separate layers of reference
counting going on. This again is caused by the above stated design
inconsistency.

As block device only considers single claimer which doesn't have to be
another device, the owner naturally should have been something which
only points to single in-kernel entity in a way which doesn't require
link to another sysfs entry.

Karel pointed out that having different methods between md and dm
would be silly; however, that is a problem which should be solved
between dm and md and actually is a quite artificial problem (or
solution). It only exists because dm and md do very similar things in
many cases. A block device can be used by many more things which are
way out of the scope which can be represented in the sysfs hierarchy.
It simply is impossible to represent that relationship with symlinks
under block device sysfs hierarchy.

Thank you.

--
tejun

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

On Fri, Jan 14, 2011 at 05:20:22PM +0100, Tejun Heo wrote:
>
> Hmmm... that's already possible with the existing holders symlinks,
> right? As Kay said in another message, I don't think we can do
> anything about the symlinks at this point. It already has userland
> users, so we'll have to maintain them and there's no reason to create
> something else for the same functionality.

Yes, agreed. My point was that if we have a better system, we could
migrate blkid and other users to new interface, and maybe in a few
years, we can deprecate that interface. So we do have to maintain
them for at least the medium term, but that shouldn't stop us from
divising a better interface, and then gradually migrating systems to
use that newer and better interface.

- Ted

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel