OpLocks and file sizes.

[simo]

On Tue, 2012-03-27 at 14:54 -0500, Christopher R. Hertel wrote: 
> On 03/27/2012 09:24 AM, Richard Sharpe wrote:
> > On Mon, Mar 26, 2012 at 10:24 PM, Ira Cooper <ira at samba.org> wrote:
> >> On Tue, Mar 27, 2012 at 12:37 AM, Christopher R. Hertel <crh at ubiqx.mn.org>wrote:
> >>
> >>> On 03/26/2012 09:21 PM, Richard Sharpe wrote:
> >>>> On Mon, 26 Mar 2012, Christopher R. Hertel wrote:
> >>>>
> >>>>> Some quick OpLock questions...
> >>>>>
> >>>>> Say we've got a file with an exclusive OpLock, and the client is
> >>> appending
> >>>>> to the end of the file (making it a bigger file, of course).  In that
> >>> case,
> >>>>> the server won't know the new size of the file until the writes have
> >>> been
> >>>>> flushed to the server, which would happen on close or OpLock break.
> >>>>
> >>>> My experience is that Windows does a one-byte write to extend the actual
> >>>> size of the file to the end of each write that would extend the file,
> >>> even
> >>>> though the data goes into the local cache.
> >>>>
> >>>> This has the advantage that ENOSPC can be reported sooner than file
> >>> close time.
> >>>
> >>> That's what I thought might happen, but I don't recall it being there in
> >>> [MS-CIFS].
> >>>
> >>> Anyone else have any clues on this?
> >>>
> >>
> >> No, but I have a good question: How would all this interact with platforms
> >> that use compression on their filesystems?  Any ZFS using platform would
> >> run into this issue if they enable compression.
> > 
> > Well, it errs on the side of caution. If there is not enough space to
> > handle the uncompressed blocks at the time the space-claiming write
> > occurs, it will fail :-)
> > 
> > Depending on the compressibility of the blocks, it might actually have
> > succeeded, but if the server is on the edge of being out of space,
> > then that is probably the correct thing to do anyway.
> 
> At one time, Microsoft was going to support access to compressed filesystems
> over SMB.  I have not checked to see if they actually do support that yet,
> though.

As far as I remember NTFS always supported compressing files.
That should be enough support ?

> If compressed filesystems are supported, we need to know how Windows handles
> them.  We may not need to implement exactly the same semantics, but we do
> need to understand the semantics well enough to know how any differences
> will impact the clients.

I am not sure that Windows treats them any differently, but testing
should be easy enough ? I guess you should just create a folder that is
shared and then compress it and see if there are any differences when
files are served ?
Now I would test if my 2 win VMs weren't completely broken and in need
of being completely reinstalled :-/

> That's also true for OpLock support in general.  It would be nice, for us,
> if the Linux kernel would only break leases for the same reasons that
> Windows does, but if there are additional reasons then the worst that will
> happen is that leases will be broken...so OpLocks will be broken.  That's
> not really too bad.

Right, I think the Linux kernel may break them on some metadata
operation where Windows wouldn't. Forgot details :(

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>