All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: device-mapper development <dm-devel@redhat.com>,
	"Alasdair G. Kergon" <agk@redhat.com>
Subject: Re: [PATCH v2] dm: Fix alignment stacking on partitioned devices
Date: Wed, 6 Jan 2010 08:25:08 -0500	[thread overview]
Message-ID: <20100106132508.GA3589@redhat.com> (raw)
In-Reply-To: <yq1pr5nsk3z.fsf@sermon.lab.mkp.net>

On Wed, Jan 06 2010 at  3:39am -0500,
Martin K. Petersen <martin.petersen@oracle.com> wrote:

> >>>>> "Mike" == Mike Snitzer <snitzer@redhat.com> writes:
> 
> Mike> BTW, the other related concern Alasdair had was that DM shouldn't
> Mike> need to know to add the start of the partition to the 'offset' it
> Mike> passes to blk_stack_limits() -- sees it as a layering violation.
> 
> Mike> I went over the fact that the 'struct queue_limits' was added to
> Mike> abstract out the limit stacking in a way that DM could use too.
> Mike> Without passing asymmetric types for the 'top' and 'bottom' device
> Mike> to blk_stack_limits(), e.g.:
> 
> I don't particularly care about the symmetry.  The current set of
> arguments were first and foremost there to meet DM's needs.  I don't
> think you had access to the bdev at the right time when we originally
> came up with this.

I think we always had it for the bottom device but not the top..
 
> However, there are other subsystems that need to stack without an
> associated block_device.  So instead of changing blk_stack_limits I
> propose we use the wrapper below.

Yes, looks like osdblk.c's use of blk_queue_stack_limits()
 
> You'll notice that bdev_stack_limits takes a sector offset as argument.
> I have a patch that I intend to push at a later date that will convert
> the remaining stacking functions to take soft sector offsets instead of
> bytes.  I deal with the appropriate conversion in the alignment
> calculation.  That way we avoid the blk_off_t goo entirely and it makes
> the difference between absolute offsets and alignment offsets crystal
> clear.

Looks good.  But you're missing the EXPORT_SYMBOL(bdev_stack_limits)

> Alasdair, if you are OK with the approach below I propose you give an
> Acked-by: and then we can feed the patch through Jens instead of dealing
> with a clunky two-stage merge this late in the .33 game.

Good point, you can have mine while we're at it.


> block: bdev_stack_limits wrapper
> 
> DM does not want to know about partition offsets.  Add a partition-aware
> wrapper that DM can use when stacking block devices.
> 
> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

Acked-by: Mike Snitzer <snitzer@redhat.com>

  reply	other threads:[~2010-01-06 13:25 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-23 18:07 [PATCH v2] dm: Fix alignment stacking on partitioned devices Mike Snitzer
2009-12-23 19:21 ` Mike Snitzer
2010-01-05 18:04 ` Alasdair G Kergon
2010-01-05 18:27 ` Alasdair G Kergon
2010-01-06  2:23   ` Martin K. Petersen
2010-01-06  2:57     ` Mike Snitzer
2010-01-06  3:03       ` Mike Snitzer
2010-01-06  3:24       ` Martin K. Petersen
2010-01-06  4:10         ` Mike Snitzer
2010-01-06  4:16           ` Martin K. Petersen
2010-01-06  5:16             ` Mike Snitzer
2010-01-06  8:39               ` Martin K. Petersen
2010-01-06 13:25                 ` Mike Snitzer [this message]
2010-01-07 17:15                   ` Martin K. Petersen
2010-01-07 18:55                     ` Mike Snitzer
2010-01-08 18:41                       ` Martin K. Petersen
2010-01-08 20:28                         ` Mike Snitzer
2010-01-09  0:01                   ` [PATCH] block: bdev_stack_limits wrapper and DM topology fixes Mike Snitzer
2010-01-06 13:55                 ` [PATCH v2] dm: Fix alignment stacking on partitioned devices Alasdair G Kergon

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=20100106132508.GA3589@redhat.com \
    --to=snitzer@redhat.com \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=martin.petersen@oracle.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.