From: Francis Moreau <francis.moro@gmail.com>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org
Subject: Re: Weird behaviour with lsblk and freshly created loop device
Date: Tue, 02 Sep 2014 18:45:58 +0200 [thread overview]
Message-ID: <5405F446.2040202@gmail.com> (raw)
In-Reply-To: <20140902073020.GB21325@x2.net.home>
On 09/02/2014 09:30 AM, Karel Zak wrote:
> On Tue, Sep 02, 2014 at 09:03:45AM +0200, Francis Moreau wrote:
>> It seems that lsblk uses udev to get some block device metadata and asks
>> some others to the kernel. If so, it makes the whole process racy
>> because udev might not have handled the events sent by the kernel yet.
>>
>> I'm not sure why udev is used by default in the first place, what are
>
> * info from udev is accessible for non-root users
> * it's better to scan devices only once on one place only
> * udev is able to gather information from more sources (for example
> libblkid does not provide WWN)
>
>> the benefits ? Using libblkid, at least by default seems the right thing
>> to do.
>>
>> Otherwise maybe lsblk should do the equivalent of 'udevadm settle' to
>> handle correctly freshly created devices ?
>
> That's question, now (because it's not hardcoded to lsblk) everyone is
> able to control this behavior, all you need is to add 'udevadm settle'
> to your use-case.
The question is more why let the user do that ?
If lsblk reports the partitions, shouldn't it do that only when it's
sure to fully have retrieve the partition's metadata ?
BTW, is the user supposed to know that lsblk relies on udev or is this
implementation detail ?
Thanks
next prev parent reply other threads:[~2014-09-02 16:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-01 15:39 Weird behaviour with lsblk and freshly created loop device Francis Moreau
2014-09-01 15:40 ` Francis Moreau
2014-09-01 17:56 ` Karel Zak
2014-09-02 7:03 ` Francis Moreau
2014-09-02 7:30 ` Karel Zak
2014-09-02 16:45 ` Francis Moreau [this message]
2014-09-05 7:45 ` Karel Zak
2014-09-05 8:13 ` Francis Moreau
2014-09-01 19:41 ` Dale R. Worley
2014-09-02 6:54 ` Francis Moreau
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=5405F446.2040202@gmail.com \
--to=francis.moro@gmail.com \
--cc=kzak@redhat.com \
--cc=util-linux@vger.kernel.org \
/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.