Date: Wed, 15 Nov 1995 14:24:57 +0500 (GMT+0500) From: "Serge A. Babkin" <babkin@hq.icb.chel.su> To: terry@lambert.org (Terry Lambert) Cc: terry@lambert.org, karl@mcs.com, current@FreeBSD.ORG Subject: Re: ISP state their FreeBSD concerns Message-ID: <199511150924.OAA05961@hq.icb.chel.su> In-Reply-To: <199511150608.XAA00327@phaeton.artisoft.com> from "Terry Lambert" at Nov 14, 95 11:08:41 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Well, NFS lockd, for one. > > > > I'm sorry, I said unclear. I meant the file-based "implicit" locking methods. > > I think lockd must make synchronization anyway and it must flush the caches. > > No, no, evil, no! Even the _client_ cache (if it is present) of the file on which this lock is executed ? I think that file locking is the simplest example of [limited] transaction processing. IMHO when the file (or its part) gets unlocked everyone who tries to read from it must get the updated data, not old. And when the file (or its part) gets locked it means that the process wants to see the current state of locked data and change it without any intervention. > > > Nope. Packet-burst. Effectively, async writes for 32 or 64k. Fixed > > > window, needs an ack every burst run. > > > > OK, why it is good for Netware and bad for NFS ? > > Because the async is on the client; if it fails, it can retry. The average > system call overhead in SVR4 is 20uS. The average packet turnaround on > a NetWare server is on the order of 60uS. Obvious UNIX will have a hell > of a time turning a packet around as fast as a NetWare server. > > The loss for NFS is that the async writes are not performed by the client. As I can understand they are even explicitly prohibited (your original "1)" paragraph). But why ? Is there some principial problem or just nobody had implemented async NFS client (or simply I never saw it) yet ? > If the client did a "window" worth of async writes an did an fsync() before > letting go, then it would work. How about this algorithm : client_nfs_fsync(): If the file is marked as "write failed" return ERROR; Make a local simple lock of file to prevent write()s during fsync(); Wait until all outstanding write() requests are completed; Unlock the file; Return OK; client_nfs_lock/unlock(): If the file is marked as "write failed" return ERROR; Make a local simple lock of file to prevent write()s during fsync(); Wait until all outstanding write() requests are completed; Issue an NFS lock/unlock request and wait until it completes; Unlock the file; Return OK; client_nfs_close(): If the file is marked as "write failed" Do anything needed to close the file; Return ERROR; Make a local simple lock of file to prevent write()s during fsync(); Wait until all outstanding write() requests are completed; Do anything needed to close the file; Unlock the file; Return OK; client_nfs_write(): If the file is marked as "write failed" return ERROR; If the file is locally locked for synch. purposes wait until it gets unlocked; If there is no free block in write pool or this file has too many outstanding write requests wait until there will be free block and the number of outstanding requests will be less than "many"; Write user data into this block; Issue an NFS write request; Start timer on this block; Return OK; acknowledgement_on_written_block_arrived(): Disable timer for this block; Return this block into the free blocks pool; timeout_on_block(): If too many retries Mark file as "write failed"; Disable timers of all outstanding write requests for this file and free their blocks; return; Else Issue an NFS write request; Restart timer on this block; Increase number of retries; Of course it is simple and obvious, but what can you, Unix Wizards, say about it ? Is it wrong ? > Basically, it fails because the client is stupid and NFS is not a connection > oriented protocol. Client can be made clever :-) and the connectionless nature of NFS prtocol should not disallow this buffering. > > > > > BSDI NFS - about 300K/s > > > > FreeBSD NFS - about 12K/s > > > > > > One wonders what BSDI does... maybe implements pcnfsd in kernel code? > > > > Nope, I have experimented with pcnfsd from BSDI compiled in FreeBSD. I know > > no details of PCNFS protocol, but if every request neeeds additional request > > to pcnfsd it's IMHO strange. BTW, I have experimented without pcnfsd at all, > > with -n key of mountd and results were the same. > > How else are you going to support findfirst/findnext and short name > semantics?!? I have experimented with short-named files :-) Really it is not a big problem if you will put only files with dos-formatted names in the PCNFS-mounted directories. I don't know about findfirst/findnext problem, Tsofts's PCNFS with which I experimented worked well with "auth=none" option. > > > Change the PCNFS server, and if possible, the PCNFS client. > > > > I know that different PCNFS clients make difference in performance but I > > never throught that pcnfsd may change the performance. Its manual page > > says that it is used for logging in and out only. > > Look at the source. The manual page lies. I have looked at pcnfsd.x and most of request types I saw are printer-related, only two of them are PCNFSD[2]_AUTH that checks user name and password and returns uid, gid and other related information and PCNFSD2_MAPID that performs translations between names and IDs. I see no need to send these requests every time we do some NFS operation. Serge Babkin ! (babkin@hq.icb.chel.su) ! Headquarter of Joint Stock Commercial Bank "Chelindbank" ! Chelyabinsk, Russia
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511150924.OAA05961>