Re: Journaling patches

[Pavel Cahyna <pavel%netbsd.org@localhost>]

On Wed, May 07, 2008 at 02:33:02AM +1000, Simon Burge wrote:
> [ Oops, let this one slip through ]
> 
> Christos Zoulas wrote:
> 
> > My only concern about applying the patch to current is that the on-disk
> > layout of the log might change and people will need to have a way to upgrade
> > their log format. For that we need to make sure that all versions of WAPBL
> > filesystems are clearly recognizable.
> 
> Do you mean the on-disk layout in terms of the contents of the journal,
> or the location of the journal?
> 
> If the former, I believe that we're just journaling physical block
> changes, so the format there won't change.  To be honest, I don't know
> any more about the contents of the journal itself.
> 
> For the latter, currently the journal is at the end of the filesystem's
> partition.  Some other (as yet unimplemented!) options are internal to
> the filesystem (as I believe Solaris does it), battery backed RAM, and
> to an external partition/device.
> 
> Currently, we just use a bit in the fs_flags member of the ffs
> superblock.  One suggestion is to use a few of the reserved parts of
> the superblock (eg fs_sparecon64) to keep track of journal location
> information.  Maybe have:
> 
>       int64_t fs_journalflags;
>       int64_t fs_journalloc0;
>       int64_t fs_journalloc1;

Could you please use this opportunity to implement an ext2fs-like
versioning scheme for FFS features? Briefly, there should be three bitmaps
of flags: one for fully compatible new features (code that does not
understand them can fully use the filesystem), read-only compatible
features (code that does not understand them must use the filesystem
read-only, otherwise it might damage it) and incompatible features (code
that does not understand them can't use the filesystem at all).

See the section "Feature Compatibility" in Documentation/ext2.txt in Linux
kernel sources for more information.

Pavel