DragonFly kernel List (threaded) for 2008-06
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
HAMMER update - 22 June 2008. heads up on hammer prune vs softprune.
Heads up - 'hammer prune' is being removed, 'hammer softprune' is going
to become the official way to prune the filesystem. I will add a
'hammer pruneall' command for emergencies which will do the same thing
that 'hammer prune everything' does now.
There are two reasons for doing this. First and foremost, transaction
id's can wind up not reflecting the current date and time. If the
filesystem is modified while the system time is off kilter it can cause
the transaction id to jump. If the system time is then corrected HAMMER
cannot back-up the transaction id and the ids will no longer match the
time. If this occurs the old pruning commands stop working properly.
I want to make a clean break before the release so transaction ids
are not assumed to be time stamps, even if they kinda act like timestamps.
The second reason is that it is a whole lot easier to manage pruning
based on a directory full of softlinks. Amoung other things we will
be able to implement different pruning regimens for different parts of
the directory hierarchy.
--
Pseudo-fs support will be committed today. A pseudo-filesystem is
basically a HAMMER filesystem inside a HAMMER filesystem, with its
own inode numbering space. Pseudo-fs's can also be pruned
independantly. The primary reason for doing this is for mirroring
support but ultimately it will also remove the need to partition
the drive.
--
I still have some issues to work through on the mirroring support, but
its looking better for the release. The main problem is figuring out
how to make it work in a multi-master environment (something we will
have to support for the later clustering work). That is, so changes
made on one machine propogate to the other mirrors and vise-versa without
creating mass confusion.
Ultimately (looking forwards into the clustering goal) DragonFly will
have to do conflict resolution and cache coherency in a kernel layer
to ensure that only non-conflicting modifications reach the underlying
filesystem. But in a multi-master environment, once the OS has decided
a modifiying operation can run, the changes are committed to one of
the N master copies of the filesystem and then must propogate to the
other masters. Any master must be able to propogate to any other
master, all in parallel. The underlying mirroring code being worked
on now will also be responsible for multi-master updates.
For the release we will have the mirroring support, but not the
conflict resolution support. The mirroring support just by itself
will be a very powerful tool of course.
-Matt
Matthew Dillon
<dillon@backplane.com>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]