From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Kent Overstreet <kmo@daterainc.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
Hugh Dickins <hughd@google.com>, Jens Axboe <axboe@kernel.dk>,
Shaohua Li <shli@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: next bio iters break discard?
Date: Wed, 15 Jan 2014 20:39:42 -0500 [thread overview]
Message-ID: <yq11u08yaap.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <20140114222424.GA7333@moria.home.lan> (Kent Overstreet's message of "Tue, 14 Jan 2014 14:24:24 -0800")
>>>>> "Kent" == Kent Overstreet <kmo@daterainc.com> writes:
Kent> Side note, one of the things on my todo list/wishlist is make a
Kent> separate enum for bio type - bare flush, normal read/write, scsi
Kent> command, discard and write same. In particular with bi_size
Kent> meaning different things depending on the type of the command, I
Kent> think having an enum we can switch off of where appropriate
Kent> instead of a bunch of random flags will make things a hell of a
Kent> lot saner.
Yeah. That's one of the reasons we cleaned up the merge flags and
introduced bio_has_data() and bio_is_rw().
Kent> There's also that horrible hack in the scsi (?) code Christoph
Kent> added for discards - where the driver adds a page to the bio - if
Kent> the driver is counting the number of segments _after_ that god
Kent> only knows what is supposed to happen.
I manually do the bookkeeping in the SCSI disk driver. I.e. LLDs are
explicitly told to perform a 512-byte transfer. And when they're done I
complete bi_size bytes to the block layer. Kind of ugly but it's an
unfortunate side effect of bi_size being both the size of the
scatterlist and the block count. I did consider making them separate
entities but that means struct bio will grow for no reason for the
common case of read/write. Didn't seem worth the hassle...
Kent> Does the below patch look like what we want? I'm assuming that if
Kent> multiple WRITE_SAME bios are merged, since they're all writing the
Kent> same data we can consider the entire request to be a single
Kent> segment.
Looks OK to me.
Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2014-01-16 1:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-13 3:52 next bio iters break discard? Hugh Dickins
2014-01-14 2:33 ` Kent Overstreet
2014-01-14 4:06 ` Martin K. Petersen
2014-01-14 4:48 ` Kent Overstreet
2014-01-14 20:17 ` Martin K. Petersen
2014-01-14 22:24 ` Kent Overstreet
2014-01-16 1:39 ` Martin K. Petersen [this message]
2014-01-16 20:21 ` Hugh Dickins
2014-01-17 1:06 ` Kent Overstreet
2014-01-17 1:21 ` Kent Overstreet
2014-01-31 17:17 ` Hugh Dickins
2014-01-31 21:58 ` Jens Axboe
2014-02-04 10:17 ` [PATCH] block: Explicitly handle discard/write same segments Kent Overstreet
2014-02-04 12:25 ` Hugh Dickins
2014-02-04 12:35 ` Kent Overstreet
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=yq11u08yaap.fsf@sermon.lab.mkp.net \
--to=martin.petersen@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=hughd@google.com \
--cc=kmo@daterainc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=shli@kernel.org \
/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.