Date: Mon, 12 Feb 2001 13:37:24 -0600 From: Russell Cattelan <cattelan@thebarn.com> To: Zhiui Zhang <zzhang@cs.binghamton.edu> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Design a journalled file system Message-ID: <3A883B74.F1CAFAFE@thebarn.com> References: <Pine.SOL.4.21.0102091214440.4738-100000@onyx>
next in thread | previous in thread | raw e-mail | index | archive | help
Zhiui Zhang wrote: > 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). Yes this is true. > > > 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. Hmm I'm not sure what the problem is here. A transaction log entry will log all changes necessary to complete that transaction, even if it involves multiple meta data objects, which is almost always does. In the event of a crash and subsequent replay of the log: the recovery code will make sure all the meta data on the disk is consistent with the log. If one meta data write happened but the another one didn't the recovery code only updates the one that didn't complete. What is the size of the disk block container on bsd buf_t's ? if they are 64bit we shouldn't have a problem... simply use absolution disk addressing for meta data items. Why would we need to copy a meta data buf_t? > > 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 > > > > > > > > -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. 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?3A883B74.F1CAFAFE>