copy-on-write disabled (NOCOW) on /var ?

[saimisebe]

SUSE Linux and other distributions that use Btrfs as their file system set the NOCOW flag (chattr +C) for the entire /var directory. Siduction does not do this, and I'm really interested to know why.

[devil]

Hi,
welcome to siduction. For starters, you might want to read the btrfs/snapper parts of our manual: https://manual.siduction.org/index_en.html. That should explain a lot.

The installer creates subvolumes for the root directory @, the user directories @home and @root, the directory @var@log, and a subvolume @snapshots for system snapshots.Snapshots are not recursive, which is why siduction created these extra subvolumes: private and variable data from @home, @root and @var@log don't end up in a snapshot of @.SUSE's blanket +C goes with a separate, snapshot-excluded /var.

siduction's /var is mostly part of the snapshotted root, so the same flag wouldn't fit. siduction splits off /var/log instead of all of /var, so the rest of /var rolls back consistently with the system, and +C can be set on individual directories such as database or VM image paths.Besides that, /var/lib/dpkg records which package versions are installed. After a snapper rollback of @, it must match the restored /usr ane /etc. That is as far as my limited understanding goes. I am not the maintainer of btrfs/snapper for siduction, he is away for the weekend and will happily answer any questions below this point in the following days.

[scholle1]

Hallo and welcome.

@devil  has already explained the main point.

Additionally, you have to keep in mind that siduction is based on Debian sid – the extremely dynamic version of Debian. For example, I often found that after just four days, a `dist-upgrade` would result in 250 to 350 packages needing to be updated.
The /var/log/ directory mainly contains temporary data that are no longer needed after a reboot. We move this data to the @var@log subvolume to prevent a snapshot of @ from becoming unnecessarily bloated. However, many other files within /var/ are required for a clean rollback. That is why we do not set the +C flag for any directory during installation.

At siduction, we use snapper and the rollback feature built into snapper. It is important to follow the procedure described in the manual. This configuration has proven effective both on test systems and on my workplace PC. Since completing the siduction-btrfs package, I haven't had a single failed rollback attempt so far.