Using HyperV with Samba 4.2

[Richard Sharpe]

On Fri, Oct 17, 2014 at 8:44 AM, Richard Sharpe
<realrichardsharpe at gmail.com> wrote:
> On Fri, Oct 17, 2014 at 7:05 AM, Richard Sharpe
> <realrichardsharpe at gmail.com> wrote:
>> On Fri, Oct 17, 2014 at 6:49 AM, David Disseldorp <ddiss at suse.de> wrote:
>>> On Wed, 15 Oct 2014 05:05:24 -0700, Richard Sharpe wrote:
>>>
>>>> Hi folks,
>>>>
>>>> Sending this out in the hope that it will be useful to some people.
>>>
>>> Thanks!
>>>> Secondly, you will need to create a VFS module (or modify your
>>>> existing VFS module if you have one) to assert that your file system
>>>> supports compression and to implement the set_compression and
>>>> get_compression entry points.
>>>
>>> I'm a little surprised by the client behaviour here. With
>>> FILE_FILE_COMPRESSION missing from the FS capabilities, the server
>>> doesn't support compression, so explicitly disabling it on a per-file
>>> basis shouldn't be necessary.
>>
>> Hmmm, maybe I need to look more closely at the capture. It was asking
>> to disable compression so maybe the people who supplied me with the
>> capture were mistakenly claiming they supported compression.
>
> Actually, I don't need to.
>
> Here is the key test in fsctl_set_cmprn:
>
>         if ((fsp->conn->fs_capabilities & FILE_FILE_COMPRESSION) == 0) {
>                 DEBUG(4, ("FS does not advertise compression support\n"));
>                 return NT_STATUS_NOT_SUPPORTED;
>         }
>
> And STATUS_NOT_SUPPORTED is what I saw on the wire.
>
> The client was issuing that FSCTL despite the fact that the server
> told it compression was not supported.

I have talked to the people at Hedvig and they confirm that they were
testing with the default Samba VFS on Linux, so it does indeed appear
like Windows is sending the set compression request even though it
knows that it should not be needed.

Strange.

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