From: Mike Snitzer <snitzer@redhat.com>
To: NeilBrown <neilb@suse.de>
Cc: Liuhua Wang <lwang@suse.com>,
Heinz Mauelshagen <heinzm@redhat.com>,
device-mapper development <dm-devel@redhat.com>,
Alasdair G Kergon <agk@redhat.com>
Subject: Re: dm raid: ensure metadata IO matches device block size.
Date: Wed, 15 Oct 2014 09:13:08 -0400 [thread overview]
Message-ID: <20141015131307.GA23955@redhat.com> (raw)
In-Reply-To: <20141015144003.7b17752d@notabene.brown>
On Tue, Oct 14 2014 at 11:40pm -0400,
NeilBrown <neilb@suse.de> wrote:
> On Tue, 14 Oct 2014 22:55:50 -0400 Mike Snitzer <snitzer@redhat.com> wrote:
>
> > On Tue, Oct 14 2014 at 9:19pm -0400,
> > NeilBrown <neilb@suse.de> wrote:
> >
> > >
> > > dm_raid_superblock is 512.
> > > Reading or writing this on a 512-byte sector works fine.
> > > On a 4096-byte sector device, this fails.
> > >
> > > If we round up rdev->sb_size to match the block size of
> > > the device, all IO will work correctly.
> > >
> > > Reported-by: "Liuhua Wang" <lwang@suse.com>
> > > Signed-off-by: NeilBrown <neilb@suse.de>
> > >
> > > ---
> > > this issue has been discussed already a bit. See email thread
> > > Subject: Re: [dm-devel] [PATCH] fix mirror device creation with lvcreate failed
> > > I think this is the best fix. It handles boths read and writes, and (I think)
> > > at the best level.
> > >
> > > Thanks,
> > > NeilBrown
> > >
> > >
> > > diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c
> > > index 4880b69e2e9e..31bdd73bc368 100644
> > > --- a/drivers/md/dm-raid.c
> > > +++ b/drivers/md/dm-raid.c
> > > @@ -858,7 +858,8 @@ static int super_load(struct md_rdev *rdev, struct md_rdev *refdev)
> > > uint64_t events_sb, events_refsb;
> > >
> > > rdev->sb_start = 0;
> > > - rdev->sb_size = sizeof(*sb);
> > > + rdev->sb_size = roundup(sizeof(*sb),
> > > + bdev_logical_block_size(rdev->meta_bdev));
> > >
> > > ret = read_disk_sb(rdev, rdev->sb_size);
> > > if (ret)
> >
> > Wouldn't it be better to use bdev_physical_block_size()?
> >
> > Even on a 4K device that emulates 512b logical sectors it is better to
> > use the physical block size (4K).
>
>
> _logical_ is the smallest value for which the IO actually works.
> And the goal of the change is to make it work.
>
> I don't object to using _physical_, but it isn't clear to me how I would
> justify that as "correct".
>
> A big question in my mind is: how much space does LVM reserve in this device
> for the metadata? It seems reasonable to assume that it reserves at least
> 1 logical block. If the API guarantees that at least one physical block is
> reserved, then that would justify using _physical_.
I'll have to check with Jon and/or Heinz on this point.
> A quick look at the code shows that the bitmap superblock is placed 4K after
> the start of the metadata.
"the code" being the MD kernel code right? Any reason not to export a
#define that reflects the space MD reserves and just have dm-raid use that?
Starting to feel like hardcoding 4K is the right thing to do given the
current code.
next prev parent reply other threads:[~2014-10-15 13:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-15 1:19 [PATCH] dm raid: ensure metadata IO matches device block size NeilBrown
2014-10-15 2:55 ` Mike Snitzer
2014-10-15 3:40 ` NeilBrown
2014-10-15 13:13 ` Mike Snitzer [this message]
2014-10-15 21:00 ` NeilBrown
2014-10-16 13:31 ` Heinz Mauelshagen
2014-10-16 19:56 ` 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:
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=20141015131307.GA23955@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=heinzm@redhat.com \
--cc=lwang@suse.com \
--cc=neilb@suse.de \
/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