Subject: Re: Porting Hammerfs (fwd)
To: Thor Lancelot Simon <email@example.com>
From: Bill Stouder-Studenmund <firstname.lastname@example.org>
Date: 12/11/2007 10:03:56
Content-Type: text/plain; charset=us-ascii
On Tue, Dec 11, 2007 at 12:36:57PM -0500, Thor Lancelot Simon wrote:
> On Sun, Dec 09, 2007 at 08:44:01PM +0100, Mark Weinem wrote:
> > Matthew Dillon about the state of the HAMMER filesystem and about
> > porting to other systems:
> > ---------- Forwarded message ----------
> > [...]
> > With regards to the OS interface, HAMMER uses 16K filesystem buffers
> > and it shouldn't be too hard to port that part of it. DragonFly us=
> > 64 bit byte offsets for its buffer cache buffers rather than block
> > numbers. There is one big gotcha, though, and that is I am using an
> > augmented softupdates callback API to allow buffer cache buffers to=
> > passively associated with HAMMER's in-memory structures. When the =
> > wants to flush or discard/reuse a buffer, it makes a callback and
> > HAMMER then has the ability to tell the OS NOT to do that by setting
> > B_LOCKED in the bp.
> NetBSD doesn't use the buffer cache for file data, so I suspect reproduci=
> this behavior is considerably more difficult than Matthew expected.
I read that paragraph differently. I don't disagree that it could well be=
a gotcha about porting, but I took it as meaning they didn't have to roll=
a custom cache for their metadata stuff. They have btrees, so they have=20
more complicated in-core structures than say ffs does.
I could be wrong though...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
-----END PGP SIGNATURE-----