HAMMER Update - 28 June 2008

[Matthew Dillon]

:Matthew Dillon wrote:
:>     The pseudo-fs's use the same space management as the primary mount
:>     right now.  I am not tracking space use on a per-pseudo-fs basis.
:
:But that should be possible quite easily, using the b-tree, right?  This would be really great.  One big filesystem, limits can be set dynamically.  I never understood the need for having 10 filesystems.
:
:cheers
:  simon

    Space use is tracked in the volume header.  I would need to have a
    per-pseudofs field to track it on a pseudofs-by-pseudofs basis.

    I am going to have to create some extension records to add the 
    label field for the pseudofs (for the mirroring safeties).  I can
    certainly reserve space in there to track space use as well, but
    I don't think I have time to hook the rest of it up for the first
    release.  Definitely not difficult to do, though.

    Lets tick off the reasons why we have multiple mounts and see how
    many we can discard:

    * Physical separation for safety purposes.

	Pseudofs doesn't take care of this, but ultimately HAMMER
	will be robust enough that physical separation will not be
	necessary.  One might still want a separate root partition,
	though.

    * Physical separation for locality of reference and to reduce
      fragmentation.

	Pseudofs doesn't take care of locality of reference but the
	reblocker does, so we might be ok here.

    * Logical separation for backups, replication, mirroring, etc.

	Pseudofs will take care of this.

    * Logical separation for NFS exports.

	Pseudofs will take care of this.  Oops.  Something else I have to
	make work with pseudofs's (the duplicate inode space will give NFS
	fits if I don't make it look like a separate filesystem).  Grumble,
	more work!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>