linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Lennart Poettering <mzxreary@0pointer.de>
Cc: Christoph Hellwig <hch@infradead.org>,
	Luca Boccassi <bluca@debian.org>,
	Matteo Croce <mcroce@linux.microsoft.com>,
	linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Jens Axboe <axboe@kernel.dk>,
	linux-kernel@vger.kernel.org,
	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: Thu, 24 Jun 2021 07:11:25 +0100	[thread overview]
Message-ID: <YNQiDROADP1jGXCJ@infradead.org> (raw)
In-Reply-To: <YNNTTUYRlpXDqMgX@gardel-login>

On Wed, Jun 23, 2021 at 05:29:17PM +0200, Lennart Poettering wrote:
> I am not sure I grok your point.

You don't.

> 1. First of all, loopback devices currently don't hook into the media
>    change logic (which so far is focussed on time-based polling
>    actually, for both CDs and floppies).

And that is the whole problem.  We need to first fix loop devices to
hook into the existing mechanism to report media changes.  We can then
enhance that mechanism to be more suitable to loop (avoid the polling)
and userspace (add a sequence number).  But if we don't have the basic
agreement to fully integreat loop with the existing way that the kernel
reports media change we don't even need to discuss this series and can
just ignore it, as it simply won't be acceptable.

>    Adding this would change
>    semantics visibly to userspace (since userspace would suddenly see
>    another action=change + DISK_MEDIA_CHANGE=1 uevent suddenly that it
>    needs to handle correctly).

Yes, and that is a good thing as loop is currently completely broken
in this respect.

> 2. We want seqnums to be allocated for devices not only when doing
>    media change (e.g. when attaching or detaching a loopback device)
>    but also when allocating a block device, so that even before the
>    first media change event a block device has a sequence number. This
>    means allocating a sequence number for block devices won't be
>    limited to the media change code anyway.

Doing this on creation is fine, and attaching is by definition a media
change.

  reply	other threads:[~2021-06-24  6:12 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 [this message]
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=YNQiDROADP1jGXCJ@infradead.org \
    --to=hch@infradead.org \
    --cc=axboe@kernel.dk \
    --cc=bluca@debian.org \
    --cc=damien.lemoal@wdc.com \
    --cc=hare@suse.de \
    --cc=javier@javigon.com \
    --cc=jefflexu@linux.alibaba.com \
    --cc=johannes.thumshirn@wdc.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcroce@linux.microsoft.com \
    --cc=mzxreary@0pointer.de \
    --cc=niklas.cassel@wdc.com \
    --cc=tj@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.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 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).