On 10/05/97 23:47:29 you wrote:
Could someone try reproducing this problem? I know it pretty much requires a Netapp that you don't mind the risk of crashing, but maybe there are some new Netapp owners out there. ;-)
It's a long-known problem that rebooting during quota initialization is a Bad Thing (tm). It might have been fixed in 4.1; I'm not sure. I'm sure support will give you the bug ID and let you know the current status of the bug, and how to get you out of your current jam.
As the old doctor joke goes - don't do that!
Bruce
On Mon, 6 Oct 1997 sirbruce@ix.netcom.com wrote:
It's a long-known problem that rebooting during quota initialization is a Bad Thing (tm). It might have been fixed in 4.1; I'm not sure.
I'll check with now.netapp.com when I get into the office, thanks.
As the old doctor joke goes - don't do that!
Well, obviously. ;-) This was one of those "it's late Sunday night, let's try it and see what happens" type of things. I'm glad I found this before I put those F210's into production.
On Mon, 6 Oct 1997 sirbruce@ix.netcom.com wrote:
I'm sure support will give you the bug ID and let you know the current status of the bug, and how to get you out of your current jam.
Yep, now.netapp.com lists the problem as bug #2198, "Panic in wafl_nfs_lookup of quota.db". I ran `wack -y' on the filer, and that seems to have cleared up the problem. I have not yet verified that this bug is fixed in 4.1d yet.
| > wack -y | Phase 1: Verify fsinfo blocks | Phase 2: Verify meta data indirect blocks | Phase 3: Verify self-consistency of blkmap data | Phase 4: Scan inode file | Inofile block 16421: inomap count: saw 2, should be 1. | Adjust? yes | Phase 5: Scan directories | Inode 555944: directory references nonexistent file: quota.db. | Unlink? yes | Phase 6: Clean up | FS info shows total inodes used to be 78249, should be 78248. | Adjust? yes | | Commit changes to disk? yes | Press any key to reboot system.
On Mon, 6 Oct 1997, Brian Tao wrote:
Yep, now.netapp.com lists the problem as bug #2198, "Panic in
wafl_nfs_lookup of quota.db". I ran `wack -y' on the filer, and that seems to have cleared up the problem. I have not yet verified that this bug is fixed in 4.1d yet.
Apparently the fix is scheduled for 4.3.