[2081] in SIPB-AFS-requests
[daemon@ATHENA.MIT.EDU : Re: There's a gopher in my filesystem]
daemon@ATHENA.MIT.EDU (marc@MIT.EDU)
Tue Aug 1 18:14:18 1995
From: marc@MIT.EDU
Date: Tue, 1 Aug 1995 18:12:40 -0400
To: sipb-afsreq@MIT.EDU
This is interesting and relevant to us, as it describes a problem
we've seen.
Marc
------- Forwarded transaction
[4027] daemon@ATHENA.MIT.EDU (rick@msc.cornell.edu) Info-AFS_Redistribution 07/31/95 10:04 (44 lines)
Subject: Re: There's a gopher in my filesystem
Reply-To: rick@msc.cornell.edu
From: rick@msc.cornell.edu
X-Originated-From: hannah.msc.cornell.edu
To: Mark.Giuffrida@umich.edu (Mark Giuffrida)
Date: Mon, 31 Jul 1995 09:25:43 -0400 (EDT)
Cc: info-afs@transarc.com
In-Reply-To: <199507311312.JAA03387@frampton.engin.umich.edu> from "Mark Giuffrida" at Jul 31, 95 09:12:22 am
Mark Giuffrida writes:
> First off, we get this all the time too and I believe its normal behavior.
> Here is whats happening:
>
> An application opens file for logging errors and holds the descriptor open.
> It doesn't have errors to log to it, so the first write has never occurred.
> Chances are it will never have any errors to log, so basically the first block
> of data for the file has not been sent to the fileserver.
>
> Now lets look behind the scenes. When the file is created and opened for
> writing, the fileserver allocates a directory entry for the file and inserts
> it into the directory structure. For efficiency reasons, it waits until the
> first block of data has arrived before it allocates the file vnode. Thus,
> when the fileserver is salvaged, you have a directory entry with no
> corresponding vnode and the salvager doesn't know what to do with it other
> than delete it.
>
> Probably what should happen is there should be some sort of initial state set
> so that the salvager can recognize the condition and simply ignore it.
AHAH! When first invoked, gopher creates and closes a zero-byte
.gopherrc. Unless bookmarks are created, it stays zero-byte.
This is obviously unrelated to my original volume corruption problem.
I still haven't heard what people consider prudent maintenance
practice for running fsck and salvage periodically.
-Rick
--
|Rick Cochran 607-255-7223|
|Cornell Materials Science Center rick@msc.cornell.edu|
|E20 Clark Hall, Ithaca, N.Y. 14853 cornell!msc.cornell.edu!rick|
| "Workstations - I bet you can't eat just one!" |
--[4027]--
------- End forwarded transaction
