Re: HEADS UP - Another media change for HAMMER

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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=
:e=20
: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.
:
:cheers
:   simon

    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
    logical breakdowns.

						-Matt