From: Mike Snitzer <snitzer@redhat.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Christoph Hellwig <hch@infradead.org>, Shaohua Li <shli@fb.com>,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
axboe@fb.com, sitsofe@yahoo.com, Kernel-team@fb.com
Subject: Re: [PATCH V2] block: correctly fallback for zeroout
Date: Tue, 14 Jun 2016 22:40:02 -0400 [thread overview]
Message-ID: <20160615024002.GD5443@redhat.com> (raw)
In-Reply-To: <yq17fdrb2ud.fsf@sermon.lab.mkp.net>
On Tue, Jun 14 2016 at 10:30pm -0400,
Martin K. Petersen <martin.petersen@oracle.com> wrote:
> >>>>> "Mike" == Mike Snitzer <snitzer@redhat.com> writes:
>
> Mike,
>
> Mike> so long story short: making this change to remove this so-called
> Mike> "stupid behaviour" will require code like
> Mike> drivers/md/dm-thin.c:issue_discard(() to check the return from
> Mike> __blkdev_issue_discard() and if it is -EOPNOTSUPP then it should
> Mike> return 0.
>
> Yes, please.
>
> The original -EOPNOTSUPP equals success is a remnant from the days where
> discards were only a hint. And sadly that policy got encoded in the
> actual interface instead of being left up to the caller.
>
> Now the world has moved on. And reliable zeroout behavior, the SCSI
> target drivers and other kernel users need an interface that tells them
> exactly what happened at the bottom of the stack so they in turn can
> provide a deterministic result (including partial block zeroing) to
> their clients.
>
> It's imperative that this gets fixed up. And instead of perpetuating a
> weird interface that returns success on failure, let's fix DM and the
> callers that actually check the return of blkdev_issue_discard() so they
> do the right thing.
>
> I really don't understand why you are objecting so much to this. It's a
> trivial change that may not directly benefit DM but it helps everybody
> else. And it cleans up a library call that's confusing, error prone and
> goes against the very grain of how all our kernel interfaces work in
> general.
I've been consistently objecting to changing the blkdev_issue_discard()
interface. Fixing the async __blkdev_issue_discard() to offer
unfiltered return values is perfectly fine by me.
But the ship has sailed on the blkdev_issue_discard() interface.
next prev parent reply other threads:[~2016-06-15 2:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-06 22:33 [PATCH V2] block: correctly fallback for zeroout Shaohua Li
2016-06-07 4:50 ` Sitsofe Wheeler
2016-06-07 14:58 ` Shaohua Li
2016-06-15 21:26 ` Sitsofe Wheeler
2016-06-10 2:04 ` Martin K. Petersen
2016-06-10 2:54 ` Shaohua Li
2016-06-11 1:49 ` Martin K. Petersen
2016-06-13 8:20 ` Christoph Hellwig
2016-06-14 18:36 ` Mike Snitzer
2016-06-15 2:30 ` Martin K. Petersen
2016-06-15 2:40 ` Mike Snitzer [this message]
2016-06-15 2:14 ` Martin K. Petersen
2016-06-15 21:24 ` Sitsofe Wheeler
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=20160615024002.GD5443@redhat.com \
--to=snitzer@redhat.com \
--cc=Kernel-team@fb.com \
--cc=axboe@fb.com \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=shli@fb.com \
--cc=sitsofe@yahoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox