Subject: Re: Interactive responsiveness under heavy I/O load
To: Johan A. van Zanten <johan@giantfoo.org>
From: Daniel Carosone <dan@geek.com.au>
List: tech-kern
Date: 01/27/2004 09:04:33
--6CiRFyVmOOJ3DkBX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jan 26, 2004 at 02:12:24PM -0600, Johan A. van Zanten wrote:
>=20
> John Goerzen <jgoerzen@complete.org> wrote:
>=20
> > Have I stumbled across the reason softdep is not enabled by default, or
> > is there some other logic behind this?
>=20
> My understanding of how soft dependencies works is that file system
> metadata is cached in memory for a short period of time (like 20
> seconds?), which means it's at risk (of being lost) if the machine
> were to loose power.
Two points:
- The question of "on by default" is shady; softdeps aren't enabled
unless you specify the mount option, but I understand sysinst now
creates fstab's with that option by default. So most users would
have them enabled on new systems at least. I may be wrong about
sysinst, its not something I really ever use.
- You are right about the metadata being delayed, but it's still
written in-order and before the relevant file data. The essential
point of softdep is to allow the ordering up updates to the on-disk
data structures to be preserved, so the ffs and fsck semantics that
depend on these still work, but without requiring synchronous
writes that make everything stop and wait. If you sync or fsync at
the right time, the previous semantics about data on disk or not
still hold.
Speaking very broadly, if your system crashes, the resulting
filesystem state with softdep is similar to if the machine had
crashed a little earlier without (unless you sync). =20
Softdep is such a huge performance win, especially for tasks like
extracting a pkgsrc tree, because lots of metadata writes update
the same disk block repetitively (think about adding files one at a
time to the same directory). With softdep, each of these updates is
done in memory (without the sync disk wait) and the resulting final
directory blocks written to disk (again, speaking very broadly).
=20
--
Dan.
--6CiRFyVmOOJ3DkBX
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)
iD8DBQFAFY7wEAVxvV4N66cRAklBAJ9oJyTWk7Jz76sxKgRQk1PxxgZi9ACaAggB
bfBhPABgvUy/ClpxXs6kqgw=
=nWJQ
-----END PGP SIGNATURE-----
--6CiRFyVmOOJ3DkBX--