|| ||Daniel Phillips <email@example.com>|
|| ||[ANNOUNCE] ddtree: A git kernel tree for storage servers|
|| ||Wed, 19 Mar 2008 00:02:24 -0800|
I have set up a new git tree to better serve the needs of those
interested in advanced storage applications and development.
This ddtree git repository aims to provide a congenial forum for
development of forward looking storage features such as replication and
clustering; and to provide improved kernels for those who consider it
important that their storage servers run efficiently under heavy load
What will be in this ddtree?
* Block layer deadlock fixes (Status: production)
* bio allocation optimizations (Status: functional)
* bio support for stacking block devices (Status: functional)
* vm dirty limit eradication (Status: prototype)
* vm dirty rate balancing (Status: prototype)
* ddlink generic device driver control library (Status: functional)
* ddsetup device mapper frontend rewrite (Status: incomplete)
* ddman kernel cluster harness (Status: upcoming)
* ddraid distributed raid (Status: prototype)
* ddsnap replicating snapshot device (Status: alpha)
Patch set tracking
One task that git does not support well at all is maintaining the
identity of patches and patch sets. This is no doubt due to the fact
that Graydon Hoare never implemented the second of my two
suggestions for improving Monotone's database schema, which is to
say that patches and patch sets should be first class, versioned
objects in the revision control database. One could fairly say that
git caters more to maintainers than submitters, the latter being
largely left to their own devices when it comes to splitting deltas up
into the modular form wanted for peer review. My partial solution to
this deficiency is to embed the interesting patches in a directory
called "patches", each named in such a way that:
ls patches/* | sort -r | xargs cat | patch -p1 -RE
will reverse them, and:
cat patches/* | patch -p1
will re-apply them. This is similar to the way Quilt works, less its
series file, which is replaced by a naming convention that is obvious
from inspection. No doubt I should really begin using Quilt, but I can
always learn that art later. For now, the important thing is to carry
along patch identities in a way that makes life easier for me.
At present, ddtree only carries six patches, all in its main "dd"
branch. These patches are based off of the "ddbase" branch, which is
in turn derived from either a two-dot or a three-dot stable kernel
release. Thus, I intend to track Linus's tree at coarse intervals and
selected stable releases at finer intervals, which will most likely
coincide with significant distributor branch points such as that of
Ubuntu Hardy (long term stable server release).
So for today:
$ tree patches
Other patches expected to land here over the next few days:
* bio.throttle (avoid bio write deadlock)
* ddsnap (snapshots and replication)
* ramback (backing store for ramdisks)
I am still learning git and developing my workflow, so it will take a
few days for that to settle down, during which period I will tear down
and rebase the content several times. Currently I have very limited
bandwidth available, so please be gentle and avoid clone - just clone
a linus tree and pull into that instead. (hpa...?)
To browse ddtree:
To pull from ddtree:
http://phunq.net/git/ddtree (please do not clone for now)
For now there is no git:protocol access because git-daemon manifests
some strange issue I have not yet had time to track down. The symptom
$ tail /var/log/git-daemon/current
2008-03-19_03:49:26.67922  Request upload-pack for '/ddtree'
2008-03-19_03:49:26.68142 fatal: packfile
./objects/pack/pack-d37a0c64e9ce1c8b29ad9c02a39636ca9c609c31.pack cannot be mapped.
Anybody who wants to participate in the ongoing design, development and
debugging of lvm3, among other things: we hang out on irc.oftc.net
#zumastor. Everybody welcome, and see http://zumastor.org.
 Graydon Hoare: see quicksort, then see grandfather.
 Fortunately, Graydon did implement the first suggestion, that
directories should become first class versioned objects, thus setting
the stage for the development of git.
 Monotone, http://en.wikipedia.org/wiki/Monotone_%28software%29
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/