Default btrfs mount options and subvolume layout

Development Calamares
,
#1

image
image1023×589 60.2 KB

My goal is to make easy and sustainable snapshotting available in Calamares for a future manjaro release. On the roadmap there following subtasks:

  1. Make the calamares swapfile generation work with btrfs ([WIP] Btrfs swapfile handling by Chrysostomus · Pull Request #1597 · calamares/calamares · GitHub)
  • without its own subvolume with disabled cow, swapfile can lead to file system corruption
  1. Enable distro configurable subvolume layout in calamares so we can have more sophisticated layout
  • Current layout wastes space by snapshotting rapidly changing low value data like pacman cache, and restoring snapshots also loses the log files.
  1. Automatically install grub-btrfs, timeshift-autosnap and btrfs-maintenance if btrfs is chosen
  • Btrfs-maintenance is needed to free up space from accumulating metadata. Regular users should not need to worry about this manually. Timeshift-autosnap and grub-btrfs provide easy bootable snapshots on every update.
  1. Let users choose the filesystem (Allow selecting the FS from GUI · Issue #847 · calamares/calamares · GitHub)
  2. Patch timeshift to preserve the subvolume layout when restoring a snapshot (Preserve default subvolume name in snapshot restoration · Issue #694 · teejee2008/timeshift · GitHub)

This topic is for discussing what would be the best default subvolume layout for btrfs systems.

  • @ for / and @home for /home are required for timeshift to work.
    • Should @home use nodatacow by default? Cow causes abysmal performance for virtual machines and databases, which are commonly stored under /home directory. Datacow can be disabled on smaller scale too, but virtual machine directories don’t yet exist at install time. You lose some nifty features like reflink copies, but it might be easier for new users.
  • @log for /var/log would preserve log files between snapshot restorations. On the other hand, the system state would no longer be reflected in the logs. Pacman log might show you installed a package, but that package is no longer installed because you restored a snapshot.
  • @cache for /var/cache would prevent the differences between snapshots from growing too much, saving a lot of space.
  • @tmp for /var/tmp, same reason as cache subvolume
  • @mt for /var/lib/manjaro-tools would keep manjaro-tools from blocking automatic snapshot deletation. Not too interesting for most users, but very useful for developers
  • Some distros use a subvolume for /srv, but we are not a server distro so I don’t think that matters.

Does anyone have any other suggestions for btrfs support in manjaro? @eugen-b?

5 Likes
#2

Keep in mind that BTRFS only uses the mount options of the first sub-volume mount command used, i don’t know if this applies to the whole system or just a single drive.
I remember reading about the usage of a separate sub-volume for the swap file, but i think you needed to set the “nocow” flag on the created file instead of the sub-volume…

This could be mounted as a tmpfs IMHO :wink:

I would also suggest to use full names (with slash replaced by underscore) for the subvolumes wrt their respective mount points. Eg. @var_log for /var/log
Or perhaps create sub-volumes inside of sub-volumes to better preserve the tree hierarchy.
You would not need to use @ in the names of the sub-volumes inside other sub-volumes, the log sub-volume inside the @var sub-volume can be addressed as @var/log…

Disclaimer:

I have been fiddling with BTRFS in the past, but am not using it anymore…

#3

Chattr +C /home?

Good idea

I would very specifically want to avoid nested subvolumes because it

  • makes restoring snapshots really messy
  • prevents unused subvolumes from being automatically pruned
  • is not supported by timeshift
#4

Reading chattr(1) that might work:

(Note: For btrfs,…
…If the ‘C’ flag is set on a directory, it will have no effect on the directory, but new files created in that directory will have the No_COW attribute set.)

I can’t say it will or won’t work, you would need to test it out to be confident :wink:

Don’t understand why it would be messy, because it is just like a bind-mount over a mount point.
Never knew BTRFS auto-pruned unused sub-volumes…
Besides the sub-volumes you create will be populated anyhow, so no unused ones there.

I never used that app, but i’m sure it should be able to handle it same way as /proc etc…
Eg. Either by staying on same filesystem or by excluding directories.
Anyway i’m not familiar with it.

#5

Timeshift automatically deletes old snapshots to save space. If there are subvolumes nested under a snaphot/subvolume, you can’t delete that subvolume before deleting the subvolumes under it, and timeshift does not do it.

Have you tried it? At bare minimum you should not be able to delete the old @ if you have subvolumes nested inside it. And you will want to delete it eventually if you need to restore a snapshot, otherwise you end up with a ever growing diff that just eats up your disk uselessly.

Is there some specific advantage to having a nested subvolume layout instead of a flat one?

#6

https://www.spinics.net/lists/linux-btrfs/msg54931.html

#7

going to bed so just a quick response to that…
The benefit would be at least no need for a mount definition in /etc/fstab :wink:

#8

I don’t really see that as a major benefit, considering that fstab get’s written by the installer.

#9

Ok i just read that link, and can see how it can cause a problem now indeed… :+1:

You could ofcourse move the @ to a new name and reconstruct the final structure by using bind-mounts, but it would involve a bit more effort to use a snapshot indeed.
Anyway it was just an idea that poped-up in my mind back then when i fiddled with BTRFS a bit, i never tried the snapshot functionality of it yet.
So lets just drop that idea then :wink:

#10

I was actually wondering when Manjaro is going to provide support for BTRFS and I am happy someone took initiative. I am looking forward to see it come true and all the best with development.

On another note, please be aware of the grubenv limitation on BTRFS that I have hit myself. I have opened a thread about it, but fixed it meanwhile. You might want to take Fedora’s approach of making a separate partition for \boot that is on ext4. Feel free to correct my posts if you find any mistakes.