OpLocks and file sizes.
realrichardsharpe at gmail.com
Wed Mar 28 08:14:15 MDT 2012
On Tue, Mar 27, 2012 at 11:08 AM, J. Bruce Fields <bfields at fieldses.org> wrote:
> On Mon, Mar 26, 2012 at 07:21:13PM -0700, 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.
> It also means you're waiting for a round trip on every write. If you're
> going to do that, wouldn't you be better off sending more than a byte of
> data while you're at it?
True. Also, I last observed this maybe 8 years ago. I do not know if
modern versions of Windows still do that, but lots of applications do
not check the return code from close.
More information about the samba-technical