Date: Fri, 9 Aug 2002 02:48:54 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Rashim Gupta <guptar@cs.rpi.edu> Cc: Terry Lambert <tlambert2@mindspring.com>, "David E. Cross" <crossd@cs.rpi.edu>, fs@freebsd.org Subject: Re: vnodes (UFS journaling)? Message-ID: <Pine.NEB.3.96L.1020809024315.23441I-100000@fledge.watson.org> In-Reply-To: <Pine.GSO.4.31.0208072033520.24055-100000@dishwasher.cs.rpi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 7 Aug 2002, Rashim Gupta wrote: > we are trying to implement a logging facility for the File System. Hence > we need to open the log file and keep its vnode open throughout the > duration while the system is mounted. Hence, we cannot free the vnode > after searching for it using the root file system since we need to > access it later on. However, if we do not return the vnode, then doing > an "ls -al" in the dirctory where the log file is present hangs the > kernel. Sounds like you are holding onto the vnode lock rather than releasing it, which causes processes to hang trying to acquire the lock. BTW, one disadvantage to using the "write to a vnode for logging" approach at this level is that it opens you up to potential lock order problems that can result in deadlocks. There are some obscure deadlock situations as a result of similar approaches taken in the quota and UFS1 extended attribute code. These generally occur when you attempt to lock a vnode while holding other vnode locks, and there's no defined lock order relationship between the two vnodes (generally, lock orders in VFS are derived from the hierarchal namespace). Depending on when you write to the journal, you might be able to avoid this, especially if you can avoid writing to the journal while holding regular file locks (only directory locks). You might also want to look at the WAFS (write-ahead file system) code posted to this list about a year ago by researchers at Harvard who used WAFS to hold journal data. WAFS is, from an off-handed recollection, a cyclic record file system designed for rapid append of ordered records. You can find a brief discussion of the file system in the paper by Seltzer, McKusick, et al, in the USENIX ATC 2000 proceedings, I believe. When I looked at the code, it clearly had experimental aspects (for example, my recollection is that access control for the log isn't implemented), but it might be a useful thing to look at. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020809024315.23441I-100000>