archive mirror
 help / color / mirror / Atom feed
From: Lennart Poettering <>
To: Hannes Reinecke <>
Cc: "Matteo Croce" <>,,,
	"Jens Axboe" <>,, "Luca Boccassi" <>,
	"Alexander Viro" <>,
	"Damien Le Moal" <>,
	"Tejun Heo" <>,
	"Javier González" <>,
	"Niklas Cassel" <>,
	"Johannes Thumshirn" <>,
	"Matthew Wilcox" <>,
	"Christoph Hellwig" <>,
	JeffleXu <>
Subject: Re: [PATCH v3 0/6] block: add a sequence number to disks
Date: Wed, 23 Jun 2021 16:07:54 +0200	[thread overview]
Message-ID: <YNNAOpBsruHGCBIX@gardel-login> (raw)
In-Reply-To: <>

On Mi, 23.06.21 14:03, Hannes Reinecke ( wrote:

> On 6/23/21 12:58 PM, Matteo Croce wrote:
> > From: Matteo Croce <>
> >
> > With this series a monotonically increasing number is added to disks,
> > precisely in the genhd struct, and it's exported in sysfs and uevent.
> >
> > This helps the userspace correlate events for devices that reuse the
> > same device, like loop.
> >
> I'm failing to see the point here.
> Apparently you are assuming that there is a userspace tool tracking events,
> and has a need to correlate events related to different instances of the
> disk.
> But if you have an userspace application tracking events, why can't the same
> application track the 'add' and 'remove' events to track the lifetime of the
> devices, and implement its own numbering based on that?
> Why do we need to burden the kernel with this?

The problem is that tracking the "add" and "remove" events is simply
not safely possibly right now for block devices whose names are
frequently reused.

Consider the loopback block device subsystem: whenever some tool wants
a loopback block device it will ask the kernel for one and the kernel
allocates from the bottom, hence /dev/loop0 is the most frequently
used loopback block device. If a large number of concurrently running
programs now repeatedly/quickly allocate/deallocate block devices they
all sooner or later get /dev/loop0. If they now want to watch the
"add" and "remove" uevents for that device for their own use of it
there's a very good chance they'll end up seeing the previous user's
"add" and "remove" events, as there's simply no way to associate the
uevents you see with *your* *own* use of /dev/loop0 right now, and
distinguish them from the uevent that might have been queued from a
prior use of /dev/loop0 and were just slow to be processed.

or to say this differently: loopback devices are named from a very
small, dense pool of names, and are frequently and quickly
reused. uevents are enqeued asynchronously and potentially take a long
time to reach the listeners (after all they have to travel through two
AF_NETLINK sockets and udev) and the only way to match up the device
uses and their uevents is by these kernel device names that are so
useless as a stable identifier.

This not only applies to loopback block devices, but many other block
device subsystems too. For example nbd allocates from the bottom, too,
i.e. /dev/nbd0 is the most like name to be used. And for SCSI devices
too: if you quickly plug/unplug/replug a bunch of USB sticks, you'll
likely always get /dev/sda...


Lennart Poettering, Berlin

      parent reply	other threads:[~2021-06-23 14:08 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-23 10:58 [PATCH v3 0/6] block: add a sequence number to disks Matteo Croce
2021-06-23 10:58 ` [PATCH v3 1/6] block: add disk sequence number Matteo Croce
2021-06-23 11:48   ` Christoph Hellwig
2021-06-23 13:10     ` Matteo Croce
2021-06-23 13:51       ` Lennart Poettering
2021-06-23 14:01         ` Hannes Reinecke
2021-06-23 14:07           ` Luca Boccassi
2021-06-23 14:21             ` Hannes Reinecke
2021-06-23 14:34               ` Luca Boccassi
2021-06-23 14:55               ` Lennart Poettering
2021-06-23 14:12           ` Lennart Poettering
2021-06-23 15:02             ` Hannes Reinecke
2021-06-23 15:34               ` Luca Boccassi
2021-06-23 15:48               ` Lennart Poettering
2021-06-23 14:28       ` Christoph Hellwig
2021-06-23 10:58 ` [PATCH v3 2/6] block: add ioctl to read the " Matteo Croce
2021-06-23 10:58 ` [PATCH v3 3/6] block: refactor sysfs code Matteo Croce
2021-06-23 11:52   ` Christoph Hellwig
2021-06-23 19:03     ` Matteo Croce
2021-06-24  6:12       ` Christoph Hellwig
2021-06-23 10:58 ` [PATCH v3 4/6] block: export diskseq in sysfs Matteo Croce
2021-06-23 10:58 ` [PATCH v3 5/6] block: increment sequence number Matteo Croce
2021-06-23 10:58 ` [PATCH v3 6/6] loop: " Matteo Croce
2021-06-23 11:57   ` Christoph Hellwig
2021-06-23 13:13     ` Luca Boccassi
2021-06-23 14:25       ` Christoph Hellwig
2021-06-23 15:29         ` Lennart Poettering
2021-06-24  6:11           ` Christoph Hellwig
2021-06-23 12:03 ` [PATCH v3 0/6] block: add a sequence number to disks Hannes Reinecke
2021-06-23 12:46   ` Luca Boccassi
2021-06-23 14:07   ` Lennart Poettering [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YNNAOpBsruHGCBIX@gardel-login \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).