From: "Ted Ts'o" <tytso@mit.edu>
To: Christoph Hellwig <hch@infradead.org>
Cc: Mark Lord <kernel@teksavvy.com>,
Steven Whitehouse <swhiteho@redhat.com>,
Lukas Czerner <lczerner@redhat.com>,
James Bottomley <James.Bottomley@suse.de>,
Matthew Wilcox <matthew@wil.cx>, Josef Bacik <josef@redhat.com>,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, sandeen@redhat.com
Subject: Re: [PATCH 1/2] fs: Do not dispatch FITRIM through separate super_operation
Date: Fri, 19 Nov 2010 10:37:48 -0500 [thread overview]
Message-ID: <20101119153748.GE10039@thunk.org> (raw)
In-Reply-To: <20101119141007.GB25488@infradead.org>
On Fri, Nov 19, 2010 at 09:10:07AM -0500, Christoph Hellwig wrote:
> On Fri, Nov 19, 2010 at 09:02:03AM -0500, Ted Ts'o wrote:
> > Deterministic TRIM is an option. It doesn't have to be implemented.
>
> For reasonable use it has to. That rationale for it is pretty clearly
> outline in ftp://ftp.t10.org/t10/document.08/08-347r1.pdf.
>
I think the author of that slide deck was being a little hysterical.
In nearly all of these cases, if the file system is comptently
implemented (i.e., you don't do a trim on anything but a deleted file
block, and _only_ when you know the deleted is committed, and only the
filesystem --- not non-privileged users --- are allowed to use the
TRIM command), there's no issue.
One case where I'll admit he may have a point is where you are using
software RAID, where if the TRIM is not determinstic, the only thing
which is safe to do is a TRIM of an entire RAID stripe. If the file
system doesn't know about the RAID geometry, then yes, in that case
determinstic TRIM is better --- although even then, it implies that
you have to rebuild the raid strip after you do a TRIM, which a
RAID-oblivious file system wouldn't do, and so you would still be
toast.
In the case of incompetently implemented, or buggy file systems, I'll
agree that non-determinstic trim offers a bunch of pitfalls --- but so
does deterministic trim in many of these cases. For example, one of
their disaster scenarios was where you do a trim on an allocated
block, and then proceed to read from that allocated block. That could
only happen if the trim happened but the delete didn't commit. But in
that case, the fact that data blocks would disappear for a non-deleted
file is also a disaster, and means the file system wasn't implemented
correctly.
The other case where non-determinstic trim could get you in trouble is
if (a) you give a user direct read access to a partition of the disk,
without any file system as an intermediary, and (b) you allow that
non-privileged user to issue TRIM commands to that partition. In that
case, it's possible that non-deterministic trim might allow you access
to non-deleted blocks in other partitions. But this goes back to my
observation that you're totally safe so long as TRIM is a privileged
operation and/or only allowed to be executed by the file system.
So yeah, deterministic trim is tricker, and you have to be more
careful, especially if you're using RAID, but it's not inherently a
disaster...
- Ted
next prev parent reply other threads:[~2010-11-19 15:41 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-18 7:36 [PATCH 1/2] fs: Do not dispatch FITRIM through separate super_operation Lukas Czerner
2010-11-18 7:36 ` [PATCH 2/2] ext4: Add EXT4_IOC_TRIM ioctl to handle batched discard Lukas Czerner
2010-11-19 16:19 ` Ted Ts'o
2010-11-19 16:26 ` Lukas Czerner
2010-11-20 1:37 ` Ted Ts'o
2010-11-18 13:06 ` [PATCH 1/2] fs: Do not dispatch FITRIM through separate super_operation Matthew Wilcox
2010-11-18 13:48 ` Josef Bacik
2010-11-18 14:19 ` Matthew Wilcox
2010-11-18 14:29 ` Christoph Hellwig
2010-11-18 17:19 ` James Bottomley
2010-11-18 17:22 ` Jeff Moyer
2010-11-18 17:41 ` James Bottomley
2010-11-18 20:04 ` Greg Freemyer
2010-11-18 21:42 ` Mark Lord
2010-11-18 21:44 ` Mark Lord
2010-11-18 21:50 ` James Bottomley
2010-11-18 22:07 ` Mark Lord
2010-11-19 1:33 ` Ted Ts'o
2010-11-19 3:44 ` Mark Lord
2010-11-19 13:58 ` Jeff Moyer
2010-11-18 23:52 ` Martin K. Petersen
2010-11-19 0:34 ` Mark Lord
2010-11-19 1:16 ` Greg Freemyer
2010-11-19 11:55 ` Christoph Hellwig
2010-11-19 14:01 ` Mark Lord
2010-11-19 14:06 ` Christoph Hellwig
2010-11-19 14:48 ` Mark Lord
2010-11-19 14:54 ` Christoph Hellwig
2010-11-19 15:24 ` Mark Lord
2010-11-19 15:34 ` Christoph Hellwig
2010-11-19 16:20 ` Greg Freemyer
2010-11-19 16:38 ` Christoph Hellwig
2010-11-19 18:06 ` Lukas Czerner
2010-11-19 18:10 ` Lukas Czerner
2010-11-19 18:14 ` Lukas Czerner
2010-11-19 19:29 ` Chris Mason
2010-11-19 1:49 ` Martin K. Petersen
2010-11-19 3:42 ` Mark Lord
2010-11-18 18:05 ` Jamie Lokier
2010-11-18 19:32 ` Markus Trippelsdorf
2010-11-18 21:45 ` Mark Lord
2010-11-18 21:50 ` Markus Trippelsdorf
2010-11-18 22:09 ` Mark Lord
2010-11-18 17:35 ` Lukas Czerner
2010-11-19 12:16 ` Steven Whitehouse
2010-11-19 13:53 ` Mark Lord
2010-11-19 14:02 ` Ted Ts'o
2010-11-19 14:10 ` Christoph Hellwig
2010-11-19 15:37 ` Ted Ts'o [this message]
2010-11-19 15:50 ` Christoph Hellwig
2010-11-19 16:16 ` Ted Ts'o
2010-11-19 14:50 ` Mark Lord
2010-11-19 15:35 ` Mark Lord
2010-11-19 15:44 ` Lukas Czerner
2010-11-19 16:30 ` Ted Ts'o
2010-11-19 22:49 ` Mark Lord
2010-11-25 2:48 ` Mark Lord
2010-11-25 4:23 ` Martin K. Petersen
2010-11-25 14:44 ` Mark Lord
2010-11-25 4:41 ` Greg Freemyer
2010-11-25 14:53 ` Mark Lord
2010-11-25 16:24 ` Greg Freemyer
2010-11-26 13:49 ` Mark Lord
2010-11-26 14:00 ` Lukas Czerner
2010-11-18 17:55 ` Chris Mason
2010-12-03 18:24 ` Ric Wheeler
2010-11-18 21:37 ` Mark Lord
2010-11-19 11:09 ` Christoph Hellwig
2010-11-19 13:54 ` Mark Lord
2010-11-19 14:40 ` Chris Mason
2010-11-19 14:53 ` Mark Lord
2010-11-19 14:57 ` Christoph Hellwig
2010-11-19 15:21 ` Mark Lord
2010-12-07 9:27 ` Christoph Hellwig
2010-12-07 16:52 ` Chris Mason
2011-06-02 4:52 ` Kyungmin Park
2011-06-02 8:14 ` Lukas Czerner
2011-06-03 2:06 ` Dave Chinner
2011-06-03 4:25 ` Kyungmin Park
2010-11-19 15:30 ` Mark Lord
2010-11-21 19:07 ` Valdis.Kletnieks
2010-11-21 20:20 ` James Bottomley
2010-11-18 14:31 ` Josef Bacik
2010-11-18 14:36 ` Tao Ma
2010-11-19 15:41 ` Ted Ts'o
2010-11-19 15:50 ` Christoph Hellwig
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=20101119153748.GE10039@thunk.org \
--to=tytso@mit.edu \
--cc=James.Bottomley@suse.de \
--cc=hch@infradead.org \
--cc=josef@redhat.com \
--cc=kernel@teksavvy.com \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=sandeen@redhat.com \
--cc=swhiteho@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