Subject: Re: Summer of code ideas
To: Johan A. van Zanten <johan@giantfoo.org>
From: Bill Stouder-Studenmund <wrstuden@netbsd.org>
List: netbsd-users
Date: 03/27/2007 12:29:56
--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 24, 2007 at 04:19:46PM -0500, Johan A. van Zanten wrote:
>=20
>   But given that NetBSD has no journaled FS, what else did Bill hope i
> would use in a "NetBSD-based" comparison?  Perhaps i should have just
> ignored Bill's original "Do you have any recent references?  Specifically
> NetBSD-based ones?" as an inherently flawed question because there is no
> sutiable JFS on NetBSD.  I still don't really understand why he asked for
> recent NetBSD-based reference if it's impossible to produce them.

I'm sorry. The question was intended to be mostly rhetorical, given the=20
lack of journaled ffs availability. However I know that there are at least=
=20
three FFS implementations out there (Seltzer's, NSS had one, and Wasabi=20
has one). There probably are more. You may well have had open-source=20
access to one of them!

Also, another part of my concern is that disk performance has changed in=20
the past 7 years. Data transfer rates have gone up while mid to long range=
=20
seek performance has stayed put. As such, a journaled implementation on a=
=20
disk that can support multiple operations at once. We have one seek to=20
write the journal, then a lot of seeks to write all the writes in it.=20
However, the disk gets to order all the follow-up writes as it sees fit,=20
so it can (hopefully) get better performance.

Soft updates can delay metadata writes, but it still has to write them in=
=20
order (except in the case where a file has come and gone before the create=
=20
updates were pushed out). So you can end up with seek dificulties. Since=20
we don't have a great flush system, we can end up needing to do multi-seek=
=20
writes at inconvenient times.

Take care,

Bill

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

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

iD8DBQFGCX7EWz+3JHUci9cRAuEsAJoC30RBJ7uooAAYITVI5OcLCs+/uwCdEdRL
RhflE/sCvejn8nLqK1HeayA=
=oCbW
-----END PGP SIGNATURE-----

--mYCpIKhGyMATD0i+--