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--