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

On Sun, Jul 02, 2006 at 12:38:38PM -0400, Chapman Flack wrote:
> Kirill Kuvaldin wrote:
> > Asynchronous journaling filesystem can be several times faster than a
> > traditional synchronous FFS.
> >...
> >* When a journaled filesystem reboots, if there are any journal entries
> > that were not marked as completed, the system must *replay* the entries
> > to bring the metadata structures up-to-date. Replaying the journal
> > prevents partial updates because each journal entry is a complete,
>=20
> It seems to me that a useful high-level picture to provide would be the
> relationship of ffs+journal not to ffs+sync (which is a comparison that
> hardly needs to be drawn) but to ffs+softdep, in terms of the sets of
> adverse events that can be recovered from, and the differences in time
> required in normal operation and for recovery (here I mean the theoretical

I think the main event recovery set is about the same for journaling and=20
softdeps.

"Normal operations" for softdeps needs a little fudging. Something's not=20
quite right with our flush algorithm, and so we cache a lot, then slam it=
=20
out to disk on one go. So you need a lot of work to average over a few=20
slams for a fair comparison.

For large file systems (say hundreds of GB into the TB), journaling
clearly blows softdeps out of the water for recovery. The main reason is=20
that the journal knows what blocks/parts of the file system were being=20
worked on. With softdeps, you have to scan the whole file system. So=20
compare recovery of writing 64M or 256 M of data with scanning a > 100 GB=
=20
disk.

> differences, as the practical ones can be obtained later through
> benchmarking).  That might be review for readers who live and breathe
> filesystems, but it might be helpful for others in setting the stage.

I hope the above helps.

Take care,

Bill

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

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

iD8DBQFEqVs6Wz+3JHUci9cRAnGbAJ9Gvx4pIdecmSEiWDmXEBP8fkMu2gCeLXGm
mPNcp9D9+xGgBHHhZV6GhQM=
=9n/s
-----END PGP SIGNATURE-----

--gatW/ieO32f1wygP--