read caching across close

Peter Waechtler peter at helios.de
Fri Apr 30 07:27:00 GMT 2004


Am Donnerstag, 29. April 2004 19:04 schrieb Steve French:
> On Thu, 2004-04-29 at 11:38, Richard Sharpe wrote:
> > On Thu, 29 Apr 2004, Peter Waechtler wrote:
> > > Am Mittwoch, 28. April 2004 23:03 schrieb Steve French:
> > > > unless I start doing lazy close of oplocked files (which is an
> > > > option),
> > > >
> > > > Although the cifs vfs gets good cache across close performance in the
> > > > common case of:
> > > >
> > > > 1) open file, get oplock
> > > > 2) read 1st page
> > > > 5) close
> > > > 6) reopen file, get oplock
> > > > 7) read 1st page out of client's cache
> > >
> > > You give up the oplock when you send a close over the wire.
> > > IMHO you have to purge the page and read it in again and don't rely
> > > on the timestamp.
> > > With a  BATCH oplock you wouldn't sent the close over the wire.
> > > Instead you start a timer and close the file when a program does
> > > not open the file again.
> > > If you close the file - you give up the oplock.
> >
> > Yes, I have to agree with that. There is an opportunity for someone to
> > get at the file between your close and re-open, and given that they could
> > set the times to what they were before they messed with the file, you
> > lose.
> >

> I agree that for strictest semantics (and to reduce the risk of an app
> changing the contents but resetting the time) that the long oplock
> approach (either one) is safest but this needs to be tested in practice
> for practicality.   There are resource considerations on the server with
> holding an oplock (either traditional or batch) until the client sends
> the delayed close.  The close (releasing the oplock on the server, and
> the server resources associated with it) will be sent eventually when
>
> 1) the client kernel tells the cifs client to free the inode
> 2) when the filesystem is unmounted (a general case of freeing all
> inodes on the mount)
> 3) when an oplock break is sent from the server

You do not _have_ to close the file. You can first lock a range, issue 
writes and reads and then ack the server the oplock break.
Oplock Level2 breaks don't have to be confirmed by client.

> 4) before the routine inode (or dentry) revalidate check, the client
> could based on timer close files that have not been reopened in some
> time window (perhaps 10 minutes seems reasonable - but it could be
> configured).  This does not require a distinct thread since it
> dentry_revalidate or inode revalidate are called often enough to be
> useful for this purpose
>

Ten minutes is _very_ long. Windows has something in the range
of 10 seconds. It was invented because "they" didn't fix the
command interpreter. This crap of software opened the bat file, read
the next line, close and so on.
Nowadays one uses the explorer, and this opens files depending on their
extension, e.g. to read the icon, if the mouse moves over it's 
icon/filename. The redirector caches some of it - but then there are 
other oddities.



More information about the samba-technical mailing list