archive mirror
 help / color / mirror / Atom feed
From: Alasdair G Kergon <>
To: Christoph Hellwig <>, Jens Axboe <>,
	Mike Snitzer <>,,
Subject: Re: [dm-devel] use regular gendisk registration in device mapper v2
Date: Tue, 10 Aug 2021 15:41:55 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Aug 10, 2021 at 01:36:08AM +0100, Alasdair G Kergon wrote:
> On Wed, Aug 04, 2021 at 11:41:39AM +0200, Christoph Hellwig wrote:
> > allows device mapper to use the normal scheme
> > of calling add_disk when it is ready to accept I/O.
> For clarity, even after this patchset, the device is not ready to accept
> I/O when add_disk is called.  

The question then arises: could we go beyond this patchset and move the
add_disk further to the first resume to make the statement true?  (From
step 2 to 3 in my earlier response. DM_TABLE_CLEAR then also enters the
mix for testing.)

In the early days, in practice userspace did have to resume a device
before it could be referenced in a table and lvm2 and other tools were
designed with that in mind - they should always resume a device before
loading a table that references it.  This was because the device
reference performed a size check - to make sure the access was within
the device, and the device size isn't defined until a table becomes live
when the device is resumed.  But some multipath tables had to be set up
referencing devices with not-yet-defined sizes, so the code got relaxed
to accept references to zero-sized devices.  (At the back of my mind I
think there was some non-multipath code that found this a convenient
short-cut too.)

So since this "must resume before referencing in a table" hasn't been
enforced for so long, I can't really say how much userspace code, if
any, might now not be doing it.  We and others would need to do some
testing to see if we could get away with making such a change.


dm-devel mailing list

  reply	other threads:[~2021-08-10 14:42 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-04  9:41 [dm-devel] use regular gendisk registration in device mapper v2 Christoph Hellwig
2021-08-04  9:41 ` [dm-devel] [PATCH 1/8] block: make the block holder code optional Christoph Hellwig
2021-08-04  9:41 ` [dm-devel] [PATCH 2/8] block: remove the extra kobject reference in bd_link_disk_holder Christoph Hellwig
2021-08-04  9:41 ` [dm-devel] [PATCH 3/8] block: look up holders by bdev Christoph Hellwig
2021-08-04  9:41 ` [dm-devel] [PATCH 4/8] block: support delayed holder registration Christoph Hellwig
     [not found]   ` <>
2021-08-10 21:30     ` Marek Szyprowski
2021-08-14 21:13   ` Guenter Roeck
2021-08-15  7:07     ` Christoph Hellwig
2021-08-15 14:27       ` Guenter Roeck
2021-08-16  7:21         ` Christoph Hellwig
2021-08-16 14:17           ` Guenter Roeck
2021-08-20 15:08             ` Christoph Hellwig
2021-08-21  3:17               ` Guenter Roeck
2021-08-18  2:51           ` Guenter Roeck
2021-08-04  9:41 ` [dm-devel] [PATCH 5/8] dm: cleanup cleanup_mapped_device Christoph Hellwig
2021-08-04  9:41 ` [dm-devel] [PATCH 6/8] dm: move setting md->type into dm_setup_md_queue Christoph Hellwig
2021-08-04  9:41 ` [dm-devel] [PATCH 7/8] dm: delay registering the gendisk Christoph Hellwig
2021-08-09 23:31   ` Alasdair G Kergon
2021-08-10  0:17     ` Alasdair G Kergon
2021-08-10 13:12     ` Peter Rajnoha
2021-08-10 15:05       ` Alasdair G Kergon
2022-07-07  3:29   ` Yu Kuai
2022-07-07  5:24     ` Christoph Hellwig
2022-07-07  7:20       ` Yu Kuai
2022-07-15  3:24         ` Yu Kuai
2022-08-01  1:04           ` Yu Kuai
2021-08-04  9:41 ` [dm-devel] [PATCH 8/8] block: remove support for delayed queue registrations Christoph Hellwig
2021-08-09 17:51 ` [dm-devel] use regular gendisk registration in device mapper v2 Jens Axboe
2021-08-10  0:36 ` Alasdair G Kergon
2021-08-10 14:41   ` Alasdair G Kergon [this message]
2021-08-19 15:58 ` [dm-devel] holders not working properly, regression [was: Re: use regular gendisk registration in device mapper v2] Mike Snitzer
2021-08-19 18:05   ` Christoph Hellwig
2021-08-19 22:08     ` Mike Snitzer

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 \ \ \ \ \ \ \ \

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