OpLocks and file sizes.

[Christopher R. Hertel]

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.

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.

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.

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org