Please support read-write snapshots about snapper

[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.