From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Mike Snitzer <snitzer@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
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:30:50 -0400 [thread overview]
Message-ID: <yq17fdrb2ud.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <20160614183612.GB26196@redhat.com> (Mike Snitzer's message of "Tue, 14 Jun 2016 14:36:12 -0400")
>>>>> "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.
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2016-06-15 2:31 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 [this message]
2016-06-15 2:40 ` Mike Snitzer
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=yq17fdrb2ud.fsf@sermon.lab.mkp.net \
--to=martin.petersen@oracle.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=shli@fb.com \
--cc=sitsofe@yahoo.com \
--cc=snitzer@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox