linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-fsdevel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH RFC] block: use discard if possible in blkdev_issue_discard()
Date: Fri, 14 Feb 2014 20:29:01 -0500	[thread overview]
Message-ID: <20140215012901.GA28307@thunk.org> (raw)
In-Reply-To: <yq1ioshobul.fsf@sermon.lab.mkp.net>

On Fri, Feb 14, 2014 at 12:14:42PM -0500, Martin K. Petersen wrote:
> >>>>> "Ted" == Theodore Ts'o <tytso@mit.edu> writes:
> 
> Ted,
> 
> [issue_zeroout_or_write_same]
> 
> Ted> How do people think I should implement this functionality?  I see
> Ted> three possible choices:
> 
> I did think about doing this when I originally implemented support for
> WRITE SAME. However, one caveat is that there are corner cases where
> devices that -- despite reporting that they return zeroed data after
> TRIM -- will return non-zeroes. The issue being that TRIM is a hint and
> there are no hard guarantees. Even if a device reports DRAT/RZAT.

So is this the same as how some devices will turn into bricks if you
send trim commands too quickly --- i.e., they are buggy, crappy
devices?

Or does the T10/T13 spec for DRAT/RZAT really say: "determinisitc:
--- you keep using that word.  I do not think it means what you think
it means....."?

Basically, who was practicing engineering malpractice?  The SSD
vendors, or the T10/T13 spec authors?

If this is a case that there is just a bunch of crap SSD's out there,
then maybe we should still do this, but just not enable it by default,
and force users to manually configure mount options or fstrim if they
think they have devices that are competently implemented?

      	   		     	 	     - Ted

  reply	other threads:[~2014-02-15  1:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-14  4:32 [PATCH RFC] block: use discard if possible in blkdev_issue_discard() Theodore Ts'o
2014-02-14 13:05 ` Christoph Hellwig
2014-02-14 14:57   ` Theodore Ts'o
2014-02-14 17:14 ` Martin K. Petersen
2014-02-15  1:29   ` Theodore Ts'o [this message]
2014-02-17 16:44     ` Martin K. Petersen
2014-02-17 19:19       ` Theodore Ts'o
2014-02-18  1:31         ` Martin K. Petersen
2014-02-18  2:17           ` Theodore Ts'o
2014-02-18  3:44             ` Martin K. Petersen
2014-02-18  5:47               ` Theodore Ts'o
2014-02-19  2:20                 ` Martin K. Petersen
2014-02-17 16:41   ` Lukáš Czerner

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=20140215012901.GA28307@thunk.org \
    --to=tytso@mit.edu \
    --cc=axboe@kernel.dk \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=martin.petersen@oracle.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;
as well as URLs for NNTP newsgroup(s).