[549] in Athena Bugs

home help back first fref pref prev next nref lref last post

Zero length files problem...

daemon@ATHENA.MIT.EDU (Chris VanHaren (Athena User Consultant))
Fri Jul 22 17:41:08 1988

To: bugs@ATHENA.MIT.EDU
Cc: carla@ATHENA.MIT.EDU, geer@ATHENA.MIT.EDU, ademola@ATHENA.MIT.EDU,
From: Chris VanHaren (Athena User Consultant) <vanharen@ATHENA.MIT.EDU>
Date: Fri, 22 Jul 88 17:40:11 EDT
	On a suggestion to Carla from Dan Geer, Carla and I think we may
have found one of the more troublesome bugs out there -- namely the
"zero-length files bug".
	For no apparent reason, files (usually while being touched) can
become zero'ed.  Dan suggested that perhaps the inode was getting "lost"
somehow in the transaction.  Looking under /mit/lost+found on the
fileserver turned up quite a few files that had been zero'ed in the
past, which would seem to confirm this.  Some of the files were our own
.meetings files that had been zero'ed, and there they were sitting in
lost+found.  So, when fsck gets run, all those "lost" inodes get rounded
up and stuck in lost+found.
	This may be hard to verify on the spot, as files get zero'ed at
seemingly random times.  The only way to be 101% sure that this is
happening is to notice immediately that a file has been zero'ed, then
bring down the fileserver and run fsck immediately and see what shows up
in lost+found.  This is probably not a very feasible thing to do, as
people aren't going to like having a fileserver brought down just to
find a zero'ed file for one person.
	We are almost positive, though, that this is what's happening.
Now, to find out why the inodes are getting "lost", and to find a fix...

						Chris VanHaren
						Carla Fermann

home help back first fref pref prev next nref lref last post