Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1349456
| Path | csiph.com!weretis.net!feeder4.news.weretis.net!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod |
|---|---|
| From | Linus Torvalds <torvalds@linux-foundation.org> |
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks |
| Date | Thu, 03 Mar 2016 19:00:02 +0100 |
| Message-ID | <r8FHA-2d3-3@gated-at.bofh.it> (permalink) |
| References | <r86qt-2pO-3@gated-at.bofh.it> <r86qt-2pO-5@gated-at.bofh.it> <r8ka6-3CZ-7@gated-at.bofh.it> <r8nUm-6fn-19@gated-at.bofh.it> <r8oQq-6Vq-13@gated-at.bofh.it> <r8EVe-1Ta-39@gated-at.bofh.it> |
| Dkim-Signature | v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to; bh=OL50AZ7Jnzr62w3ogCfvx9m2o6O9QhMQC7nwh579IvA=; b=AUUZ/KmvIkBlh88Vva2r4WjVqObr63+6E7imLgydWFCsxDiZxo73jWj2x6uwAC/DIZ bh92MyFfaT2SYJsyGSuuS5RaCBZX5zuTW0mS4TfPp8GGTftgg+0tHEqk8ESiBKMaV+LB aeToXFHxnNIi3zaW/XT2EsfmS8c7d8uRJ0CsvsgKf0hD4ezLP7fq/yFcDI6L4oUThg70 Aro6VQw2LHXiAsfip+CldhxntW6CuBMRcz4HKEm8UErEGouXYp4Meq/cKjehqpGEGXUv c+DX4yK0Yrcb5jWQzy5nhbAVrJNU5O1UchTA0EwHMuY1bnBV01mhbH0bkIn2dxOWwqGW aOGA== |
| Dkim-Signature | v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to; bh=OL50AZ7Jnzr62w3ogCfvx9m2o6O9QhMQC7nwh579IvA=; b=cwpsEAfLzCvGNHjN+HvsTHORgSE2T3N3W4lySxckoUuJ3GglYX+yWq9bRCp0r03Gy8 ZnwL37BjcpvYtYbzvq7xnXji0TVC9D6WtsuW2aKTidtPke68i6rrvqSwfPARJk3JAC+p DhaQetEdXtEr7S0oyENMflD/WqpVNOOoKPzrY= |
| X-Google-Dkim-Signature | v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to; bh=OL50AZ7Jnzr62w3ogCfvx9m2o6O9QhMQC7nwh579IvA=; b=SH7Kh1FMUy2Dk2ShkYTTYng661J0nmfmh7xe+KP8DcheWvr7tJhNgl/YurMiPgsB0v 2ziHA4G4vAArNDHNPQq7iCIfT4Wl9/siqtBywhLQDheslpo58Vje0ToSak38quVdruy5 pRpGlkzm81yxDYWsSJ2S+0WzjyN0lMeqxhMRWqAKFEy/YB214QYHi/o5BVyQfybfjye3 DGd33fZZTBK3nDElr0lhXpv6bieBIet2ttVz8k69jQZG1THmEjhmO1VG2KZdeEIeY2zb zJ3FS/IXn4M0o9maTiZcuo8/1jCXvluYVr9C4d1cLmT5sXueWpNFud4ggwdG3wATkBTD heAw== |
| X-Gm-Message-State | AD7BkJIqKbNHFlMSimO47ooaLTAG6FsAvm3SGcvir/PTq9yIWGPzG84NVyWC94j63Ja0XW3SsmyE3DF24UvJSA== |
| MIME-Version | 1.0 |
| X-Received | by 10.50.137.66 with SMTP id qg2mr322413igb.25.1457027738207; Thu, 03 Mar 2016 09:55:38 -0800 (PST) |
| X-Google-Sender-Auth | f5QX5FMkhfRVcKa-wsckF0IJ0VQ |
| Content-Type | text/plain; charset=UTF-8 |
| Sender | robomod@news.nic.it |
| List-ID | <linux-kernel.vger.kernel.org> |
| X-Mailing-List | linux-kernel@vger.kernel.org |
| Approved | robomod@news.nic.it |
| Lines | 79 |
| Organization | linux.* mail to news gateway |
| X-Original-Date | Thu, 3 Mar 2016 09:55:38 -0800 |
| X-Original-Message-ID | <CA+55aFwPA1X8XGTdVZmP5uzkWMwj+X=bjkGVcEkZDme+qskrzQ@mail.gmail.com> |
| X-Original-References | <20160302040932.16685.62789.stgit@birch.djwong.org> <20160302040947.16685.42926.stgit@birch.djwong.org> <CA+55aFx_NPn0VYk=+Ad5S_r=D6J1xFmWmf7JzQ7RmkwKmdkYOg@mail.gmail.com> <20160302225601.GB21890@birch.djwong.org> <CA+55aFyNPnjJ-Nsu3bMr+HuLQnkj1B8FMddNnXW7HJqxdUzJmQ@mail.gmail.com> <20160303170205.GD24012@thunk.org> |
| X-Original-Sender | linux-kernel-owner@vger.kernel.org |
| Xref | csiph.com linux.kernel:1349456 |
Show key headers only | View raw
On Thu, Mar 3, 2016 at 9:02 AM, Theodore Ts'o <tytso@mit.edu> wrote:
>
> There is a massive bug in the SATA specs about trim, which is that it
> is considered advisory. So the storage device can throw it away
> whenever it feels like it. (In practice, when it's too busy doing
> other things).
Ugh.
But that essentially says that we shouldn't expose this interface at
all (unless we trust our white-lists - I'm sure they are getting
better, but if nobody has ever really _relied_ on the zeroing behavior
of trim, then I guess there could be tons of bugs lurking).
Or maybe we should expose it, but not call it BLKZEROOUT, and make it
*much* more generic.
That migth actually put some of my complaints to rest: if this is more
a general "manage this range of blocks" model, then the flags make
more sense to me.
So what are people actually wanting to do?
If they don't care horribly about the zeroing, they might then say
"using trim is ok". But why wouldn't they use the BLKDISCARD ioctl
then?
So just looking at this more, that "trim is ok" flag still doesn't
make much sense to me.
I see two cases: either we guarantee zero-out behavior with discard
set to true (and we trust our whitelists), or we don't. Can anybody
see a third alternative?
And if we don't guarantee zero-out behavior from
blkdev_issue_zeroout() with "discard" set to true, then why would we
expose such a random interface to user space? No sane user space could
*possibly* use it: if they care about zeroing, it's the wrong thing to
do, and if they *don't* care about zeroing it's still the wrong thing
to do.
In other words, I still don't see how that flag can possibly make
sense in any possible scenario.
Put succinctly:
"Either we trust trim and and our whitelists (in which case _not_
using trim makes no sense), or we do (in which case exposing a random
untrustworthy user interface is pointless, since any user would be
fundamentally broken and should just have used BLKDISCARD)"
See where I'm coming from?
Now, the reason I think a more generic model that *isn't* hung up
about zeroing the buffer migth be ok is that maybe it would be a good
thing to have a more unified itnerface for doing all those things
people do want to do:
- flush caches
- discard (our current BLKDISCARD doesn't flush caches either, so
together with flushing caches this is something new)
- zero out
- synchronous/asynchronous
- other things?
So I do see a case for passing in multiple flags, but a lot of that
case ends up depending on the zeroing out *not* being the most central
feature.
I very much could see wanting "discard these blocks and flush caches".
And I could see just "flush caches", with or without zeroing. But I do
*not* see the point of "discard blocks and zero" for the reasons
outlined above.
Linus
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v5.1 0/2] create BLKZEROOUT ioctl that invalidates page cache "Darrick J. Wong" <darrick.wong@oracle.com> - 2016-03-02 05:20 +0100
[PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks "Darrick J. Wong" <darrick.wong@oracle.com> - 2016-03-02 05:20 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Christoph Hellwig <hch@infradead.org> - 2016-03-02 10:30 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-02 20:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks "Darrick J. Wong" <darrick.wong@oracle.com> - 2016-03-03 00:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-03 01:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-03 18:10 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-03 19:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Christoph Hellwig <hch@infradead.org> - 2016-03-03 19:10 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks "Martin K. Petersen" <martin.petersen@oracle.com> - 2016-03-03 19:20 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-03 19:30 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks "Martin K. Petersen" <martin.petersen@oracle.com> - 2016-03-03 19:10 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Christoph Hellwig <hch@infradead.org> - 2016-03-03 19:10 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks "Darrick J. Wong" <darrick.wong@oracle.com> - 2016-03-03 19:20 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks "Martin K. Petersen" <martin.petersen@oracle.com> - 2016-03-03 20:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-03 23:50 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Dave Chinner <david@fromorbit.com> - 2016-03-04 00:20 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-04 01:30 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Dave Chinner <david@fromorbit.com> - 2016-03-04 00:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Thomas Schoebel-Theuer <tst@schoebel-theuer.de> - 2016-03-04 03:40 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-03 19:20 +0100
Re: [PATCH v5.1 0/2] create BLKZEROOUT ioctl that invalidates page cache Arnd Bergmann <arnd@arndb.de> - 2016-03-02 10:20 +0100
Re: [PATCH v5.1 0/2] create BLKZEROOUT ioctl that invalidates page cache Christoph Hellwig <hch@infradead.org> - 2016-03-02 10:50 +0100
Re: [PATCH v5.1 0/2] create BLKZEROOUT ioctl that invalidates page cache Arnd Bergmann <arnd@arndb.de> - 2016-03-02 12:00 +0100
csiph-web