[PATCH] smb2 FSCTL_SRV_COPYCHUNK support

[Richard Sharpe]

On Wed, Feb 15, 2012 at 7:05 AM, Volker Lendecke
<Volker.Lendecke at sernet.de> wrote:
> On Wed, Feb 15, 2012 at 06:51:58AM -0800, Richard Sharpe wrote:
>> 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.
>
> If you are using threads in your VFS module, how do you pass
> that up to the core SMB handling engine? The _send/_recv
> model makes it possible to keep the main engine
> single-threaded but opens up the possibility to do a
> threaded implementation in the VFS. See for example the
> vfs_aio_pthread module that Jeremy added lately. It still
> uses the posix AIO based VFS calls, but I think those should
> be converted to pread_send/recv and pwrite_send/recv, hiding
> the ugliness of the Posix API in some default module.

Actually, to be honest, I am only using a thread for 'background'
processing, where I push files up to S3 in the background. I am not
handling any VFS functions in threads. I don't believe that Samba 3 is
currently structured to allow that properly.

Even then, there are things that a real 'solution' would need to do
that my approach cannot do, but then it is really only designed to be
a demo of what you can do with a VFS and to explore how Samba 3 might
have to change, if we can find the energy to do so.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)