OpLocks and file sizes.

[Richard Sharpe]

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.

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