On Tue, Jul 21, 2015 at 2:33 AM, Matthias G. Eckermann
On 2015-07-20 T 16:51 -0600 Chris Murphy wrote:
On Mon, Jul 20, 2015 Matthias G. Eckermann wrote:
Am 20. Juli 2015 20:20:36 MESZ, schrieb Chris Murphy:
On Mon, Jul 20, 2015 at 11:13 AM, Matthias G. Eckermann wrote:
And with respect to the number of snapshots: size is the limit.
In theory that's true, in practice Btrfs itself has problems with many snapshots at the moment irrespective of available free space in the volume.
my experience with btrfs is different in the positive way.
Can you point us to SUSE bugreports indicating the opposite?
No, that information is on the upstream linux-btrfs@ list. It's come up several times, in particular when deleting many snapshots because the metadata for all extents involved must be visited and rewritten so a lot of deletion can cause a lot of writing.
While this is true, it does not limit the number of snapshots. It only determines the time to delete snapshots (which is a different question).
I said in particular when, not only when or especially when.
On of the more well knowns cases is with VM images and databasess, even when not snapshotting and even when using chattr +C.
That is a different question than the _number_ of snapshots, and frankly, the same is true for all CoW filesystems (including for example ZFS).
It isn't orthogonal to the number, because new writes are cow even on nocow files, when they are reflink copied or the containing subvolume is snapshot. So yes the number of snapshot will affect the fragmentation and performance and it also depends on the concurrency of writes to the copies. Pretty much the only thing that's next to free is the snapshot or reflink copy operation itself. Any additional operations are going to be impacted and not always in obvious ways.
vmm-libvirt places its images in /var/lib/libvirt/images and isn't excluded from snapper, so that's a problem source. But snapshotting makes the problem worse, quickly. http://www.spinics.net/lists/linux-btrfs/msg40563.html
As far as I am aware, VM images under /var/lib/libvirt are automatically created with NoCOW on openSUSE (>13.1) and SUSE Linux Enterprise 12 systems. Please check. If this is not the case, it's worth a bug report.
That does matter for performance reasons, but also that directory should be a subvolume so it doesn't get snapshot along with /, and that subvolume needs to be in fstab so that upon rollback the VM images don't disappear. I filed that bug as: https://features.opensuse.org/319299 I haven't tested whether virt-manager on opensuse defaults to -nocow=on for images; that's not the case with qemu-img or virt-manager upstream. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org