On Sun, May 11, 2008 at 02:24:15PM +0200, Pavel Cahyna wrote: > 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. Put a plist on disk instead. But some form of versioning would be great! Take care, Bill
Attachment:
pgpUuZufM9eeT.pgp
Description: PGP signature