SMB3 Unix extensions

[ronnie sahlberg]

For your VFS presentation,   could I request that
* "Add discard API to the VFS layer"

be put on the roadmap ?    :-)

On Fri, Apr 28, 2017 at 10:41 AM, Jeremy Allison via samba-technical
<samba-technical at lists.samba.org> wrote:
> On Fri, Apr 28, 2017 at 12:38:03PM -0500, Steve French wrote:
>> On Fri, Apr 28, 2017 at 10:53 AM, Jeremy Allison <jra at samba.org> wrote:
>> > On Fri, Apr 28, 2017 at 10:56:28AM +0200, Stefan Metzmacher wrote:
>> >> Am 27.04.2017 um 18:13 schrieb Jeremy Allison:
>> >> > On Thu, Apr 27, 2017 at 04:36:30PM +0200, Stefan Metzmacher wrote:
>> >> >>
>> >> >> As far as I remember the idea was to just do this by file handle.
>> >> >>
>> >> >> So the client will just try to use the create context and the returned
>> >> >> create context defines the features available just for that file handle.
>> >> >
>> >> > Yes, that's right.
>> >> >
>> >> >> So NO global negotiation anymore!
>> >> >
>> >> > That was my original idea, but no, we need it. The reason is
>> >> > (David Kruse pointed this out) that it allows the client to
>> >> > determine if a UNIX create context that is ignored by the server
>> >> > is not returned because the server can't grant or doesn't want
>> >> > to grant UNIX handles on this part of the file system, vs
>> >> > a server that doesn't grant UNIX handles because it doesn't
>> >> > implement UNIX extensions.
>> >> >
>> >> > The initial Negprot extension tells the client that yes,
>> >> > I can do UNIX handles I just don't want to for this handle.
>> >>
>> >> Why does a client need to care about this?
>> >> Just avoiding a few bytes for the ignored create context?
>> >
>> > No, there was a good reason, I just can't remember
>> > it right now whilst I'm writing my second SambaXP
>> > talk :-).
>> >
>> > Steve, can you remember the use case ?
>>
>> The client needs to know if the server supports Unix Extensions before
>> it sends the SMB2 CREATE request so that it doesn't attempt to do an
>> unrecoverable
>> operation (create supersede/overwrite or delete e.g) which behaves
>> differently based
>> on whether case sensitive turns out to be supported or not.
>
> Thanks Steve ! I knew there was a unassailable use case here, I just
> forgot what it was (deep in writing a VFS presentation right
> now :-).
>