--9zSXsLTf0vkW971A
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 23, 2007 at 09:35:26PM -0500, Johan A. van Zanten wrote:
>=20
> Bill Stouder-Studenmund <wrstuden@netbsd.org> wrote:
> > Thank you. However we were wanting to compare soft updates with a=20
> > journaled ffs, not LFS.
>=20
>  I'm sorry, i'm a little confused now.  What you previously said was:
>=20
> "Do you have any recent references? Specifically NetBSD-based ones?"
>=20
>  Is there a journaled FFS in NetBSD?  If not, how was i to compare this
> all on NetBSD?  Or were you suggesting that we compare NetBSD FFS + soft
> updates against a journaled file system on another OS like Solaris or AIX?
>=20
>  It seems like this would be an inherently inaccurate comparison due to
> the different ways the various OSes buffer and cache data, not to mention
> things like default block sizes for writes, or file system clusters.

I agree with the concerns you raise above about comparing different OSs
and file systems. I however feel that comparing LFS and any form(s) of FFS
is equally suspect when we are discussing FFS metadata update policy and
procedure.

Part of my interest was to see if soft updates on NetBSD got as close to=20
FSS async as it did when those papers were published, and to see how the=20
system performed across different block sizes. Especially tests that=20
generate a large amount of metadata. The perception we have is that=20
Soft Updates can trigger a flood of data when the right update is=20
triggered. The system becomes unresponsive at such a time.

>   I would be interested in seeing ZFS in more OSes than Solaris; i've
> heard only good things about it from many Solaris sysadmins.  I'm not at
> all arguing with you about this.  But it seems a little like you said,
> "Show me data from a recent NetBSD" and then i did, and now you are
> saying, "Show me data from a JFS," which NetBSD does not have.
>=20
> How about we come at this from the other side. Can you provide any data
> indicating that a JFS is substantially faster than FFS + soft updates (SU)
> with comparable hardware and OS considerations?

I'm sorry, we are not pushing a journaled ffs because we feel FFS + Soft=20
Updates is slow. We are pushing it because of 1) the fact that, baring=20
programming errors or driver and i/o errors, once you play the journal,=20
the fs is consistent, and 2) the perception that running with soft updates=
=20
is too similar to using ffs in asynchronous mode. Yes, it's fast. However=
=20
when something goes wrong, you're left with a spectacular mess.

> The context of this original dicussion was improving file systems in
> NetBSD.  Adding a JFS would be an improvement, of course.  But my point is
> that adding background fsck to FFS might be easier and at the moment, it
> seems as if it's unclear if a JFS will perform better?

We will not know if a journaled FFS will perform better or worse than FFS=
=20
+ Soft Updates until we have it.

We know we need to work with ext3fs, and adding that will require 90% of=20
the work for a journaled FFS. We also have people who are interested in=20
working on journaled FFS.

As I stated earlier, we will not object to a contribution of patches=20
adding background fsck. To be honest, I now actually like the idea in the=
=20
contest of a journaled ffs as well, as it's good to occasionally (say once=
=20
every 100 boots or once every 3 to 6 months) check a whole file system for=
=20
consistency. You can also refresh your RAID 5 and/or RAID 6 at the same=20
time.

Take care,

Bill

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

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

iD8DBQFGCGNKWz+3JHUci9cRAlvHAJ9sdeMxo1LKUtFzY7OGujkqe9tKygCdGKnd
/N6nTCKGZIjIOix0dfjqPDo=
=i8v1
-----END PGP SIGNATURE-----

--9zSXsLTf0vkW971A--