From: Mike Snitzer <snitzer@redhat.com>
To: dm-devel@redhat.com, ejt@redhat.com, agk@redhat.com
Subject: Re: [PATCH 2/2] dm thin: support for non power of 2 pool blocksize
Date: Mon, 30 Apr 2012 13:33:47 -0400 [thread overview]
Message-ID: <20120430173347.GB19033@redhat.com> (raw)
In-Reply-To: <20120430095555.GA5955@ubuntu>
On Mon, Apr 30 2012 at 5:55am -0400,
Joe Thornber <thornber@redhat.com> wrote:
> Hi Mike,
>
> In general this looks good. A lot cleaner now you've dropped the
> specialisation of the division. A few nit-picks below.
>
> - Joe
>
> On Sat, Apr 28, 2012 at 12:44:29AM -0400, Mike Snitzer wrote:
> > +/*
> > + * do_div wrappers that don't modify the dividend
> > + */
> > +static inline sector_t dm_thin_do_div(sector_t a, __u32 b)
> > +{
> > + sector_t r = a;
> > +
> > + do_div(r, b);
> > + return r;
> > +}
> > +
> > +static inline sector_t dm_thin_do_mod(sector_t a, __u32 b)
> > +{
> > + sector_t tmp = a;
> > +
> > + return do_div(tmp, b);
> > +}
>
> Please don't inline static functions. Let the compiler make the
> decision.
But in this instance we certainly want it inlined; regardless of whether
the compiler might do it anyway. Why would we ever want to allow the
compiler to not inline it?
> Also those sector_t's are passed by value, so you don't need to
> declare r or tmp. eg, it's enough to do this:
>
> static sector_t dm_thin_do_div(sector_t a, __u32 b)
> {
> do_div(a, b);
> return a;
> }
>
> static sector_t dm_thin_do_mod(sector_t a, __u32 b)
> {
> return do_div(a, b);
> }
OK, makes sense.
> > @@ -1941,12 +1954,18 @@ static int pool_ctr(struct dm_target *ti, unsigned argc, char **argv)
>
> ...
>
> > + if (dm_thin_do_mod(ti->len, block_size)) {
> > + ti->error = "Data device is not a multiple of block size";
> > + r = -EINVAL;
> > + goto out;
> > + }
>
> I don't see the need for this check. If I have a disk that isn't a
> multiple of the block size why should I have to layer a linear mapping
> on it to truncate it before I can use it as a data volume? Any
> partial block at the end of the device is already ignored (see the
> data_size calculation in pool_preresume). Is this restriction causing
> some of the changes you made to the test-suite?
Yes. But imposing this restriction was motivated by and the "attempt to
access beyond end of device" failures I saw with test_origin_unchanged
(I shared more details about this in private mail to you and kabi on
4/25 -- making the pool size a multiple of the non power of 2 blocksize
resolved that failure).
next prev parent reply other threads:[~2012-04-30 17:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-28 4:44 [PATCH 1/2] dm: update max_io_len to support a split_io that is not a power of 2 Mike Snitzer
2012-04-28 4:44 ` [PATCH 2/2] dm thin: support for non power of 2 pool blocksize Mike Snitzer
2012-04-28 4:51 ` [PATCH] thinp-test-suite: " Mike Snitzer
2012-04-28 15:32 ` Mike Snitzer
2012-04-30 10:15 ` [PATCH] " Joe Thornber
2012-04-30 9:55 ` [PATCH 2/2] dm thin: " Joe Thornber
2012-04-30 17:33 ` Mike Snitzer [this message]
2012-05-01 9:41 ` Joe Thornber
2012-04-30 16:10 ` [PATCH 1/2] dm: update max_io_len to support a split_io that is not a power of 2 Alasdair G Kergon
2012-04-30 17:24 ` Mike Snitzer
2012-04-30 18:36 ` Alasdair G Kergon
2012-04-30 18:59 ` Mike Snitzer
2012-05-01 15:42 ` Brassow Jonathan
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=20120430173347.GB19033@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=ejt@redhat.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.