Subject: Re: FFS journal
To: Pavel Cahyna <pavel@netbsd.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 07/05/2006 13:36:16
--TybLhxa8M7aNoW+V
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
> >=20
> > 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.
> >=20
> > I don't know other filesystems enough to speak to them.
> >=20
> > However, even for FFS, it will break if you switch from RW to RO and
> > then back to RW.
>=20
> 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=
=20
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.

Take care,

Bill

--TybLhxa8M7aNoW+V
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFErCLAWz+3JHUci9cRAnFpAJ9n6nAkQOwDb2W0vXW7oDflxG45dgCeJaxg
8cYjafXFutC0soyCsmyiZFg=
=I3aE
-----END PGP SIGNATURE-----

--TybLhxa8M7aNoW+V--