Date: Fri, 17 Nov 1995 10:21:35 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: babkin@hq.icb.chel.su (Serge A. Babkin) Cc: terry@lambert.org, hackers@freebsd.org Subject: NFS client caching in UNIX Message-ID: <199511171721.KAA05681@phaeton.artisoft.com> In-Reply-To: <199511170535.KAA29102@hq.icb.chel.su> from "Serge A. Babkin" at Nov 17, 95 10:35:39 am
next in thread | previous in thread | raw e-mail | index | archive | help
I have split the reponses. > > Since the client won't make one INT 21 call and then make another while > > that one is pending (DOS is a non-reentrant real mode interrupt handler), > > you can't cache one and not return. You *must* return. > > How about to use a like algorithm for an Unix client ? NFS client caching for UNIX is possible to make safe in a restricted case. There are many detailed papers on this that are a better source than me on this, and which will cover the topic in greater detail. But here are some highlights: You can client cache fairly safely if the file is opened read-only. This won't work for some circumstances: mostly programs that incorrectly use files for IPC. Most of these would be older programs. You can client cache if you have advisory notification (ala madvise) to tell you what rules of access the application will follow. You can client cache (in fact, it is a major win in many ways) if the file is being opened to execute it. There is unfortunately no distinction in the kernel in the way that a file is openened in order to provide cache hints to the underlying FS. This is (IMO) a deficiency in the kernel level file I/O interface used for both file and executable image opening, and prevents cleanup of the "execute a program from an NFS server using the file as swap store" VEXEC non-propagation bug that lets you crash programs on an NFS client from either the server, or in some cases another client. The fix involves changing the internal-use-interface, providing a "hint flag" which is part of the internal-use-interface semantics, and flagging the NFS file system as "remote" (this last is the only part which is implemented). Then you still have to implement the client side cache, which will be complicated by the unified VM/cache model. You can use write-locking as a lease to cache, *if* you have working NFS locking. You *must* flush the cache when the lock goes away. I believe this is thrice flawed. An application that makes multiple changes to a single record on disk is broken in the first place is flawed... the changes should be made in core to reduce the implied state. The cache flush must be synchronous, so it's questionable whether trading a "delay now" for a "delay later" isn't itself inherently flawed. Finally, there exists implied state of a small amount of data using index locking, a typical approach to reduce real locking calls for databases in third normal form (or higher). Caching will fail to be asserted for file data which may in fact be the majority of operations. In closing, it's arguable that any application that uses database techniques should be implemented as a transaction oriented database client and server. If this is done, it's unlikely that occasions that allow for NFS client cacheing (other than file execution) will ever occur. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511171721.KAA05681>