tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Journaling patches

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

64-bit seems a bit wasteful for just some flags, but I think its better
to keep them with the location data rather than using a 32-bit spare in
a different part of the superblock.  fs_journalloc0 and fs_journalloc1
can then be location-type specific - they might be the special inode of
an internal FS journal, the start and end addresses of battery backed
RAM, a dev_t or similar locator.

Would something like this satisfy your concerns?


Home | Main Index | Thread Index | Old Index