DragonFly kernel List (threaded) for 2008-06
[
Date Prev][Date Next]
[
Thread Prev][Thread Next]
[
Date Index][
Thread Index]
Re: HAMMER Update - 28 June 2008
: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@backplane.com>
[
Date Prev][Date Next]
[
Thread Prev][Thread Next]
[
Date Index][
Thread Index]