[Samba] Enable the btrfs vfs module

[FroggyFlox]

During my research for #1910 , I came across a potential improvement of our global SMB implementation:

As of Samba 4.1.0, Samba carries a Btrfs VFS module that enables the support of Btrfs enhanced server-side copy offload:
https://wiki.samba.org/index.php/Server-Side_Copy#Btrfs_Enhanced_Server-Side_Copy_Offload

The Samba wiki reads:

Along with server-side copy support, a Btrfs specific Samba VFS Module was newly added with 4.1.0. This module improves the performance and efficiency of server-side copy operations on Btrfs backed shares, by using the Btrfs clone-range IOCTL. As of Samba 4.7.0, the VFS Module also offers support for FSCTL_DUPLICATE_EXTENTS_TO_FILE.

Sequence

1. Client issues FSCTL_SRV_COPYCHUNK or FSCTL_DUPLICATE_EXTENTS_TO_FILE requests to server
2. Server issues BTRFS_IOC_CLONE_RANGE filesystem ioctl

Result

• File data does not traverse network or disk
  • Filesystem meta-data update only
• No duplication of file data
  • Source and destination files share the same on disk data extents

It simply requires to add the vfs module on a per share basis:

   [share]
   vfs objects = btrfs

This could thus simply be added to the defaults in:

rockstor-core/src/rockstor/system/samba.py

Lines 50 to 64 in dcdb7ca

	def rockstor_smb_config(fo, exports):
	mnt_helper = os.path.join(settings.ROOT_DIR, 'bin/mnt-share')
	fo.write('%s\n' % RS_SHARES_HEADER)
	for e in exports:
	admin_users = ''
	for au in e.admin_users.all():
	admin_users = '%s%s ' % (admin_users, au.username)
	fo.write('[%s]\n' % e.share.name)
	fo.write(' root preexec = "%s %s"\n' % (mnt_helper, e.share.name))
	fo.write(' root preexec close = yes\n')
	fo.write(' comment = %s\n' % e.comment.encode('utf-8'))
	fo.write(' path = %s\n' % e.path)
	fo.write(' browseable = %s\n' % e.browsable)
	fo.write(' read only = %s\n' % e.read_only)
	fo.write(' guest ok = %s\n' % e.guest_ok)

As all three Rockstor variants currently have samba versions > 4.7.0, it should be possible across the board. @phillxnet , what do you think?

[phillxnet]

@FroggyFlox Re:

@phillxnet , what do you think?

I think that's a great idea, Nice find. Lets do it.

[FroggyFlox]

Lets do it.

Sounds good. I'm not sure (yet) how to test any performance improvement with it, but on paper I don't seem to see how it could be worse, at the very least.
I'll probably include this when working on #1910 .

[FroggyFlox]

Of note, there's also a snapper module of and when we get to implement it.
https://www.samba.org/samba/docs/current/man-html/vfs_snapper.8.html

Linking to #1491 for later consideration and evaluation.

[phillxnet]

@FroggyFlox Re:

I'll probably include this when working on #1910 .

It is of course your call, but it might make for a nice little concise pr to highlight this potentially significant 'feature' addition within the changelog. But we could also do that by bending our changelog convention.

I'm not sure (yet) how to test any performance improvement with it,

No me neither, though I'd imagine copying a large file, using a sufficiently new enough SMB client, from one subvol to another within the same pool should be much master and involve much less disk activity, it should be near enough instantaneous from the:

• Filesystem meta-data update only

bit. But it may not work across mount points, even though the metadata of subvols so mounted share metadata via there pool. Quite a nice tick that. I believe NFS has a similar trick but I'm not sure if it's yet btrfs 'happy'.

[phillxnet]

@FroggyFlox Re:

Of note, there's also a snapper module of and when we get to implement it.
https://www.samba.org/samba/docs/current/man-html/vfs_snapper.8.html

Linking to #1491 for later consideration and evaluation.

Yes snapper integration would be nice, and @sfranzen in the issue you linked, did a tone of work in that direction. Maybe once we are fully moved over we can pick that up again.

[FroggyFlox]

It is of course your call, but it might make for a nice little concise pr to highlight this potentially significant 'feature' addition within the changelog. But we could also do that by bending our changelog convention.

Good point. As it's not a pressing matter, I'll keep it separate so that we make sure it doesn't mess with the other vfs modules we'll have to add for #1910. That again looks like a good candidate for Testing channel, incidentally.

Thanks for your very informative input!

[phillxnet]

@FroggyFlox Given the recent interest in Samba performance on the forum of late:
https://forum.rockstor.com/t/samba-write-speeds-are-ultra-slow/8869/24
Maybe this issue should be added to our next Milestone once we have our 5.0.0-0 testing branch release out (next few days hopefully).
WARNING -- RENEWED TESTING PHASE 5.0.0-0 -- (DEVELOPERS ONLY) #2610

[FroggyFlox]

Good idea.