Date: Fri, 17 Nov 1995 10:00:02 -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 vs. NetWare for DOS file services Message-ID: <199511171700.KAA05647@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've split the responses. > It really looks like a problem. For DOS client the solution may be to > flush the whole cache before issuing an unlock request. But I think > any network-aware DOS program must use fsync. Here's the rub: most "network-aware DOS programs" don't use NetBIOS. They use a proprietary API. 70% of all DOS network nodes overall are NetWare. The majority of small business networks (100 employees or less) are Lantastic. For a proprietary API, you can define caching-friendly interface semantics; this is exactly what has been done for those systems that cache. > > Write cache going to disk relies on the fact that some writes are async, > > and may be cached, and some writes are sync, and must complete before > > they return, leaving the data on the disk. > > > > DOS doesn't have the distinction between async and sync writes, so you > > can't just say "I'll just cache async writes" -- because there aren't > > any. > > The programs using Netware must know about this difference. Most programs > that really do record locking are working on Netware, not on a local machine > (why else you need record locking on a single-tasking OS?) and differ > async and sync writes. OK. I worked on the file system for the NetWare for UNIX 4.x product for nearly two years using the Native NetWare 4.x source code as a base, so I know a "little bit" about this. NetWare clients do client caching. They use the low 24 bits of the file handle as a hash index (which incidently screwed me treating the short file handled as an opaque 32 bit value like you are supposed to be able to). This cache is used mostly when reading .exe and other files which are opened read-only or which are read-only for the client, as determined by querying the file attributes. This may not seem like a big win, but 70% of all requests to a NetWare Server are read requests. There is a big win on .exe loading to caching. Specifically, the way DOS loads executables causes it to refer to the first 9k several times in the load process. A DOS client loading a .exe will not trigger read-ahead, because the first 9k is rereferenced when the file is otherwise sequential I/O. Windows is a bit different here because it pages, but client caching has a big effect (obviously) on paging. The biggest win a UNIX box acting as a server for DOS clients can implement is file name and open mode specific madvise() operations. After reads, the next most frequent operation is writes, which are about 18% of operations. Typically, writes are not sequential. There is little you can do to improve write performance, other than to remove the synchronous requirements. These requirements are removed by: 1) Removing POSIX semantics on the file system (dangerous). 2) Changing the mechanism which guarantees the POSIX semantics to use a better scheme than synchronous writes to provide the ordering guarantees (ala the UnixWare 2.x UFS, and the U of Michigan EECS "Soft Update" Metadata update mechanism). The first isn't a real option; it's bogus. The second reduces drastically the absolute overhead that you have to eat to maintain the NFS protocol guarantees consistently. Of the remaining 12%, 8% are directory operations, and 4% are all other operations. Directory operations accont for a disproportionate amount of the time for the client waiting for a server response. The biggest win, which only recently went into NetWare and NFSv3, is the ability to return multple entries at the same time. The POSIX guarantees once again get in the way of performance. For directories, however it is possible to cheat. POSIX guarantees file times update semantics. In addition, it guarantees directory time update semantics when getdents() is called. BUT... POSIX does not require that you consider a directory to be a file: it can't, since VMS can be POSIX compliant (point of interest: many of the idiotic semantics with regard to "shall be updated", "shall be marked for update", and "may be marked for update" that POSIX requires seem to be related to vendor "special interests" in defining POSIX so they don't have to recode existing systems). So does POSIX require that you use getdents() to access directory contents? It does not. So you can cheat by "defining" a directory to be other than a file, and then using an interface other than getdents() to get at it. Or you can say "to hell with the dancing" and give yourself a blanket license to relax POSIX guarantees, as long as you don't do anything that compromises file system integrity. Note that this type of crap won't fly with NFS, which pretends to provide POSIX semantics to its clients. So NetWare achieves its speed by not being POSIX and by using interfaces other than the NetBIOS interface to implement its own cache-friendly semantics. Oh yeah. And by having the entire volume directory structure, including file metadata, in core at all times and accessed via hashlist. And you wondered why mounting took a long time. > > DOS client applications assume O_SYNC on all opens. > > Pure DOS (without any network) assume exclusive access to anything and do > not use any locks at all. No. "SHARE" provides file granularity access locking semantics. Which means multiple reader OR single writer guarantees are made, even under NetBIOS. > > You'd do better to define your own API and make it conform to POSIX > > semantics (basically, a libc replacement) and write the DOS client > > programs that way. > > The problem is that we need to run the ready applications, not only the > self-written ones. BTW I think Novell did exactly this with its Netware > and now all network-aware clients use such API implemented with DOS calls. Novell provides a non-NetBIOS redirector for INT 21 and INT 13 (to an extent) calls, as well as hooking several other intterupts. These requests are then funneled into NetWare specific requests optimized for the way DOS makes requests and some common DOS software operates. There are over half a thousand "system calls" for an application that uses a NetWare server, though most applications only use a fraction. That (and packet signatures and ticketing and NDS using licensed RSA technology) is the reason I react with such incredulity anytime someone suggests providing NetWare services as a Freeware effort. Because the NetWare client makes its own way, and decides up front based on file open modes (and other information Novell has invested many years figuring out) what behaviours map to what server interfaces for what version of DOS/Windows, it can make optimizations that you simply can *NOT* make when pounding the API-restricted NetBIOS interface into the even-more-restricted NFS POSIX interface. The leeway you have in implementation is the room between a NetBIOS and self-hooking INT 21, INT 13, etc.. Small room. > > > Yes, this alogrithm implies a client-side "write only" cache and no > > > server-side write cache, the server remains as it is now. In your > > > analogy server is here a "disk". > > > > What about Solaris, SGI, and SVR4 servers, which do server caching? > > You said that this solution is unreliable and it will not be yet more > unreliable due to the client-side write caching. It compounds the unreliability. Both are multiplicative. It *will* be more unreliable. > > DOS libc fsync() does nothing. Or applications don't call fsync(). > > Very differnt form assembly programs calling the INT 21 op. > > How do they work on the Netware network ? If they want to work on it they > need to use fsync() too. And I think most dBASE-like databases do these > calls. If they do not use these calls they would not work on Netware too. They use the NetWare TTS API and convert the database file I/O into transactions that can be backed out. The start-transaction/end-transaction pairs indicate to the server the implied state in the client application that accesses multiple files. If I crash and come back up, for every "start-transaction" without an "end-transaction", the server can decide to throw away the changes that that transaction wanted to make by identifying them by transaction ID. So it works by the "NetWare aware" application using NetWare API's instead of the standard DOS APIs (and the NFS client typically only hooks the DOS API's). 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?199511171700.KAA05647>