On Fri, 14 Feb 2014, Martin K. Petersen wrote: > Date: Fri, 14 Feb 2014 12:14:42 -0500 > From: Martin K. Petersen <martin.petersen@xxxxxxxxxx> > To: Theodore Ts'o <tytso@xxxxxxx> > Cc: linux-fsdevel@xxxxxxxxxxxxxxx, Jens Axboe <axboe@xxxxxxxxx> > Subject: Re: [PATCH RFC] block: use discard if possible in > blkdev_issue_discard() > > >>>>> "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. That was my experience as well back when I did discard testing. The situation however was even worse than that because I've seen the content of discarded block to change over time - it still contained data right after the discard, however after a while it would read zeros. While it's true that this was couple of years ago and those devices I've seen this on had probably faulty firmware but, even today I would not feel comfortable enabling this by default. Thanks! -Lukas > > So the reason I didn't end up adding a call like yours is that the > result is non-deterministic. The call would have to be "please zero this > block range but I don't *actually* rely on getting zeroes back". I don't > have a problem providing a function that does that as long as the > best-effort limitation is made crystal clear. > > -- 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
