Date: Sat, 18 Nov 1995 14:12:33 -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: Re: NFS vs. NetWare for DOS file services Message-ID: <199511182112.OAA09562@phaeton.artisoft.com> In-Reply-To: <199511181046.PAA01710@hq.icb.chel.su> from "Serge A. Babkin" at Nov 18, 95 03:46:11 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I have tried FoxPro 2.0 both on Netware and NFS (I have learned in the > university where it was runned on Netware and I did laboratory works at > my work where I had NFS installed) and it worked on both. So it looks like > it uses DOS lock calls that are then implemented through Netware or NFS. > I don't know about other calls. It looks like DOS (and Netware too) has > no fsync call or anything like, the full sync call appeared in DOS 6+ olny. More likely, the code will use a NetWare API if it finds one, and is doing regualr DOS I/O and doesn't know it's on a network in the NFS case. [ ... 70% of NetWare requests are reads ... ] > BTW, which percent of them are reads of .exes ? If it is small all these > tricks with 9K will give small effect. Many of them. But that's not the point. The point is that most reads are done on fd's open for read and not write, so you can safely cache because you have additional information that you don't have otherwise. > > 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. > > Is it because the typical size of .exe relocation table is 9K ? IMHO this > can be implemented (may be less effective but enough simple) by reserving > 9K cache where to put the data readed from the first 9K of any file. > When reading from the first 9K of any file we can lookup first in this > buffer. No. It's because of the stupid way that most DOS executables load, and that's because of the stupid way the DOS loader sets up the PSP by rereading crap instead of setting it all up at once. > > 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. > > Do other reads trigger read-ahead ? I think that if the common cache is > different from the "9K cache" read-aheads will not pain because they will > not disturb the "9K cache". I mean trigger read-ahead by a UFS file system. And it *should* trigger read-ahead. That's why you need an fadvise. > > 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). > > I'm sorry... Explain me please shortly what is this semantics. POSIX requires certain data to be updated at certain times so it can make data state guarantees to the clients of the POSIX API. Many of these state guarantees result in "useless" synchronous I/O in UFS. This is "useless" from the perspective of our "intended use": serving files to a DOS box. [ ... ] > > 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. > > I have read the RFC on NFSv2 and there was said that it has the ability to > read multiple directory entries at once. Was it just not implemented > in servers ? The major issue is the stat data. But v2 implementations typically do not provide a multiple entry interface. [ ... ] > > Note that this type of crap won't fly with NFS, which pretends to provide > > POSIX semantics to its clients. > > Getdents() reads multiple directory entries at once, why we can't say that > reading multiple directory entries through NFS at once is like getdents() ? You can. It's the large amount of sync I/O you can't avoid, as long as you are making update guarantees consistent with POSIX. > > 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. > > I have throught that the main reason why Netware loads all metadata in core is > that its access rights are very "heavy". Nope. Not all of the blocks containing the trustee information are in core. A typically installation won't use a lot of trustee data anyway. > > No. "SHARE" provides file granularity access locking semantics. Which > > means multiple reader OR single writer guarantees are made, even under > > NetBIOS. > > I'm not shure what SHARE does, I have throught that it simply implements DOS > FLOCK call on Microsoft networks. Does not it ? There are two locking modes: "regular", used by aware applications, and "compatability" used by dumb applications. The SHARE implements compatability mode requests do that dumb applications can run (I just looked for my state table for the thing and I can't find it; it must be on my other machine, and I'm running WinBench against it, so I'm not going to do anything about it right now). [ ... ] > In my opinion what you describe are "very Netware-aware" applications > but most applications work on Lantastic, NFS etc. too. I think that > dBASE-like systems must not be so network vendor dependent. An app like that is only "NetBIOS" aware, which may be enough to cause it to do async requests, etc.. The use of the Novell TTS API's is understandably far from portable. Applications that are "network apps" will typically modify the way they access things to get better performance (having been tested in that type of environment) and use thing like the exended INT 21 interfaces introduced with DOS 3.1 in place of the older interfaces -- they don't mix them. dBase-like systems will make locks on records, not using the index file as a full on lock. They also typically *expect* to be screwed with a server error, and thus come with some recover tool. The people who use them expect to have to run the tool occasionally. Not to drag Jordan into this (8-)), but it's like buying a car with known electrical problems, and then replacing the alternator coil each time it goes bad because they won't sell you a working regulator. This is not the type of application you should code for -- doing so perpertuates the assumptions that allow the application to work, and encourages more bad applications that feel free to make the same assumptions. Regards, 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?199511182112.OAA09562>