[PATCH] smb2 FSCTL_SRV_COPYCHUNK support
realrichardsharpe at gmail.com
Wed Feb 15 07:51:58 MST 2012
On Wed, Feb 15, 2012 at 5:05 AM, Volker Lendecke
<Volker.Lendecke at sernet.de> wrote:
> On Wed, Feb 15, 2012 at 02:00:51PM +0100, David Disseldorp wrote:
>> On Wed, 15 Feb 2012 13:49:03 +0100
>> Volker Lendecke <Volker.Lendecke at SerNet.DE> wrote:
>> > On a second thought: Why do we need copychunk in the VFS at
>> > all? We have pread and pwrite in both sync and async
>> > flavor. We could handle the copychunk stuff in the core smbd
>> > building upon those. Or are there native file systems that
>> > do copychunk?
>> Yes, btrfs via the BTRFS_IOC_CLONE_RANGE ioctl, and better yet it's
>> only a metadata operation. This is plumed in as part of the patchset.
>> Other COW based filesystems (ZFS etc.) may go down a similar path.
> Ok, that might be fast enough to be done in a sync fashion.
> The default implementation though would probably do it via
> pread/pwrite which might be just slow enough to justify it
> to be done asynchronously.
[resent to the list because first one was only a reply to Volker
because I had not had any coffee]
With respect to an earlier question about whether or not FSCTLs need
to be done in the VFS, I would very much prefer that they are for a
couple of reasons:
1. It gives VFS writers the ability to handle those operations in
their specific ways and to define their own FSCTSLs if they want to
without them having to modify the body of Samba.
2. I want that functionality in a VFS for Amazon's S3 service that I am writing.
With respect to making the VFS thread safe, perhaps we should invest
some time on that. I am using a thread in the VFS module mentioned
above, although that is not really the correct model. However, it has
not really exposed too many issues so far. You can't use talloc_tos()
in the VFS code if those objects are going to be passed to threads but
that is surely a matter of documentation.
I also think it is perfectly fine for Samba to provide a default
implementation of copychunk, perhaps in vfs_default that calls back
into Samba. Then a btrfs- or ZFS-specific VFS could implement the
file-system direct approach.
More information about the samba-technical