Date: Fri, 9 Feb 2001 12:24:54 -0500 (EST) From: Zhiui Zhang <zzhang@cs.binghamton.edu> To: Russell Cattelan <cattelan@thebarn.com> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Design a journalled file system Message-ID: <Pine.SOL.4.21.0102091214440.4738-100000@onyx> In-Reply-To: <3A83986E.55789E59@thebarn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I guess that this will involve either memory copying or changing the buffer header directly. Linux seems to address buffer directly via physical (not logical) block number, so there is no need to change the buffer header. Plus, Linux have a reference count to prevent a buffer from disappearing (brelse()'ed). Another difficulty is that if several transactions are in progress at the same time, we must remember which metadata buffers are modified by which transactions. When we copy/rename the buffer, we must inform those transactions the fact that we did the copy/rename. The buffers modified by one transaction must be flushed at the same time. BTW, Linux GFS code seems to allow ONE transaction in progess at any time. -Zhihui On Fri, 9 Feb 2001, Russell Cattelan wrote: > Zhiui Zhang wrote: > > > 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. > > XFS: > All pinned buffers are keep on a queue to be flushed by a > daemon that walks the queue looking for buffer that > have recently become unlocked and unpinned. > > > > > > > > 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 > > Yup. All meta data buffer use and absolute device offset. > > > > 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 > > -- > Russell Cattelan > cattelan@thebarn.com > > > > 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.SOL.4.21.0102091214440.4738-100000>