On 01/13/11 09:23, Milan Broz wrote:
> On 01/12/2011 06:34 PM, Valdis.Kletnieks@vt.edu wrote:
>> Seen in a boot of yesterday's linux-next. The 'W' flag was due to the
>> already-reported 'WARNING: at kernel/workqueue.c:1202 worker_enter_idle'.
>> Not sure if it's a block_dev or dm/LVM issue, so I'm cc:'ing both groups. I wonder
>> if the fact I still have 'CONFIG_DEVTMPFS=n' is involved (it's apparently ticking off
>> dracut before and after the warning).
>>
>> [ 16.840333] dracut: Found volume group "vg_blackice" using metadata type lvm2
>> [ 16.892282] dracut: The link /dev/vg_blackice/opt should had been created by udev but it was not found. Falling back to direct link creation.
>> [ 16.912627] ------------[ cut here ]------------
>> [ 16.912635] WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
>
> That seems to be
> WARN_ON_ONCE(!bdev->bd_holder || bdev->bd_holder_disk);
> added in patch
> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=e09b457bdb7e8d23fc54dcef09 30ac697d8de895
> "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.

Thanks,
--
Jun'ichi Nomura, NEC Corporation

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

On 01/13/2011 12:06 PM, Tejun Heo wrote:
> 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.

I am not sure if I understand it correctly, but multiple holders/slaves
links are very useful in userspace to present device dependences.

We just implemented lsblk command in util-linux which simple prints
tree according to these links, so dependendes of DM/MD/whatever devices
can be printed without using any system specific callbacks, just using
sysfs. See http://karelzak.blogspot.com/2010/12/lsblk8.html

Whatever changes are needed, please keep this functionality, it can be useful.

Thanks,
Milan

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

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).

Hi,

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).

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

Milan

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

On 01/13/2011 03:11 PM, Tejun Heo wrote:

> 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.

Maybe, but this was not invented in DM/MD camp:-)
Probably Kay or Greg can answer why it was done this way?

For DM it just added links to be proper user of it, see
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f165921df46a977e3561f1bd9f1 3a348441486d1

Anyway, it is /sys/block - so it represents block devices.

If btrfs internally creates some virtual _block_ device for its pool, it should
present it here too with slaves/holders. If not, why it should create any links there?

Milan

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

Thu Jan 13 15:30:02 2011
Return-path: <advisory-board-bounces@lists.fedoraproject.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Thu, 13 Jan 2011 15:22:19 +0200
Received: from bastion02.fedoraproject.org ([209.132.181.3]:33442 helo=bastion.fedoraproject.org)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <advisory-board-bounces@lists.fedoraproject.org>)
id 1PdN87-0004J7-PO
for tom@linux-archive.org; Thu, 13 Jan 2011 15:22:19 +0200
Received: from lists.fedoraproject.org (collab1.vpn.fedoraproject.org [192.168.1.21])
by bastion02.phx2.fedoraproject.org (Postfix) with ESMTP id 5017E10F985;
Thu, 13 Jan 2011 14:27:15 +0000 (UTC)
Received: from collab1.fedoraproject.org (localhost.localdomain [127.0.0.1])
by lists.fedoraproject.org (Postfix) with ESMTP id C936E3267DD;
Thu, 13 Jan 2011 14:27:14 +0000 (UTC)
X-Original-To: advisory-board@lists.fedoraproject.org
Delivered-To: advisory-board@lists.fedoraproject.org
Received: from smtp-mm03.fedoraproject.org (smtp-mm3.fedoraproject.org
[152.46.7.226])
by lists.fedoraproject.org (Postfix) with ESMTP id D8534326743
for <advisory-board@lists.fedoraproject.org>;
Thu, 13 Jan 2011 14:27:12 +0000 (UTC)
Received: from mail-ey0-f173.google.com (mail-ey0-f173.google.com
[209.85.215.173])
by smtp-mm03.fedoraproject.org (Postfix) with ESMTP id 65CA137D67
for <advisory-board@lists.fedoraproject.org>;
Thu, 13 Jan 2011 14:27:12 +0000 (UTC)
Received: by eyg7 with SMTP id 7so834905eyg.32
for <advisory-board@lists.fedoraproject.org>;
Thu, 13 Jan 2011 06:27:11 -0800 (PST)
Received: by 10.213.31.132 with SMTP id y4mr2398018ebc.1.1294928831511;
Thu, 13 Jan 2011 06:27:11 -0800 (PST)
Received: from valhalla.rhi.hi.is (valhalla.rhi.hi.is [130.208.69.191])
by mx.google.com with ESMTPS id t50sm90552eeh.6.2011.01.13.06.27.10
(version=SSLv3 cipher=RC4-MD5); Thu, 13 Jan 2011 06:27:10 -0800 (PST)
Message-ID: <4D2F0BBD.4050801@gmail.com>
Date: Thu, 13 Jan 2011 14:27:09 +0000
From: =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
<johannbg@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14
Thunderbird/3.1.7
MIME-Version: 1.0
To: advisory-board@lists.fedoraproject.org
Subject: Re: The future of optical media within the project.
References: <4D2DE60C.7000408@gmail.com> <1294854201.2091.152.camel@Brigid> <4D2DEEA3.4050906@freenet.de> <1294880741.18742.670.camel@constitution.bos.jonma sters.org> <4D2E5DD0.3090409@redhat.com> <1294889258.18742.680.camel@constitution.bos.jonma sters.org> <4D2EC717.8070906@gmail.com> <1294911939.18742.729.camel@constitution.bos.jonma sters.org> <4D2ED6BF.1070801@gmail.com> <4D2EE793.2070601@gmail.com> <4D2EF7B2.3030806@gmail.com>
<4D2F0610.2060308@gmail.com>
In-Reply-To: <4D2F0610.2060308@gmail.com>
X-BeenThere: advisory-board@lists.fedoraproject.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Fedora community advisory board
<advisory-board@lists.fedoraproject.org>
List-Id: Fedora community advisory board
<advisory-board.lists.fedoraproject.org>
List-Unsubscribe: <https://admin.fedoraproject.org/mailman/listinfo/advisory-board>,
<mailto:advisory-board-request@lists.fedoraproject.org?subject=unsubscrib e>
List-Archive: <http://lists.fedoraproject.org/pipermail/advisory-board>
List-Post: <mailto:advisory-board@lists.fedoraproject.org>
List-Help: <mailto:advisory-board-request@lists.fedoraproject.org?subject=help>
List-Subscribe: <https://admin.fedoraproject.org/mailman/listinfo/advisory-board>,
<mailto:advisory-board-request@lists.fedoraproject.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: advisory-board-bounces@lists.fedoraproject.org
Errors-To: advisory-board-bounces@lists.fedoraproject.org

T24gMDEvMTMvMjAxMSAwMjowMiBQTSwgRnJhbmsgTXVycGh5IH dyb3RlOgo+IE9uIDEzLzAxLzEx
IDEzOjAxLCAiSsOzaGFubiBCLiBHdcOwbXVuZHNzb24iIHdyb3 RlOgo+IDxzbmlwPgo+PiA+ICBJ
dCBhbHNvIGJlZ3MgdGhlIHF1ZXN0aW9uIGlmIEZlZG9yYSAiRG VmYXVsdCIgaXMgc3VpdGFibGUg
Zm9yIHRob3NlCj4+ID4gIHBlcnNvbnMgZXQgYWwgYW5kIHRoZX kgc2hvdWxkIGJlIHVzaW5nIGxp
Z2h0ZXIgZGVzdG9wIGVudmlyb21lbnQgaW5zdGVhZAo+PiA+IC BsaWtlIExYREUgb3IgWEZDRQo+
IEFyZSB0aGV5IG5vdCBvbiBhIENEPwoKVGhlaXIgaXNvIHNpem UgZmFsbHMgd2l0aGluIENEIHNp
emUgeWVzIGFuZCB0aGVpciB0YXJnZXQgYXVkaWVuY2UgYXJlIA pwZW9wbGUgdGhhdCBhcmUgcnVu
bmluZyBvbGQgaGFyZHdhcmUgYnV0IG90aGVyIERFIGxpa2UgR2 5vbWUgYW5kIEtERSAKc2hvdWxk
IG5vdCBiZSBmb3JjZWQgdG8gdGhhdCBzaXplIGltYWdlIGlmIH RoZXkgd2FudCB0byBkZWxpdmVy
ZXIgYmV0dGVyIApvdXQgb2YgdGhlIGJveCBleHBlcmllbmNlIG ZvciB0aGVpciB0YXJnZXQgYXVk
aWVuY2UgYW5kIHRoZXkgd291bGQgaGF2ZSAKYSBwbGVudHkgb2 Ygcm9vbSB0byBkbyBzbyB3aXRo
IGEgbGFyZ2VyIGlzbyB0aGF0IGNvdWxkIGJlIGJ1cm5lZCBvbi BEVkQgCm9yIHNvbWUgMUcgb3Ig
Mkcgb3IgNEcgdXNiIGZsYXNoIGRyaXZlIGRlcGVuZGluZyBvbi B3aGF0IHRoZXkgd2VyZSAKYWlt
aW5nIGF0LgoKSkJHCl9fX19fX19fX19fX19fX19fX19fX19fX1 9fX19fX19fX19fX19fX19fX19f
X19fCmFkdmlzb3J5LWJvYXJkIG1haWxpbmcgbGlzdAphZHZpc2 9yeS1ib2FyZEBsaXN0cy5mZWRv
cmFwcm9qZWN0Lm9yZwpodHRwczovL2FkbWluLmZlZG9yYXByb2 plY3Qub3JnL21haWxtYW4vbGlz
dGluZm8vYWR2aXNvcnktYm9hcmQ=

Hello,

On Thu, Jan 13, 2011 at 3:25 PM, Milan Broz <mbroz@redhat.com> wrote:
> Maybe, but this was not invented in DM/MD camp:-)
> Probably Kay or Greg can answer why it was done this way?

Let's not play the dig the history and blame game if possible. We
(including me, of course) all did a lot of horrible things in the
past. :-)

> For DM it just added links to be proper user of it, see
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f165921df46a977e3561f1bd9f1 3a348441486d1
>
> Anyway, it is /sys/block - so it represents block devices.
>
> If btrfs internally creates some virtual _block_ device for its pool, it should
> present it here too with slaves/holders. If not, why it should create any links there?

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.

Thanks.

--
tejun

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

On Thu, Jan 13, 2011 at 15:30, Tejun Heo <tj@kernel.org> wrote:
> On Thu, Jan 13, 2011 at 3:25 PM, Milan Broz <mbroz@redhat.com> wrote:
>> Maybe, but this was not invented in DM/MD camp:-)
>> Probably Kay or Greg can answer why it was done this way?

It's not from Greg or Kay. It just appeared some day in the context of dm.

And yes, symlinks *look* nice and simple for the outside, but they are
not, and have all sorts of problems like non-atomic updates, make it
impossible to ever rename a device (as long as they copy the device
name), and and and .... we should not add more of this.

>> If btrfs internally creates some virtual _block_ device for its pool, it should
>> present it here too with slaves/holders. If not, why it should create any links there?
>
> 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.

Btrfs does not use any blockdev as the master for good reason, and it
can never map its slaves inside of /sys/block. Simple meta-blockdevs
like md/dm just don't fit into modern requirements of a filesystem
(directory snapshots, directory subvolumes, complex raids, hassle-free
resizing, ...) -- hence btrfs is much more like a network-filesystem
mount than a stream of blocks like a disk, and does not fit at all
into this model.

Kay

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

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?

-- Ted


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

On 01/13/2011 03:30 PM, Tejun Heo wrote:

Hi,

>> Anyway, it is /sys/block - so it represents block devices.
>>
>> If btrfs internally creates some virtual _block_ device for its pool, it should
>> present it here too with slaves/holders. If not, why it should create any links there?
>
> 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, then it is not optimal for fs and should it be separated?
There is also /sys/fs now...

I think represent dependences of block devices in some generic (and exactly defined)
way is useful. So if there is something missing, lets define it properly.

The whole idea behind lsblk was practical: we responded many questions why
"device is busy" and what keeps it open in stacked subsystem.
Just try fdisk, mdadm, dmsetup table, losetup -a, kpartx, cryptsetup, etc ...

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.

Thanks,
Milan

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

On 01/13/2011 03:43 PM, Kay Sievers wrote:

>> On Thu, Jan 13, 2011 at 3:25 PM, Milan Broz <mbroz@redhat.com> wrote:
>>> Maybe, but this was not invented in DM/MD camp:-)
>>> Probably Kay or Greg can answer why it was done this way?
>
> It's not from Greg or Kay. It just appeared some day in the context of dm.

ah, then sorry, I am just confused:-)
But DM does not need it for operation at all so it must had some other reason.
(We have dmsetup ls --tree using dm-ioctls for years.)

> And yes, symlinks *look* nice and simple for the outside, but they are
> not, and have all sorts of problems like non-atomic updates, make it
> impossible to ever rename a device (as long as they copy the device
> name), and and and .... we should not add more of this.

Yes, I agree, if there is better way, let's switch to that.

Milan

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

On Thu, Jan 13, 2011 at 16:59, Karel Zak <kzak@redhat.com> wrote:
> On Thu, Jan 13, 2011 at 03:43:38PM +0100, Kay Sievers wrote:
>> On Thu, Jan 13, 2011 at 15:30, Tejun Heo <tj@kernel.org> wrote:
>> > On Thu, Jan 13, 2011 at 3:25 PM, Milan Broz <mbroz@redhat.com> wrote:
>> >> Maybe, but this was not invented in DM/MD camp:-)
>> >> Probably Kay or Greg can answer why it was done this way?
>>
>> It's not from Greg or Kay. It just appeared some day in the context of dm.
>>
>> And yes, symlinks *look* nice and simple for the outside, but they are
>> not, and have all sorts of problems like non-atomic updates, make it
>
> *Sounds like sysfs implementation problem, right?

It's a normal multi-file problem. It can by-definition not be atomic
without doing really weird locking things.

> *If there is noway to fix sysfs then we can add a generic ioctl or
> */sys/block/<device>/{slave,holder}_list files with list of
> *holders/slaves.

Yeah, we've been there with the btrfs problem. For btrfs it woud
probably need to be something statfs()-like.

> *But please, don't force userspace to use *claimer-specific*
> *methods to answer *generic questions* like slave/holder dependencies
> *between devices.

The links exist only for dm and md so far, I think. It's the classical
multiple-parents-in-a-tree problem. We have that for bonded network
devices and some IO buses too. There is no nice representation for
these reversed-trees-in-the-tree so far.

Kay

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