Please support read-write snapshots

[rrthomas]

I want to use snapper to create a "Time Machine" that can take me arbitrarily far back in time. This works fine provided I don't run out of disk space. In my early trials, I ran out of disk space rapidly because of large, changing files. I reorganized my user directory so that most of these now live in ~/.local/var, which is a symlink to /usr/local/var/$HOME, which is outside my @home volume, but unfortunately, I still find myself filling my (reasonably capacious) disk from time to time with "mistakes", and currently all I can do is erase all my snapshots, and reboot the Time Machine.

If I could use read-write snapshots (as snapper once supported, before btrfs added support for read-only snapshots), then I would be able to fix my mistakes by hand: potentially tedious, but at least I'd have the choice. Deleting a few large files in a number of snapshots is not so bad after all.

[aschnell]

Read-write snapshots have several disadvantages, e.g. already accessing the snapshot can cause atime updates which cause disk space allocation. Also the filelist cache of snapper gets out of sync.
So I do not intent to implement creation of read-write snapshots.

But with newer btrfs tools you can set the read-only status of a subvolume, e.g. btrfs property set /.snapshots/1/snapshot ro false. The kernel has the ioctl since a long time. For your use-case that should be fine.

[rrthomas]

Thanks very much for the tip. Typically, I will want to run "find" on all my snapshots to discover in which a particular large file occurs, the make all of them read-write and delete the file. Obviously, it would be easier if they were all read-write in the first place (which I guess I could do by suitable extensions to my snapper config). Does it make a difference if I run with noatime, and what is the implication of the filelist cache getting out of sync?

[aschnell]

Mounting with noatime should avoid the problem with disk space allocation just by looking at snapshots.

The filelist cache getting out of sync will of course make the snapper status and diff command display wrong data. During undochange this can lead to error e.g. when snapper wants to copy a file from a snapshot to the system when the file does not exist in the snapshot anymore.

[rrthomas]

Thanks very much. Since I do not intend to use these snapshots for rollback (at least, not using the rollback command: typical use is to roll back manually a single file, by copying if necessary), the problem with the cache is not serious for me, so noatime should help.