Date: Wed, 15 Dec 1999 15:18:01 -0500 From: bill@twwells.com (T. William Wells) To: freebsd-questions@freebsd.org Subject: Re: softupdates... the sequel Message-ID: <838som$7n2$1@twwells.com> References: <Pine.BSF.4.21.9912110346420.56533-100000@dogma.freebsd-uk.eu.org> <82ui21$2s8a$1@twwells.com> <19991213185734.B358@mojave.worldwide.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <19991213185734.B358@mojave.worldwide.lemis.com>, Greg Lehey <grog@lemis.com> wrote: : On Saturday, 11 December 1999 at 17:13:00 -0500, T. William Wells wrote: : > I'm not sure what the fix here is. Softupdates *should not* have : > this effect. My guess is that what is happening is that : > softupdates doesn't handle I/O errors well. The quick hack would : > be for softupdates to disable itself as soon as a partition : > reports an I/O error.... : : Since the primary intention of soft updates is to handle I/O errors : well, you can believe that we're concerned about this. If you can : give us details of what goes wrong, preferably repeatable, we'll be : grateful. Yes, this is asking a lot. No way to reproduce it -- production machines get fixed ASAP. I noticed two different effects that might point a finger. One of them was that various parts of inodes got random data stored in them. E.g., the file modes would have some large 32 bit integer of no obvious provenance stored in them. The other was large quantities of DUPs found during fsck. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?838som$7n2$1>