Date: Wed, 22 Apr 1998 19:12:33 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: tlambert@primenet.com, ken@plutotech.com, syssgm@dtir.qld.gov.au, freebsd-current@FreeBSD.ORG Subject: Re: NFS corruption Message-ID: <199804221912.MAA29389@usr08.primenet.com> In-Reply-To: <29627.893227732@time.cdrom.com> from "Jordan K. Hubbard" at Apr 21, 98 11:48:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Please integrate my write lease notifications, which I did for free, > > without it being my paying job, and see if it fixes the problem. > > While I appreciate the pointer, I also have to say that the chances of > this fixing _all_ the serious problems with NFS are pretty remote, > don't you agree? The original point stands, I think. Yes, I don't expect this to fix all of the problems. For server locking, you will need my changes to the kernel advisory locking manager and fcntl(), as well. For client locking, you will need my changes to make the VOP_ADVLOCK veto-based, which incidently adds locking support to all newly developed filesystems from now on, without adding FS specific code. The client locking also needs the changes to the advisory locking manager to seperate "assert" from "commit" incase a remote NFS server says "no, you can't have the lock". It also moves the lock list from being hung off the in-core inode to being hung off the in-core vnode. This should resolve locking issues currently outstanding with the nullfs and unionfs as well. For the directory search problems, you will need to take my code that seperates the retrieval of an FS specific directory entry block and the iteration of elements within that block into seperate VOP's. This gets rid of cookies, which I'm sure everyone will miss, what with their unexpectedly playful returning of duplicate file names, and other hijinx they tend to get up to. It also incidently allows search restarts to be more reliable for other clients that iterate a file at a time. Like SAMBA and AFS. Some people may argue that my approach is not correct; but where is the alternative code? "Anything that works is better than anything that doesn't" -- Edison All that aside, yes, NFS needs a top-down architecture reassessment in line with the standards documents in general and the Sun NFS implementations in particular. In order to support that, it's probably necessary that the VFS interface be reflexive, so that we can ignore the issues that aren't related to NFS. So yes, I need to dust off my nameifree() patches for that. There probably needs to be some consensus brought to Michael Hancock's patches, as well. They seem good, and they seem in line with simplifying what an NFS maintainer (or any other person doing FS developement) needs to have to be able to hold in their head at one time to get useful work done. --- So I will dust of my nameifree() patches (for which I will need people with NFS to test that I haven't introduced a path name buffer leak, since that code is convoluted as hell, with macro-hidden goto/label definitions), and I suggest that Michael Hancock's patches for VFS the relevent interfaces be committed. I also suggest that what patches there are be committed; no they aren't a full soloution, but long journies begin with but a single step. If those that are mine need dusting, well, I'll do dusting, I guess. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804221912.MAA29389>