Univention Bugzilla – Bug 55523
severe performance degradation when using samba's btrfs VFS object
Last modified: 2022-12-29 11:36:44 CET
Enabling samba's "btrfs" VFS object on a share that is a btrfs mount (specifically, a subvolume, not sure if that makes a difference), performance of access from a Windows 10 client drops very very dramatically; e.g. right click on a file then "properties" takes tens of seconds. The /var/log/samba/log.smbd log is filled with many many copies of messages like ../../source3/modules/vfs_btrfs.c:503(btrfs_fget_compression) btrfs_fget_compression: /proc open of /proc/self/fd/47 failed: Interrupted system call and ../../source3/modules/vfs_btrfs.c:503(btrfs_fget_compression) btrfs_fget_compression: /proc open of /proc/self/fd/40 failed: Permission denied According to https://bugzilla.samba.org/show_bug.cgi?id=15004 this is mostly bogus, and upstream samba has silenced that message (except in debug mode). I think it would be worth to test whether the performance drop is "only" due to the logging overhead, and in this case to backport the trivial little upstream patch.
I wasn't sure whether you would consider this a "key scenario" or a "secondary scenario", so I took a guess. Feel free to correct.
UCS version 5.0-2 samba and samba-vfs-modules package version 2:4.16.2-1A~5.0.0.202211091951 linux-image-4.19.0-22-amd64 version 4.19.260-1 btrfs-progs 4.20.1-2 To be complete (but my guess is it does not matter for this issue), some shares are also under snapper management for automated snapshot management and have the samba snapper VFS module enabled. Low number of snapshots (less than 5 per subvolume), so the btrfs performance degradation that comes with a lot of snapshots should not be a factor. snapper 0.8.2-1