On Fri, Feb 14, 2014 at 12:14:42PM -0500, Martin K. Petersen wrote:
> >>>>> "Ted" == Theodore Ts'o <tytso@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
