Date: Fri, 9 Feb 2001 20:23:36 +0100 From: "Karsten W. Rohrbach" <karsten@rohrbach.de> To: Zhiui Zhang <zzhang@cs.binghamton.edu> Cc: freebsd-fs@freebsd.org Subject: Re: Design a journalled file system Message-ID: <20010209202336.D48420@rohrbach.de> In-Reply-To: <Pine.SOL.4.21.0102061544230.6584-100000@opal>; from zzhang@cs.binghamton.edu on Tue, Feb 06, 2001 at 04:15:45PM -0500 References: <Pine.SOL.4.21.0102061544230.6584-100000@opal>
next in thread | previous in thread | raw e-mail | index | archive | help
there was a post last year to either -fs or -hackers that described the use of a single disk or block device for logging all writes and committing them afterwards. i think it was presented at usenic last year or 99. can't find it now - please check the mailing list archives. /k Zhiui Zhang(zzhang@cs.binghamton.edu)@Tue, Feb 06, 2001 at 04:15:45PM -0500: > > I am considering the design of a journalled file system in FreeBSD. I > think each transaction corresponds to a file system update operation and > will therefore consists of a list of modified buffers. The important > thing is that these buffers should not be written to disk until they have > been logged into the log area. To do so, we need to pin these buffers in > memory for a while. The concept should be simple, but I run into a problem > which I have no idea how to solve it: > > If you access a lot of files quickly, some vnodes will be reused. These > vnodes can contain buffers that are still pinned in the memory because of > the write-ahead logging constraints. After a vnode is gone, we have > no way to recover its buffers. Note that whenever we need a new vnode, we > are in the process of creating a new file. At this point, we can not flush > the buffers to the log area. The result is a deadlock. > > I could make copies of the buffers that are still pinned, but that incurs > memory copy and need buffer headers, which is also a rare resource. > > The design is similar to ext3fs of linux (they do not seem to have a vnode > layer and they use device + physical block number instead of vnode + > logical block number to index buffers, which, I guess, means that buffers > can exist after the inode is gone). I know Mckusick has a paper on > journalling FFS, but I just want to know if this design can work or not. > > Any ideas? Thanks for your help! > > -Zhihui > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message -- > Booze is the answer. I don't remember the question. KR433/KR11-RIPE -- http://www.webmonster.de -- ftp://ftp.webmonster.de 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?20010209202336.D48420>