Re: Case for "datacow-forced" option

[David Sterba <dsterba@suse.cz>]

On Fri, Jan 07, 2022 at 08:30:46PM -0500, Remi Gauvin wrote:
> I notice some software is silently creating files with +C attribute
> without user input.  (Systemd journals, libvert qcow files, etc.)... I
> can appreciate the goal of a performance boost, but I can only see this
> as disaster for users of btrfs RAID, which will lead to inconsistent
> mirrors on unclean shutdown, (and no way to fix, other than full balance.)
> 
> I think a datacow-forced option would be a good idea to prevent
> accidental creation of critical files with nocow attribute.

Settings like that start some kind of "policy wars" and list of
exceptions, ie. who decides what the filesystem is allowed to do. A
mount option like you suggest would never allow to create a nocow file,
but having some scratch nocow files with better performance would be
nice to have. A global forced option would prevent accidental nocow
files while you as user would consider them important.

I'd rather see that fixed or made configurable on the side of
applications, the filesystem is really just providing features and
options and limits the policies and forced options to the users.

IIRC the systemd journals got +C because the write pattern is 'append'
that over time creates highly fragmented files. For VM images it's a
performance optimization at the cost of no checksums. Both performance
vs reliability trade off, that somebody made on behalf of users. But not
to satisfaction to all, wich I understand but don't agree that the
filesystem should be the level where this gets resolved.

If fragmentation is problem, eventual runs of the defrag ioctl on the
files can make the problem bearable.