[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Journaling patches
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:
but what you have is fine too.
Main Index |
Thread Index |