Re: HEADS UP - Another media change for HAMMER

[Michael Neumann <mneumann@xxxxxxxx>]

Matthew Dillon wrote:
> :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.

Superb! Exactly what I was waiting for! And this would also solve the
pruning "problem" we discussed a few days ago -- pruning of files that
are located in a directory -- and that very efficiently.

Do you already have an idea how those filesystems-within-a-filesystem
are maintained? In ZFS I can create filesystems like:

  zfs create tank/usr
  zfs create tank/usr/obj

Would there be a similar tool for HAMMER, or is each directory basically
a filesystem on it's own? The latter would mean that there is no need
for such a tool, leading to less administrative overhead.

Regards,

  Michael