Date: Wed, 23 Sep 1998 03:05:10 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: luoqi@watermarkgroup.com (Luoqi Chen) Cc: Don.Lewis@tsc.tdk.com, current@FreeBSD.ORG, luoqi@watermarkgroup.com Subject: Re: Yet another patch to try for softupdates panic Message-ID: <199809230305.UAA17230@usr06.primenet.com> In-Reply-To: <199809212327.TAA23891@lor.watermarkgroup.com> from "Luoqi Chen" at Sep 21, 98 07:27:23 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> The unlock is not bogus at all. You have to maintain a strict locking order > to avoid deadlocks. For vnodes, this locking order is the directory tree > itself, i.e., you have to lock the parent first, then the child. So if you > hold the lock on the child and intend to lock the parent, you have to > release the lock on child first, then acquire the lock on the parent, and > then reacquire lock the the child. That's also the reason why you can't have > hardlinks to a directory. Actually, I believe the hard linked directory capability was removed in FreeBSD because it facilitates parent traversal to root, and because POSIX permits this removal by intentionally avoiding the definition of a directory to be "a type of file". I think that it also avaids a number of painful circumstances, like directory loops. I believe soft updates specified this behaviour because of the referential integrity problem for the traversal of the ".." entry to obtain the parent directory vnode. For the way hard links are implemented (i.e., not using an on disk "alias node"), the parentage of any filesystem object that is either not a directory, or is a hard-linked directory, is suspect. If you were to change the physical manifestation of hard links, causing them to take up another 256 bytes for the first link and 128 bytes per hard link threafter, using a new inode file type to do this (the first one causes the generation of an alias object in both the source and target directories), you could reenable hard links of directories. This change would require an inode allocation per link instance, and one for the real file, and the addition of a pass to fsck to take these secondary inodes into account as being virtually referenced by a directory. You could also store a "parent" pointer for each object, which would mean that you could always get the absolute location in the FS of any file, no matter how it was open'ed, and therefore the file's name (since the vnode structure would point to an in core copy of the alias node from on disk, which would them point to the in-core copy of the linked file. Yet another application for FS_getbackingvp(), to avoid VM object aliases... 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?199809230305.UAA17230>