Re: [RFC PATCH] btrfs-progs: prop: add datacow inode property

[Dominique Martinet <asmadeus@codewreck.org>]

Thanks for the reply!!

Nikolay Borisov wrote on Tue, Apr 05, 2022 at 05:21:06PM +0300:
> On 30.03.22 г. 8:45 ч., Dominique Martinet wrote:
> > If you just say 'no' I'll bite the bullet and install e2fsprogs just for
> > btrfs and document the command, but as things stand my users (embedded
> > device developpers) have no way of disabling cow for e.g. database
> > workloads and that's not really good long-term.
> 
> Just my 2 cents: I think we should strive to rely as much as possible on the
> generic infrastructure where we can. The nocow options is one such case. The
> way I see it btrfs property is used to manage features which are indeed
> specific to btrfs and have no generic alternative.

That's not what the man page says:

       btrfs property provides an unified and user-friendly method
       to tune different btrfs properties instead of using the
       traditional method like chattr(1) or lsattr(1).

I appreciate not wanting to duplicate code however, but documentation
should be adjusted if that is what we want to do.


> What's more I don't see how 'chattr +C /some/path' can be considered
> 'complex' to teach someone, plus chattr is a standard linux utility.

Well, '+C' is harder to remember than 'datacow', so in that sense yes it
is more complex to teach someone from that regard.

My users are mostly windows users who barely ever used linux, and I'm
throwing a listing of command they should use in which conditions in our
product manual, so it's much more coherent to have a group of 'btrfs
property set' commands where I explain ro/compression/datacow together
than resort to 'chattr' on one.

Yes, there are other generic chattr commands that work on btrfs (append
only, immutable come to mind immediately), but compression and datacow
are historically handled differently for btrfs... Admittedly not a very
good reason, the above and manual page paragraph I quoted are more
important to me.
(Speaking of which if the mountpoint has compress=smth, lsattr doesn't
list +c and `btrfs property set x compression none` doesn't seem to
cancel it, so I see no way of disabling compression on a single file in
that case on 5.17.1 -- didn't that use to work?)



Another reason for me would be that, on alpine linux, chattr is packaged
as part of e2fsprogs-extra, which grows my root filesystem by a whole
2MB.

This might not seem much, but when I have to make everything fit in
<200MB every bit counts. Adding a new flag here doesn't increase the
size of the system much.
(busybox has a chattr implementation, but for some reason it's not
enabled on alpine linux -- I'll request to consider enabling it after
checking how big it is if this isn't wanted here)


Thanks,
-- 
Dominique