OpLocks and file sizes.

[Ira Cooper]

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.

-Ira