Date: Sat, 14 Mar 1998 09:40:12 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Tor Egge <Tor.Egge@idi.ntnu.no> Cc: freebsd-current@FreeBSD.ORG Subject: Re: 4 WILLRELE's to bite the dust Message-ID: <Pine.SV4.3.95.980314092702.20867B-100000@parkplace.cet.co.jp> In-Reply-To: <199803131845.TAA26656@pat.idi.ntnu.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Tor, Excellent! I'm not fixing bugs at this stage, but after all the rele's and locks have moved to the right place it should be easier to solve some of the problems you've listed. I'm being conservative because of the volume of code I need to go through, but maybe we can coordinate on fixing some of the easier problems as I do these changes. Regards, Mike Hancock On Fri, 13 Mar 1998, Tor Egge wrote: > > I did some simple testing of nullfs and union. It's seems Kato-san has > > gotten them pretty stable. What kind of things cause problems with null > > and union? > > - coherence. When the different layers operates on separate > vm objects, the vm objects might get out of sync. > E.g. page fault algorithms checks the size of the upper > vm object, and gets the wrong value, since a VOP_WRITE > only extended the size of the lower vm object. > > Symptom: install -C during make world gets a SIBGUS > if /usr/obj is nullfs mounted. > > - freeing of resources. When the file is unlinked, the > lower vnode still has a reference from the upper vnode > which is left until the upper vnode is recycled. Currently > null_inactive calls VOP_INACTIVE on the lower vnode. > This is wrong (e.g. a process directly accessing the lower > vnode will see a truncated file, which is an unintended > side effect). > > Symptom: Removing a file that has been opend via nullfs > will not necessarily free the space on the file system > before the null vnode is recycled. > > - locking. > > - Missing vnode locking during vnode recycling, > i.e. does not wait for inactive to complete. > Symptom: lock manager panic when trying > to release the lock in vclean. > > - During object recycling, the VOP_ISLOCKED method > can cause a trap 12. This problem might not > occur anymore, since vfs_msync now checks for > the VXLOCK vnode flag. > > - Use of VOP_ISLOCKED() is very often a kludge, since > it is assumed that the current process is the owner > of an exclusive lock on the vnode, while it might > be a different process or a shared lock. > > - vnode leakage in null_node_alloc. > > - During vnode recycling, fsync is called several times on > the lower vnode. This only affects performance. > > - Access to files on a nullfs file system gives spurious > EDEADLK errors, due to a bogus deadlock detection in > nullfs_root. That deadlock detection is not needed > if the generic mount system call is slightly changed. > (most local file systems has the same kind of deadlock > problem, thus a generic solution is preferrable). > > > I've been using nullfs since Nov 7 1997 without any serious problems > after having fixed some of the above mentioned problems in my local > source tree. The code is not perfect, panics are still possible due > to heuristics (due to VOP_ISLOCKED()) being wrong, but I've yet > not experienced any problems. > > Using the nullfs in -current without any fixes, a make world would > very likely not succeed if /usr/obj is nullfs mounted. > > By modifying null_mount, I've played around with hierarchical mounts: > > ikke# find /usr/zzz -print > /usr/zzz > /usr/zzz/zzz4 > /usr/zzz/zzz4/test4 > ikke# mount -t null /usr/zzz /usr/zzz > null: Resource deadlock avoided > ikke# mount -t null /usr/zzz /usr/zzz/zzz4 > ikke# find /usr/zzz -print > /usr/zzz > /usr/zzz/zzz4 > /usr/zzz/zzz4/zzz4 > /usr/zzz/zzz4/zzz4/test4 > ikke# umount /usr/zzz/zzz4 > ikke# mount -t null /usr/zzz/zzz4 /usr/zzz > ikke# find /usr/zzz -print > /usr/zzz > /usr/zzz/test4 > ikke# umount /usr/zzz > ikke# mount -t null /usr/zzz /usr/yyy > ikke# mount -t null /usr/zzz /usr/yyy > null: Resource deadlock avoided > ikke# mount -t null /usr/yyy /usr/zzz > null: Resource deadlock avoided > ikke# mount -t null /usr/yyy /usr/yyy > null: Resource deadlock avoided > ikke# mount -t null /usr/zzz /usr/yyy > null: Resource deadlock avoided > ikke# mount -t null /usr/zzz /usr/zzz > null: Resource deadlock avoided > ikke# umount /usr/yyy > > I saw the need for a general change in the mount system call when I issued > > mount /usr/zzz /usr/zzz > > instead of > > mount -t null /usr/zzz /usr/zzz > > when testing the nullfs deadlock handling, and got a panic, due to bugs in the > the ufs mount code. > > With a changed mount system call, I get > > ikke# mount /usr/zzz /usr/zzz > /usr/zzz on /usr/zzz: Block device required > ikke# mount -t null /usr/zzz /usr/zzz > null: Device busy > ikke# mount -t msdos /usr/zzz /usr/zzz > msdos: /usr/zzz: Block device required > ikke# mount -t cd9660 /usr/zzz /usr/zzz > cd9660: Block device required > ikke# ls -ld /usr/zzz > drwxr-xr-x 3 root wheel 512 Feb 10 02:02 /usr/zzz > > > - Tor Egge > -- michaelh@cet.co.jp http://www.cet.co.jp CET Inc., Daiichi Kasuya BLDG 8F, 2-5-12 Higashi Shinbashi, Minato-ku, Tokyo 105 Japan Tel: +81-3-3437-1761 Fax: +81-3-3437-1766 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?Pine.SV4.3.95.980314092702.20867B-100000>