Subject: Re: Porting Hammerfs (fwd)
To: Thor Lancelot Simon <>
From: Bill Stouder-Studenmund <>
List: tech-kern
Date: 12/11/2007 10:03:56
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
> >=20
> > ---------- Forwarded message ----------
> > [...]
> >=20
> >     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...

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.7 (NetBSD)