From: Lars Ellenberg <lars.ellenberg@linbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Ming Lei <ming.lei@canonical.com>, Jens Axboe <axboe@kernel.dk>,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
Al Viro <viro@zeniv.linux.org.uk>,
Anton Altaparmakov <anton@tuxera.com>,
xfs@oss.sgi.com, Dave Chinner <david@fromorbit.com>,
drbd-dev@lists.linbit.com,
Philipp Reisner <philipp.reisner@linbit.com>,
Boaz Harrosh <boaz@plexistor.com>
Subject: Re: [PATCH 7/8] block: drbd: avoid to use BIO_MAX_SIZE
Date: Tue, 29 Mar 2016 10:09:21 +0200 [thread overview]
Message-ID: <20160329080921.GG15579@soda.linbit> (raw)
In-Reply-To: <20160329073124.GH18920@infradead.org>
On Tue, Mar 29, 2016 at 12:31:24AM -0700, Christoph Hellwig wrote:
> On Tue, Mar 22, 2016 at 02:12:28PM +0800, Ming Lei wrote:
> > drbd is the only user of BIO_MAX_SIZE, so use BIO_MAX_PAGES
> > instead.
>
> That whole code block looks completely bogus to me, although your patch
> doesn't make it any worse.
>
> I/O size for a network protocol shouldn't dependend on the number of
> vectors in a kernel internal structure.
That's correct. But we needed some limit there.
Initially, up until I changed it like six years ago iirc,
the receiving side would receive into a single bio.
So limiting us to what a single bio could usually handle
seemed like a good idea at the time.
Today, we should be able to handle 128 MiB easily,
maybe more. But that would require a protocol bump
to stay backwards compatible.
The part about "architecture not supported",
if our limit (1 MiB) is bigger than the "system" limit:
Never met that in real life. Probably not even possible.
Just a paranoia on my side: what if.
If that would have happened somewhere,
on some strange architecture or configuration,
I wanted to know about that.
Best way: don't even compile.
> Well, getting rid of BIO_MAX_SIZE is worth it, so:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
Thanks,
Lars Ellenberg
WARNING: multiple messages have this Message-ID (diff)
From: Lars Ellenberg <lars.ellenberg@linbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jens Axboe <axboe@kernel.dk>, Boaz Harrosh <boaz@plexistor.com>,
Ming Lei <ming.lei@canonical.com>,
linux-kernel@vger.kernel.org, xfs@oss.sgi.com,
linux-block@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
Philipp Reisner <philipp.reisner@linbit.com>,
Anton Altaparmakov <anton@tuxera.com>,
drbd-dev@lists.linbit.com
Subject: Re: [PATCH 7/8] block: drbd: avoid to use BIO_MAX_SIZE
Date: Tue, 29 Mar 2016 10:09:21 +0200 [thread overview]
Message-ID: <20160329080921.GG15579@soda.linbit> (raw)
In-Reply-To: <20160329073124.GH18920@infradead.org>
On Tue, Mar 29, 2016 at 12:31:24AM -0700, Christoph Hellwig wrote:
> On Tue, Mar 22, 2016 at 02:12:28PM +0800, Ming Lei wrote:
> > drbd is the only user of BIO_MAX_SIZE, so use BIO_MAX_PAGES
> > instead.
>
> That whole code block looks completely bogus to me, although your patch
> doesn't make it any worse.
>
> I/O size for a network protocol shouldn't dependend on the number of
> vectors in a kernel internal structure.
That's correct. But we needed some limit there.
Initially, up until I changed it like six years ago iirc,
the receiving side would receive into a single bio.
So limiting us to what a single bio could usually handle
seemed like a good idea at the time.
Today, we should be able to handle 128 MiB easily,
maybe more. But that would require a protocol bump
to stay backwards compatible.
The part about "architecture not supported",
if our limit (1 MiB) is bigger than the "system" limit:
Never met that in real life. Probably not even possible.
Just a paranoia on my side: what if.
If that would have happened somewhere,
on some strange architecture or configuration,
I wanted to know about that.
Best way: don't even compile.
> Well, getting rid of BIO_MAX_SIZE is worth it, so:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
Thanks,
Lars Ellenberg
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-03-29 8:15 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-22 6:12 [PATCH 0/8] block: prepare for multipage bvecs Ming Lei
2016-03-22 6:12 ` Ming Lei
2016-03-22 6:12 ` [PATCH 1/8] block: move bvec iterator into include/linux/bvec_iter.h Ming Lei
2016-03-22 6:12 ` Ming Lei
2016-03-29 7:26 ` Christoph Hellwig
2016-03-29 7:26 ` Christoph Hellwig
2016-03-29 8:53 ` Ming Lei
2016-03-29 8:53 ` Ming Lei
2016-03-22 6:12 ` [PATCH 2/8] block: make 'struct bvec_iter' not depend on CONFIG_BLOCK Ming Lei
2016-03-22 6:12 ` Ming Lei
2016-03-29 7:26 ` Christoph Hellwig
2016-03-29 7:26 ` Christoph Hellwig
2016-03-22 6:12 ` [PATCH 3/8] block: mark 1st parameter of bvec_iter_advance as const Ming Lei
2016-03-22 6:12 ` Ming Lei
2016-03-29 7:26 ` Christoph Hellwig
2016-03-29 7:26 ` Christoph Hellwig
2016-03-22 6:12 ` [PATCH 4/8] iov_iter: use bvec iterator to implement iterate_bvec() Ming Lei
2016-03-22 6:12 ` Ming Lei
2016-03-29 7:27 ` Christoph Hellwig
2016-03-29 7:27 ` Christoph Hellwig
2016-03-22 6:12 ` [PATCH 5/8] fs: xfs: replace BIO_MAX_SECTORS with BIO_MAX_PAGES Ming Lei
2016-03-22 6:12 ` Ming Lei
2016-03-29 7:29 ` Christoph Hellwig
2016-03-29 7:29 ` Christoph Hellwig
2016-03-22 6:12 ` [PATCH 6/8] block: bio: remove BIO_MAX_SECTORS Ming Lei
2016-03-22 6:12 ` Ming Lei
2016-03-29 7:29 ` Christoph Hellwig
2016-03-29 7:29 ` Christoph Hellwig
2016-03-22 6:12 ` [PATCH 7/8] block: drbd: avoid to use BIO_MAX_SIZE Ming Lei
2016-03-22 6:12 ` Ming Lei
2016-03-29 7:31 ` Christoph Hellwig
2016-03-29 7:31 ` Christoph Hellwig
2016-03-29 8:09 ` Lars Ellenberg [this message]
2016-03-29 8:09 ` Lars Ellenberg
2016-03-22 6:12 ` [PATCH 8/8] block: bio: remove BIO_MAX_SIZE Ming Lei
2016-03-22 6:12 ` Ming Lei
2016-03-29 7:31 ` Christoph Hellwig
2016-03-29 7:31 ` Christoph Hellwig
2016-03-29 1:33 ` [PATCH 0/8] block: prepare for multipage bvecs Ming Lei
2016-03-29 1:33 ` Ming Lei
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=20160329080921.GG15579@soda.linbit \
--to=lars.ellenberg@linbit.com \
--cc=anton@tuxera.com \
--cc=axboe@kernel.dk \
--cc=boaz@plexistor.com \
--cc=david@fromorbit.com \
--cc=drbd-dev@lists.linbit.com \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@canonical.com \
--cc=philipp.reisner@linbit.com \
--cc=viro@zeniv.linux.org.uk \
--cc=xfs@oss.sgi.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.