DragonFly kernel List (threaded) for 2008-05
Re: HEADS UP - Another media change for HAMMER
:How about having a "version" field in the superblock and if we want to=20
:change the media layout, we'd just have to supply a tool which changes th=
:filesystem from the old format into the new format. This way we could=20
:keep on changing the layout without having to worry too much about=20
:incompatible changes. I'd hate to be forced to use an inferior format,=20
:just because we might already have a user base using it.
Yah, there's already a version field, but filesystem upgrades aren't
going to be implemented until after the official first release. There
are simply too many changes being made prior to the official release for
an upgrade path to be a viable option.
Once we release, though, there will clearly be an upgrade path.
While I'm doing this I just realized that I can implement another feature
that I wanted to have for a while. In order to replicate a HAMMER
filesystem the object ID's (i.e. inode numbers) must also be replicated.
Normally this would mean that you have to replicate whole HAMMER
filesystems but with localization I can actually create logical
HAMMER filesystems inside the real HAMMER filesystem, each with its own
object ID space and thus independantly replicatable.
The point here is that one would then be able to have, say, /var, but
then make each directory under /var a filesystem-within-a-filesystem
and replicate them independantly. One might then decide to replicate
/var/db but not /var/log, putting the redundancy and parallelism where
its needing rather then having to use a big-stick approach.
I was going to make the localization field 8 bits but I think I may
make it 32 bits instead, giving us an almost unlimited number of possible