From ArchWiki

New article structure

Thinking about adding two new subsections (modify and delete configurations), I observed the structure of the article was not grouped. Could be better to change article structure to (e.g.):

1       Installation
2       Configuration
2.1       Create a new configuration
2.2       List configurations
2.3       Modify a configuration (new subsection -> snapper -c config set-config option=value)
2.4       Delete a configuration (new subsection -> snapper -c config delete-config)
3       Snapshots
3.1       Take snapshots
3.1.1       Automatic timeline snapshots       Enable/disable       Set snapshot limits       Change snapshot and cleanup frequencies
3.1.2       Manual snapshots       Simple snapshots       Pre/post snapshots
3.1.3       Snapshots on boot
3.2       List snapshots
3.3       Delete a snapshot
4       Access for non-root users
5       Tips and tricks
[... same as original ...]

This would group important topics, such as configurations and snapshots. I think it would be a better way to structure the article. --AlonsoLP (talk) 10:45, 22 January 2019 (UTC)

New page suggestion: Btrfs Snapshots

The main article about Btrfs is already very long but does not cover the tools for working with snapshots, even though some of these tools are already in the repositories, and are popular. There is this article about Snapper, that covers some of these tools, but the article about snapper should focus on Snapper itself, and maybe tools based on snapper, but not independent tools. It is also important to show which tools are based on snapper and which tools only require btrfs itself. The Snapper article mixes both tools. -- Teateawhy (talk) 03:09, 11 January 2020 (UTC)

A new layout

Hi Archlinux wiki contributors,

I've wrote a guide for LUKS+Btrfs installation, completed with a new layout. What about adding the new layout to Snapper page?

Cheers -- S0x9v (talk) 13:24, 4 December 2020 (UTC)

I would say even the revision you proposed in Suggested Filesystem Layout section is a bit bloated. I totally agree with Lahwaacz's reversion. In my understanding, the suggested layout you proposed in your earlier edits serves multiple purposes that are easily separable:
  • A better alternative to the ugly file structure caused by snapper rollback as described here. Here I would actually agree that mounting 0/snapshot is a good idea because it preserves the functionality of snapper rollback.
  • Making separate subvolumes for Snapper#Preventing_slowdowns.
  • Making separate subvolumes for preserving information during rollbacks as in Snapper#Preserving_log_files. Maybe even the subvolume for /home should be put into that section and that section renamed to "Preserving Information".
So for simplicity's sake, they should be put in separate places so that readers of the wiki can choose what to adopt. A personal blog might be a better place for the edits you are proposing.
Fanzhuyifan (talk) 15:26, 4 December 2020 (UTC)
Actually 0/snapshot does not preserve the functionality of snapper rollback:
snapper internally reserves 0 for current system, as you can see here. Also 0/snapshot lacks info.xml. Therefore installing system into 0/snapshot is purely for aesthetic reasons (last ASCII art). We still need to force snapper rollback --ambit classic when rolling back for the first time since snapper does not recognize 0/snapshot.
As for "bloated", the layout I proposed is taken directly from various root on ZFS installations. As in here and here. They are not bloated, just necessary for different use cases. It's essential to have a separate /var/lib/libvirt and apply chattr +C /var/lib/libvirt on it if you use qcow for QEMU disk image, for example.
I agree the separation is not needed for all use cases and therefore should be put into Snapper#Preventing_slowdowns and Snapper#Preserving_log_files, as you've proposed. But this info must be on the wiki page to inform potential users, not on some unindexed blog page. It can actually be a quite frustrating experience when you experienced terrible performance with your system, only to find out much later that there's some gotchas laying around.
User homes can be automatically created as subvolumes with useradd -m --btrfs-subvolume-home $username.
Cheers, -- S0x9v (talk) 08:34, 5 December 2020 (UTC)
My bad. I thought "In this scenario, after the initial setup, snapper needs no changes, and will work as expected" meant that snapper rollback would work as expected.
I don't use the "qcow for QEMU" you mentioned and I don't know what it is. But if the configurations you are proposing are only relevant for those users, I would suggest putting the relevant materials in the wiki page for QEMU.
As for the Ubuntu and Debian default layouts you mentioned, Arch Linux is not Ubuntu or Debian. We start with no partition and lets the user take full reign from then on. In line with the principles of Arch_Linux#Simplicity, I would say let's just keep the most essential configurations and guides for snapper on this page, and move the advice and cautions to their respective places.
Fanzhuyifan (talk) 08:59, 5 December 2020 (UTC)
snapper rollback will work as expected, only rolling back for the first time needs snapper rollback --ambit classic.
Cheers, -- S0x9v (talk) 10:16, 5 December 2020 (UTC)
I didn't know that! I think if you are going to mention this, you should mention the whole thing -- say that only the first roll back needs special treatment and maybe provide a brief explanation of the reasons, if possible.
Fanzhuyifan (talk) 11:54, 5 December 2020 (UTC)
.qcow is the default virtual disk format for QEMU, which stands for QEMU Copy-on-Write. The underlying filesystem already has this attribute and another layer on it will induce significant performance penalty.
I think this piece of information is more relevant here than in QEMU:
Considering the layout is determined during installation, and everyone installing Archlinux on Btrfs will be referencing to Snapper#Suggested_filesystem_layout. We need to tell them right here, in a note, that if you are going to run virtual machines you must create this additional subvol and disable CoW or the performance will suffer. Also /etc/fstab will be generated in the next step with genfstab, which includes this subvol.
Cheers, -- S0x9v (talk) 10:16, 5 December 2020 (UTC)
In that case, I would say a new section titled "Virtual Machine Recommendations" would be a quite reasonable place to put your tips that apply for virtual machine users.
Fanzhuyifan (talk) 11:54, 5 December 2020 (UTC)
Yes, Arch Linux is not Ubuntu or Debian, as Lahwaacz have already pointed out, but more detailed. I've incorporated Archlinux specific changes to my layout.
Cheers, -- S0x9v (talk) 10:16, 5 December 2020 (UTC)
There is some very interesting stuff here, and in User_talk:Lahwaacz#Btrfs_layout. It's difficult to find for the average user though, shouldn't the suggested layout be updated to reflect those tips ? ie {@,@home,@var_cache,@var_log,@var_tmp} ? -- Cvlc (talk) 03:35, 25 November 2021 (UTC)

Deleting Orphaned snapshots (and snapshots in general)

Snapper marks snapshots as read only, so rm fails with a cascade of "Read-only filesystem" errors. The solution is to either remove the subvolume with btrfs subvolume delete or set it as read-write before removing it. Should this be mentioned somewhere?

It also might be helpful to mention that the subvolume itself is not the numbered directory, it's a subdirectory named "snapshot"; attempting to use btrfs subvolume commands on the numbered snapshot directories will also fail.

Rbuchberger (talk) 13:39, 5 May 2021 (UTC)

Deleting a subvolume is not specific to Snapper. -- Lahwaacz (talk) 16:29, 5 May 2021 (UTC)

Preserving log files

See this longer systemd issue: "/var stays busy at shutdown due to journald". —This unsigned comment is by SamirNassar (talk) 22:49, 26 November 2021 (UTC). Please sign your posts with ~~~~!