--B4IIlcmfBL/1gGOG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 23, 2006 at 07:43:45AM -0500, Cary G. Gray wrote:
> On Sun, 22 Oct 2006, Bill Studenmund wrote:
> ...
> >I think an inode is the best way for now. I don't think a jffs will have
> >the same problem LFS has as files stay put on ffs once allocated. While
> >the contents of the journal will change with time, its location won't.
> >Thus the only metadata updates would be m & a time. Assuming we desired
> >keeping them current (which I don't think we need to bother with).
>=20
> In order to avoid loss of the journal, you actually need to make sure tha=
t=20
> none of its metadata is rewritten at all--not the block containing its=20
> inode, nor any indirect blocks.  Failure during a rewrite of those leaves=
=20
> you with a corrupted journal, which leaves you with a corrupted=20
> filesystem.  (My assumption here is that failure during a disk write can=
=20
> leave a sector unreadable.)

Kinda.

ffs, and most other file systems, do not deal well with i/o errors on=20
meta-data blocks. This applies to all metadata blocks, not just the=20
journal. So the journal is doing nothing new...

> It is probably necessary to special case the journal inode timestamps,=20
> too, because writing to the log updates the journal inode timestamps,=20
> which produces a log write, which updates the timestamps...

No. NetBSD has a lazy timestamp behavior. Doing something that would
trigger an update (read or write) merely flags the node as needing an
X-time update. The update doesn't happen until something else flushes the
inode to disk.

Take care,

Bill

--B4IIlcmfBL/1gGOG
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFFPSaoWz+3JHUci9cRArxWAKCOarc7EMnFoA8PaU2DlwMIc0f0TQCeLrNA
UYvS5y9tbQpui7lKzxBtf9A=
=MEX1
-----END PGP SIGNATURE-----

--B4IIlcmfBL/1gGOG--