Subject: Re: FFS journal
To: Thor Lancelot Simon <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 07/03/2006 11:35:58
Content-Type: text/plain; charset=us-ascii
On Mon, Jul 03, 2006 at 01:52:28PM -0400, Thor Lancelot Simon wrote:
> On Mon, Jul 03, 2006 at 10:16:50AM -0700, Bill Studenmund wrote:
> > >=20
> > > * One of the main sources of confusion about journaling is what exact=
> > > journal contains. In the vast majority of journaling filesystems
> > > journal only contains modifications made to filesystem metadata
> > > (i.e. changes to directories, inodes, inode and block bitmaps). The
> > > journal doesn't contain any user data stored in a file.
> > You missed the difference between logical and physical journals. You=20
> > really want to do a physical journal as recovery is MUCH simpler.
> Solaris journals logical operations, doesn't it? We asked Kirill to
> investigate using a compatible on-disk format to the Solaris implementati=
> since it is the only mature implementation of journaling for FFS for which
> source code is available.
Kirill certainly does get to choose what kind of journaling to implement.
The problem with logical journaling is that you then have to build most of=
the file system into the check tool, so that the check tool can fix up a=20
partial operation. Further, you have to keep the tool in-sync with the=20
on-disk file system. With a physical journal, you just play the journal=20
and all's done.
While source code is nice, I personally do not think that it's a
big-enough reason to choose a logical journal over a physical one. Our=20
kernel and Solaris's kernel are sufficiently different that I'm concerned=
that differences between the two will cloud issues.
To be honest, I think what's needed will be a mostly-physical journal.=20
It's a physical journal, but you have the ability to flag certain inodes=20
as being unlinked, so that fsck knows to get rid of them. Also, it's good=
to be able to flag a block as "don't write from journal". This would be=20
for a case where what was a meta data block (indirect block pointers) gets=
reallocated as file data. At that point you shouldn't write anything from=
the journal as: 1) the block is now file data, and 2) by that fact, you=20
know anything you might want to write is stale.
> Obviously, he is free to decide to journal physical blocks instead, and
> there are good reasons why he might do that. The corresponding project
> in FreeBSD is a device driver (actually, part of the GEOM layer) which
> journals physical blocks, as I understand it.
Hmm... I don't like that idea. Mainly as we then can only journal to a=20
device; you can't say journal to space in the file system.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----