All of lore.kernel.org
 help / color / mirror / Atom feed
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: Fri, 05 Sep 2014 10:13:13 +0200	[thread overview]
Message-ID: <54097099.4070505@gmail.com> (raw)
In-Reply-To: <20140905074535.GI21325@x2.net.home>

On 09/05/2014 09:45 AM, Karel Zak wrote:
> On Tue, Sep 02, 2014 at 06:45:58PM +0200, Francis Moreau wrote:
>>> 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 ?
> 
>  because we're talking about small, simple command line util, not
>  about complex high-level UI
>  
>> If lsblk reports the partitions, shouldn't it do that only when it's
>> sure to fully have retrieve the partition's metadata ?
> 
>  if you do not have exclusive access to the device then you cannot be
>  sure at all. All is asynchronous...
> 
>> BTW, is the user supposed to know that lsblk relies on udev or is this
>> implementation detail ?
> 
>  This is very generic system feature, for example if you want to mount
>  a device by /dev/disk/by-* symlinks then nowhere is guarantee that
>  mount(8) is not faster than udev+blkid, etc.
> 
>  Yes, we can add "udevadm settle" functionality into all system utils,
>  but it will increase complexity and degrade performance. So from my
>  point of view it seems better to explain the problem in man page,
>  keep lsblk simple and stupid and assume that users who really care
>  will use "udevadm settle".

Also you might want to add a new option for forcing lsblk to wait for udev ?

Thanks for your answers.

  reply	other threads:[~2014-09-05  8:13 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
2014-09-05  7:45         ` Karel Zak
2014-09-05  8:13           ` Francis Moreau [this message]
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=54097099.4070505@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.