Handling quota and out of space issues while holding an OpLock

[Peter Waechtler]

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!

I was told that even for sparse files, the space for the requested file size 
is checked - on Unix this isn't done - at least I don't know about that.
So on windows you can be quite sure that you can write into "the gaps" without 
getting an error.
And with regards to quota: when does a unix system checks the quota limit?
On Inode and block allocation time? Am I able to create a sparse file that is 
beyond the limit - only getting an error on block allocation? I think so.