Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#68706 - [mariadb] systemd-tmpfiles prints errors if btrfs compression was enabled before installing mariadb

Attached to Project: Arch Linux
Opened by wtf (oi_wtf) - Sunday, 22 November 2020, 15:41 GMT
Last edited by Doug Newgard (Scimmia) - Sunday, 22 November 2020, 23:49 GMT
Task Type Bug Report
Category Packages: Extra
Status Assigned
Assigned To Christian Hesse (eworm)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No



The following error was printed after installing mariadb on my system:

(1/3) Reloading system manager configuration...
(2/3) Creating temporary files...
Cannot set file attribute for '/var/lib/mysql', value=0x00800000, mask=0x00800000, ignoring: Invalid argument
(3/3) Arming ConditionNeedsUpdate...

I found out that this was due to btrfs' compression feature, which seems to conflict with the nocow `+C` flag.
It seems `+c` and `+C` cannot be enabled together.

Maybe compression can be disabled too in /usr/lib/tmpfiles.d/mariadb.conf ?
Is that sensible or would disabling it maybe create issues on other filesystems?
I could live with knowing to just do `chattr -c /var/lib/mysql` after installing...

Additional info:
* package version(s):

# pacman -Q mariadb systemd
mariadb 10.5.8-1
systemd 246.6-1

* config and/or log files etc.

# cat /usr/lib/tmpfiles.d/mariadb.conf
d /run/mysqld 0755 mysql mysql -
d /var/lib/mysql 0700 mysql mysql -
h /var/lib/mysql - - - - +C

# cd /var/lib
# lsattr | grep mysql
--------c----------- ./mysql

* link to upstream bug report, if any:

I have reported a similar issue to systemd upstream regarding /var/log/journal and /usr/lib/tmpfiles.d/journal-nocow.conf here:

Steps to reproduce:

1. Enable compression feature of btrfs on /var/lib or on the whole filesystem before installing Arch Linux and/or mariadb
2. Install mariadb
3. Observe above error messages and the NO-COW flag not being set.
This task depends upon

Comment by Doug Newgard (Scimmia) - Sunday, 22 November 2020, 16:36 GMT
Seems to work fine with the compress= mount option.
Comment by wtf (oi_wtf) - Sunday, 22 November 2020, 19:16 GMT
Well, I had used `btrfs property set / compression lzo` on the filesystem/subvolume root before installing arch
and have not used with the compress= mount option, since there are cases where I want to disable compression per directory.
So I have not tested with the mount option...

so maybe nocow does not "confict" in this case, or just no error produced? A different logic used?
It could also be a bug in how btrfs handles attributes, and setting both attributes actually should work? I don't know.
All I know: When having done `chattr +c` or `btrfs property set...` on a dir a following `chattr +C` or similar fails, same for the other way round if `chattr +C` was done first, a `chattr +c` fails.
This leads to errors when systemd-tmpfiles wants to set the nocow attribute, and the messages are not very clear about what happens, but the latter is clearly a systemd-tmpfiles issue...

Comment by wtf (oi_wtf) - Sunday, 22 November 2020, 19:27 GMT
Well, it seems nocow and compression being mutually exclusive is expected behavior, since `man 5 btrfs` states this twice for the `nodatacow` option:

> Nodatacow implies nodatasum, and disables compression
> ...
> Note: If nodatacow or nodatasum are enabled, compression is disabled.

That at least it explains the behavior of `chattr` somewhat...
With the compress mount option +C is probably disabling compression for that directory, too. But does not complain because it's not compress-force= or something like that?
Comment by Doug Newgard (Scimmia) - Sunday, 22 November 2020, 23:48 GMT
"and have not used with the compress= mount option, since there are cases where I want to disable compression per directory."

That's exactly what the mount option and the +X attribute are for. What you've got is mostly for when you want to selectively enable compression per directory. In this case, that means you've specifically chosen to compress /var/lib/mariadb/*, which makes this more of a configuration issue IMO.
Comment by wtf (oi_wtf) - Monday, 23 November 2020, 00:59 GMT
huh? chattr does not have +X? All documentation says the X attribute can only be set by the kernel, not using chattr.

Disabling compression I've done mainly for directories containing many video files to not have the chance of wasting performance, but that may have been me "optimizing" something that didn't need to be (anymore), it just became a habit, I guess.
There was another reason I started doing the attributes instead of mount options, now that I think of it...

By setting the compression attribute I wont have to specify the mount option on every machine a filesystem gets mounted on.
Of course that not really applicable to the root fs, but I recently did a bunch of more "mobile" drives that get mounted on different systems and it just became the standard way of how I set up new filesystems, so a habit again... :D
And since this was the first time after that setting up a new root filesystem, I just did it the way I always did it...

> In this case, that means you've specifically chosen to compress /var/lib/mariadb/*, which makes this more of a configuration issue IMO.

That does make sense, from the "systems viewpoint", though it was more like /var/lib/mariadb inheriting the compression flag from /var/lib, /var and /.
So from my "users viewpoint" it's actually more like: I've specifically chosen to compress / and its children. Not giving much thought to "its children".
But maybe the mount option really is the better way of expressing that intent.

I think I'll just have to remember to rather do the mount option for "non-mobile"/"system" drives... and remember it every time when manually mounting...
Comment by Christian Hesse (eworm) - Monday, 23 November 2020, 08:24 GMT
Are you happy with the systemd upstream changes?

That gives an idea about what happens at least.

After all this is just a warning, IMHO. User may decide what option is preferred and set it.
I think there's nothing to change here.
Comment by wtf (oi_wtf) - Monday, 23 November 2020, 11:50 GMT
Yeah, I'm fine with that, if the improved "error" message gets merged into systemd-tmpfiles.
Then one would not have to search the internet to find out what's wrong and that's perfectly fine with me.
Comment by Christian Hesse (eworm) - Friday, 18 December 2020, 07:58 GMT