Re: Journaling patches

[christos%zoulas.com@localhost (Christos Zoulas)]

On May 7,  2:33am, simonb%NetBSD.org@localhost (Simon Burge) wrote:
-- Subject: 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?

Yes that would do it. I would probably allocate some of the flag bits
as the version, something like:

uint8_t fs_journal_version;
uint8_t fs_journal_reserved[3];
uint32_t fs_journal_flags;
uint64_t fs_journal_location;
uint64_t fs_journal_size;

but what you have is fine too.

christos