archive mirror
 help / color / mirror / Atom feed
From: Lennart Poettering <>
To: Matthew Wilcox <>
Cc: "Matteo Croce" <>,,,, "Luca Boccassi" <>,
	"Jens Axboe" <>,
	"Alexander Viro" <>,
	"Damien Le Moal" <>,
	"Tejun Heo" <>,
	"Javier González" <>,
	"Niklas Cassel" <>,
	"Johannes Thumshirn" <>,
	"Hannes Reinecke" <>
Subject: Re: [PATCH -next 1/5] block: add disk sequence number
Date: Thu, 25 Mar 2021 21:52:21 +0100	[thread overview]
Message-ID: <YFz4BabOiNDcnHIm@gardel-login> (raw)
In-Reply-To: <>

On Mo, 15.03.21 20:18, Matthew Wilcox ( wrote:
> On Mon, Mar 15, 2021 at 09:02:38PM +0100, Matteo Croce wrote:
> > From: Matteo Croce <>
> >
> > Add a sequence number to the disk devices. This number is put in the
> > uevent so userspace can correlate events when a driver reuses a device,
> > like the loop one.
> Should this be documented as monotonically increasing?

I think this would be great. My usecase for this would be to match up
uevents with loopback block device attachments, because that's
basically impossible right now: you attach a loopback device to a
file, and then wait for the relevant uevents to happen, for all
partitions but you cannot do this safely right now, since loopback
block devices are heavily reused in many scenarios so you never know
if a uevent is from the attachment you created yourself or from a
previous one — or even already for the next.

If this would be documented as being monotonic this would be excellent
for this usecase: if you know that your own use of a specific loopback
device got seqno x then you know that if you see uevents for seqno < x
it makes sense to wait longer, but when you see seqno > x then you
know it's too late, somehow you lost uevents and hsould abort.

Hence: for my usecase having this strictly monotonic, and thus being
able to *order* attachments across all areas where the seqno appears
would be absolutely excellent and make this as robust as it possibly
could be.

> I think this is actually a media identifier.  Consider (if you will)
> a floppy disc.  Back when such things were common, it was possible
> with personal computers of the era to have multiple floppy discs "in
> play" and be prompted to insert them as needed.  So shouldn't it be
> possible to support something similar here -- you're really removing
> the media from the loop device.  With a monotonically increasing
> number, you're always destroying the media when you remove it, but
> in principle, it should be possible to reinsert the same media and
> have the same media identifier number.

This would be useless for my usecase, we don't really care for the
precise file being attached (which is queriable via sysfs anyway), but
we want to match up our use of the device with the uevents it
generates on itself and decendend partition block devices.

Hence: for my usecase I want something that recognizes *attachments*
and not media. If i attach the same media 3 times i want to be able to
discern the three times. And more importantly: if I attach it once and
someone else also once, then I don't want to get confused by that and
be able ti distinguish both attachments.

Morevoer, I am not even sure what media identifier would mean: if you
have one image and then copy it, is that still the same image? in your
model, should that have distinct ids? or the same, because it is from
the same common original version? and if i then modify one, what
happens then?

Finally, media usually comes with ids anyway. i.e. file systems have
uuids, GPT partition tables have meda uuids. The infrastructure for
that already exists. What we need really is something that allows us
to track attachments, not media.

(That said, I think it would make sense to bump the IDs not only on
explicit user-induced reattachments, but also when media is replaced,
i.e. bump it more often than not)


Lennart Poettering, Berlin

  parent reply	other threads:[~2021-03-25 20:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15 20:02 [PATCH -next 0/5] block: add a sequence number to disks Matteo Croce
2021-03-15 20:02 ` [PATCH -next 1/5] block: add disk sequence number Matteo Croce
2021-03-15 20:18   ` Matthew Wilcox
2021-03-15 21:04     ` Matthew Wilcox
2021-03-15 21:32       ` Lennart Poettering
2021-03-25 17:29       ` Matteo Croce
2021-03-26  8:00         ` Hannes Reinecke
2021-03-25 20:58       ` Lennart Poettering
2021-03-16 14:13     ` Christoph Hellwig
2021-04-20 20:12       ` Lennart Poettering
2021-03-25 20:52     ` Lennart Poettering [this message]
2021-03-16  1:44   ` JeffleXu
2021-03-23 17:43     ` Matteo Croce
2021-03-15 20:02 ` [PATCH -next 2/5] block: add ioctl to read the " Matteo Croce
2021-03-15 20:13   ` Matthew Wilcox
2021-03-15 20:17     ` Damien Le Moal
2021-03-15 20:34     ` Matteo Croce
2021-03-15 20:02 ` [PATCH -next 3/5] block: refactor sysfs code Matteo Croce
2021-03-15 20:02 ` [PATCH -next 4/5] block: export diskseq in sysfs Matteo Croce
2021-03-15 20:02 ` [PATCH -next 5/5] loop: increment sequence number Matteo Croce

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=YFz4BabOiNDcnHIm@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).