Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1349456

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

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


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