On 8/27/20 3:37 AM, Christoph Hellwig wrote:
On Thu, Aug 27, 2020 at 10:29:05AM +0300, Amir Goldstein wrote:
I figured you'd say something like that :)
but since we are talking about dm-thin as a solution for predictable
behavior at the moment and this sanity check helps avoiding adding
new tests that can fail to some extent, is the proposed bandaid good enough
to keep those tests alive until a better solution is proposed?
Well, the problem is that a test that wants to reliable nuke data needs
to... *drumroll* reliably nuke data. Which means zeroing or at least
a known pattern. discard doesn't give you that.
I don't see how a plain discard is going to work for any file system
for that particular case.
This sort of brings up a good point, the whole point of DISCARD support
in log-writes was to expose problems where we may have been discarding
real data we cared about, hence adding the forced zero'ing stuff for
devices that didn't support discard. But that made the incorrect
assumption that a drive with actual discard support would actually
return 0's for discarded data. That assumption was based on hardware
that did actually do that, but now we live in the brave new world of
significantly shittier drives. Does dm-thinp reliably unmap the ranges
we discard, and thus give us this zero'ing behavior? Because we might
as well just use that for everything so log-writes doesn't have to
resort to pwrite()'ing zeros everywhere. Thanks,
Josef
