linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luca Boccassi <bluca@debian.org>
To: Christoph Hellwig <hch@infradead.org>,
	Matteo Croce <mcroce@linux.microsoft.com>
Cc: linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Jens Axboe <axboe@kernel.dk>,
	linux-kernel@vger.kernel.org,
	Lennart Poettering <lennart@poettering.net>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Damien Le Moal <damien.lemoal@wdc.com>, Tejun Heo <tj@kernel.org>,
	Javier Gonz??lez <javier@javigon.com>,
	Niklas Cassel <niklas.cassel@wdc.com>,
	Johannes Thumshirn <johannes.thumshirn@wdc.com>,
	Hannes Reinecke <hare@suse.de>,
	Matthew Wilcox <willy@infradead.org>,
	JeffleXu <jefflexu@linux.alibaba.com>
Subject: Re: [PATCH v3 6/6] loop: increment sequence number
Date: Wed, 23 Jun 2021 14:13:25 +0100	[thread overview]
Message-ID: <bbd3d100ee997431b2905838575eb4bdec820ad3.camel@debian.org> (raw)
In-Reply-To: <YNMhwLMr7DiNdqC/@infradead.org>

[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]

On Wed, 2021-06-23 at 12:57 +0100, Christoph Hellwig wrote:
> On Wed, Jun 23, 2021 at 12:58:58PM +0200, Matteo Croce wrote:
> > From: Matteo Croce <mcroce@microsoft.com>
> > 
> > On a very loaded system, if there are many events queued up from multiple
> > attach/detach cycles, it's impossible to match them up with the
> > LOOP_CONFIGURE or LOOP_SET_FD call, since we don't know where the position
> > of our own association in the queue is[1].
> > Not even an empty uevent queue is a reliable indication that we already
> > received the uevent we were waiting for, since with multi-partition block
> > devices each partition's event is queued asynchronously and might be
> > delivered later.
> > 
> > Increment the disk sequence number when setting or changing the backing
> > file, so the userspace knows which backing file generated the event:
> 
> Instead of manually incrementing the sequence here, can we make loop
> generate the DISK_EVENT_MEDIA_CHANGE event on a backing device (aka
> media) change?

Hi,

This was answered in the v1 thread:

https://lore.kernel.org/linux-fsdevel/20210315201331.GA2577561@casper.infradead.org/t/#m8a677028572e826352cbb1e19d1b9c1f3b6bff4b

The fundamental issue is that we'd be back at trying to correlate
events to loopdev instances, which does not work reliably - hence this
patch series. With the new ioctl, we can get the id immediately and
without delay when we create the device, with no possible races. Then
we can handle events reliably, as we can correlate correctly in all
cases.

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-06-23 13:13 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 [this message]
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

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=bbd3d100ee997431b2905838575eb4bdec820ad3.camel@debian.org \
    --to=bluca@debian.org \
    --cc=axboe@kernel.dk \
    --cc=damien.lemoal@wdc.com \
    --cc=hare@suse.de \
    --cc=hch@infradead.org \
    --cc=javier@javigon.com \
    --cc=jefflexu@linux.alibaba.com \
    --cc=johannes.thumshirn@wdc.com \
    --cc=lennart@poettering.net \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcroce@linux.microsoft.com \
    --cc=niklas.cassel@wdc.com \
    --cc=tj@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --subject='Re: [PATCH v3 6/6] loop: increment sequence number' \
    /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

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