[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Journaling patches
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.
Main Index |
Thread Index |