DragonFly kernel List (threaded) for 2008-05
DragonFly BSD
DragonFly kernel List (threaded) for 2008-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: HEADS UP - Another media change for HAMMER

To: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
From: Michael Neumann <mneumann@xxxxxxxx>
Date: Sat, 17 May 2008 22:13:36 +0200

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.



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]