From owner-freebsd-fs Thu Feb 8 23:13:11 2001 Delivered-To: freebsd-fs@freebsd.org Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by hub.freebsd.org (Postfix) with ESMTP id 1C66637B401 for ; Thu, 8 Feb 2001 23:12:53 -0800 (PST) Received: from thebarn.com (nic-31-c12-219.mn.mediaone.net [24.31.12.219]) by lips.borg.umn.edu (8.11.2/8.10.1) with ESMTP id f197Cpb30997; Fri, 9 Feb 2001 01:12:51 -0600 (CST) Message-ID: <3A83986E.55789E59@thebarn.com> Date: Fri, 09 Feb 2001 01:12:46 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Zhiui Zhang Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Design a journalled file system References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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