[6657] in Athena Bugs
Re: attach fails to try next filsys on bad RVD
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Sat Dec 22 15:50:34 1990
Date: Sat, 22 Dec 90 15:50:21 -0500
To: Mark Rosenstein <mar@MIT.EDU>
Cc: bugs@MIT.EDU, bug-attach@MIT.EDU
In-Reply-To: Mark Rosenstein's message of Wed, 28 Nov 90 11:57:30 -0500,
From: Richard Basch <probe@MIT.EDU>
Date: Wed, 28 Nov 90 11:57:30 -0500
From: Mark Rosenstein <mar@MIT.EDU>
Sender: mar@MIT.EDU
When attaching m48-vssys
Toto>hesinfo m48-vssys filsys
RVD vssys aristarchus r /srvd
RVD vssys hyperion r /srvd
while aristarchus was incorrectly configured, it would successfully
spinup the pack, but then fail to mount it because it was not a VAX
filesystem. So far so good, but it then returned an error instead of
trying to use hyperion. This was verified from toto, a 7.1H VS3100.
-Mark
Actually, it is the RVD code in the kernel that is preventing the second
attach from succeeding... The kernel has cached the blocks from the
first RVD and even though the second is spun up, it still thinks that
the superblock is wrong. I somewhat suspected this was the case, and
noticed that "attach" was trying the proper spinup/mount/spindown
sequence and it tried this on both filesystems.
There are two ways that this problem could be solved:
1) Read the raw RVD from beginning to end, upon spinup, to flush the
previously cached blocks. (This could be done in attach).
2) Fix the kernel to invalidate the cached blocks upon spindown.
-Richard
