Subject: Re: FFS journal
To: Pavel Cahyna <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 07/05/2006 13:36:16
Content-Type: text/plain; charset=us-ascii
On Tue, Jul 04, 2006 at 11:48:33PM +0200, Pavel Cahyna wrote:
> On Tue, Jul 04, 2006 at 03:32:36PM -0400, der Mouse wrote:
> > For FFS, I think this would work: the inode is cleared, but the inode
> > is locked in core anyway while the file is open - and the data and
> > indirect blocks will be marked free but, as you say, their contents
> > will be undisturbed.
> > I don't know other filesystems enough to speak to them.
> > However, even for FFS, it will break if you switch from RW to RO and
> > then back to RW.
> If we ever want to support this properly, the kernel should remember
> that a cleared inode is still used, and when doing the switch back to RW
> undelete the inode using the cached data.
Such a thing will be very messy to support. I think it's far better to=20
somehow keep a scratch area recording "unlinked but inuse inodes".
Among other things, say the unlinked file is large enough that we can't=20
cache all its block metadata in-core. Then there's no way to "undelete" it=
as we can't remember where all the blocks are. Remember a 4 TB ufs2 file=20
has around 1 GB of block pointer data.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----