--61jdw2sOBCFtR2d/
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=
es
> >     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=
 be
> >     passively associated with HAMMER's in-memory structures.  When the =
OS
> >     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.
>=20
> NetBSD doesn't use the buffer cache for file data, so I suspect reproduci=
ng
> this behavior is considerably more difficult than Matthew expected.

I read that paragraph differently. I don't disagree that it could well be=
=20
a gotcha about porting, but I took it as meaning they didn't have to roll=
=20
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,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFHXtELWz+3JHUci9cRAvmnAJwKPJ8XqqA4fhowYtyFoG1rA/UdDACeJDt4
VZ41X7WDyD6jpa7/eNpqspU=
=WIwe
-----END PGP SIGNATURE-----

--61jdw2sOBCFtR2d/--