On Fri, Jun 11, 2021 at 07:15:29PM +0800, Qu Wenruo wrote:

On 2021/6/11 下午6:55, Martin Raiber wrote:

quoted

On 11.06.2021 02:18 Qu Wenruo wrote:

quoted

On 2021/6/10 下午10:32, Martin Raiber wrote:

But this still means, all other regular end user can hit a case where
they set nodatasum for a directory and later corrupt their data.

So this where I'd say give users what they ask for, like the usecase
where the data correctness is done on another layer or solved by
completely different approach like reprovisioning in case of errors.

I would certainly not recommend to turning off nodatasum in general but
if thre's a usecase with known pros and cons then I'm for allowing it
(if feasible on technical grounds).

An example from past is (not)allowing DUP on a single device for data.
The counterargument for that was something like "but it won't help on SD
cards anyway", but we're not choosing hw or usecase for users.

I had a prototype to do "nometasum", it's obviously simple but with lack
of usecase I did not push it for a merge. If there's an interest for a
checksum-free usecase we can do that.

This will increase the corruption loss, if user just migrate from older
kernel to newer one.

Yeah, you can blame the users for doing that, but I'm still not that
sure if such behavior change is fine.

Especially when this increase the chance of data loss.
It may be fine for ceph, but btrfs still have a wider user base to consider.

So the silent change would make a difference, but it's still after a
decision to do nodatasum, that gets on a directory and inherited.
That it actually happens is not what user asked for, so from that point
I think it's the other way around.

quoted

Furthermore it depends on the use-case if corruption affecting
one page, or a whole compressed block is something one can live with.

That's true, but my point is, at least we shouldn't increase the data
loss possibility for the end users.

If in the past, we allowed NODATASUM + compression, then converting to
current situation, I'm more or less fine, since it reduce the
possibility of data loss.

I'm going to read the reasoning again.