From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Kent Overstreet <kent.overstreet@gmail.com>
Cc: Mike Snitzer <snitzer@redhat.com>,
Ming Lei <ming.lei@canonical.com>,
device-mapper development <dm-devel@redhat.com>,
Christoph Hellwig <hch@lst.de>, Alasdair Kergon <agk@redhat.com>,
Lars Ellenberg <drbd-dev@lists.linbit.com>,
Philip Kelleher <pjk1939@linux.vnet.ibm.com>,
Christoph Hellwig <hch@infradead.org>,
Nitin Gupta <ngupta@vflare.org>,
Ming Lin <ming.l@ssi.samsung.com>,
Oleg Drokin <oleg.drokin@intel.com>,
Al Viro <viro@zeniv.linux.org.uk>, Ming Lin <mlin@kernel.org>,
Jens Axboe <axboe@kernel.dk>,
axboe@fb.com, Andreas Dilger <andreas.dilger@intel.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Geoff Levand <geoff@infradead.org>, Jiri Kosina <jkosina@suse.cz>,
lkml <linux-kernel@vger.kernel.org>, Jim Paris <jim@jtan.com>,
Minchan Kim <minchan@kernel.org>, Joe Thornber <ejt@redhat.com>,
Dongsu Park <dpark@posteo.net>,
drbd-user@lists.linbit.com
Subject: Re: [Drbd-dev] [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
Date: Tue, 11 Aug 2015 13:49:50 -0400 [thread overview]
Message-ID: <yq11tf9hg01.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <20150811033851.GA28533@kmo-pixel> (Kent Overstreet's message of "Mon, 10 Aug 2015 19:38:51 -0800")
>>>>> "Kent" == Kent Overstreet <kent.overstreet@gmail.com> writes:
Kent> This kind of logic really doesn't belong in dm
Well it does in this case since the thinp personality actually
provisions and unprovisions space.
But there is a difference between what dm thinp acts on for its own
internal provisioning purposes and what it passes down the stack. I am
really against dropping information anywhere along the path. We don't
round off read/write requests either.
The queue limits were meant as hints to mkfs.* so that on-disk data
structures could be laid out in an aligned and storage friendly way. I
never intended for the hints to affect runtime behavior.
Kent> IMO though it belongs in the driver - if a discard needs to be
Kent> dropped because it's too small and the hardware can't do it, that
Kent> should be the driver's responsibility.
I agree except I really don't want to lop off anything unless the device
locks up if we send it partial blocks. There was an array that had
problems a while back but I believe they have been fixed.
The fundamental premise should be that we pass as comprehensive
information as we can. And the device can then decide to ignore all or
parts of the request. That's fundamentally how things work at the
protocol level in both SCSI and SATA. I don't see any reason why the
Linux I/O stack should behave in a different manner.
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2015-08-11 17:49 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-06 7:44 [Drbd-dev] [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios Ming Lin
2015-07-06 7:44 ` [Drbd-dev] [PATCH v5 08/11] block: kill merge_bvec_fn() completely Ming Lin
2015-07-31 19:23 ` [Drbd-dev] [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios Mike Snitzer
2015-07-31 21:19 ` Ming Lin
2015-07-31 21:38 ` Mike Snitzer
2015-08-01 6:58 ` Ming Lin
2015-08-01 16:33 ` Mike Snitzer
2015-08-03 5:58 ` Ming Lin
2015-08-04 11:36 ` Christoph Hellwig
2015-08-05 6:03 ` Ming Lin
2015-08-07 7:30 ` Christoph Hellwig
2015-08-07 23:40 ` Ming Lin
2015-09-11 13:20 ` Kent Overstreet
2015-08-08 5:17 ` Ming Lin
2015-09-11 13:20 ` Kent Overstreet
2015-08-08 12:35 ` Christoph Hellwig
2015-09-11 13:21 ` [Drbd-dev] [dm-devel] " Hannes Reinecke
2015-09-11 13:21 ` Kent Overstreet
2015-09-11 13:22 ` Hannes Reinecke
[not found] ` <20150807000004.GB30757@moria.home.lan>
2015-08-07 7:30 ` [Drbd-dev] " Christoph Hellwig
2015-08-08 16:19 ` [Drbd-dev] [dm-devel] " Martin K. Petersen
2015-08-09 5:59 ` Ming Lin
2015-08-09 6:41 ` Christoph Hellwig
2015-08-09 6:55 ` Ming Lin
2015-08-09 7:01 ` Christoph Hellwig
2015-08-09 7:18 ` Ming Lin
2015-08-10 15:02 ` [Drbd-dev] " Mike Snitzer
2015-08-10 16:14 ` Ming Lin
2015-08-10 16:18 ` Ming Lin
2015-08-10 16:40 ` Martin K. Petersen
2015-08-10 18:13 ` Mike Snitzer
2015-08-10 22:30 ` Ming Lin
2015-08-10 16:22 ` Martin K. Petersen
2015-08-10 18:18 ` Ming Lin
2015-08-11 2:00 ` Martin K. Petersen
2015-08-11 2:41 ` Mike Snitzer
2015-08-11 17:36 ` Martin K. Petersen
2015-08-11 17:47 ` Mike Snitzer
2015-08-11 18:01 ` [Drbd-dev] [dm-devel] " Martin K. Petersen
2015-09-11 13:22 ` [Drbd-dev] " Kent Overstreet
2015-08-11 14:08 ` Mike Snitzer
2015-08-11 17:49 ` Martin K. Petersen [this message]
2015-08-11 18:05 ` Martin K. Petersen
2015-08-11 20:56 ` Ming Lin
2015-08-12 0:24 ` Martin K. Petersen
2015-08-12 4:41 ` Ming Lin
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=yq11tf9hg01.fsf@sermon.lab.mkp.net \
--to=martin.petersen@oracle.com \
--cc=agk@redhat.com \
--cc=andreas.dilger@intel.com \
--cc=axboe@fb.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=dpark@posteo.net \
--cc=drbd-dev@lists.linbit.com \
--cc=drbd-user@lists.linbit.com \
--cc=ejt@redhat.com \
--cc=geoff@infradead.org \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=jim@jtan.com \
--cc=jkosina@suse.cz \
--cc=kent.overstreet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=minchan@kernel.org \
--cc=ming.l@ssi.samsung.com \
--cc=ming.lei@canonical.com \
--cc=mlin@kernel.org \
--cc=ngupta@vflare.org \
--cc=oleg.drokin@intel.com \
--cc=pjk1939@linux.vnet.ibm.com \
--cc=snitzer@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/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