Handling quota and out of space issues while holding an OpLock
rsharpe at richardsharpe.com
Tue Sep 21 07:00:52 GMT 2004
On Mon, 20 Sep 2004, Peter Waechtler wrote:
> Am Sonntag, 19. September 2004 19:11 schrieb Richard Sharpe:
> > Hi,
> > I have noticed that windows clients tend to send requests to extend the
> > file size even though they are holding an oplock on a file.
> > It struck me that this must be so they can deal with issues like out of
> > quota or out of space at the point at which they occur, and thus give the
> > application a useful error message, rather than trying to deal with these
> > things at file close time (ie, trying to flush lots of data to the file
> > server could result in an EXQUOTA or NOSPACE return, and thus the close
> > operation must fail, however, the application might not even bother to
> > check the result of the close operation, and by that stage, there is no
> > way to recover etc).
> But it's more common for apps to check at least the return code from write
> calls. With the redirector passing the truncate operation to the server, it's
> possible to propagate the error condition to the app.
> If the redirector wouldn't do that, the writes, which are write back cached,
> would never be able to notice the error condition.
> On closure of the app and the timeout of the redirector (for batch oplocks
> about 5 seconds) the redirector wouldn't even be able to pass the error on
> close time!
OK, it seems that for Windows NT Servers, a Win2K redirector sends 1 byte
writes to interesting locations, like:
Write 1 byte at offset 65535
Write 1 byte at offset 2162687
Write 1 byte at offset 4259839
Write lots of data (flush the dirty data).
This seems clearly designed to allow quota and space problems to be
reflected back to the application.
Now to figure out how to make the redirector think it should do the same
Richard Sharpe, rsharpe[at]richardsharpe.com, rsharpe[at]samba.org,
More information about the samba-technical