Dale Ghent wrote:
I took some time today to investigate the vfsck problems on Solaris 9 with kernel patch 112233-12 or greater applied.
It seems that this patch did change a bit of the UFS structure. The biggest visible change I've been able to find is the removal of the fs_interleave member from the fs struct (defined in /usr/include/sys/fs/ufs_fs.h)
Do you have a diff of the old and new header files? I have patch 112233-12 on my Solaris 9 workstation, but the AFS servers are running with 112233-11 The files are identical.
They have "int32_t fs_interleave; /* hardware sector interleave */
Are you sure you don't have a corrupt verison of ufs_fs.h?
The ufs_fs.h file dated as Aug 7 2003 and a lenght of 24602. and MD5 hash of 86e95798e5c54903adb94403300c891d with #prgma ident "@#ufs_fs.h 2.62 03/02/23 SMI"
The ufs driver reflects this change, and that is why with a vfsck compiled on a previous kernel rev fails with the "IMPOSSIBLE INTERLEAVE" error. So I went into src/vfsck/setup.c and removed the references to fs_interleave from the AFS_SUN5_ENV ifdef blocks. This cleared up that error.
Now, the next error vfsck reports is "CANNOT READ: BLK 0". It seems that the default UFS block size is 8192 bytes. I put some debugging code into utilities.c at lines 409 and 412 and it is reporting block 0 being a size of 1568 bytes. If I tell vfsck to continue past this error, it then displays the same error but reports block 0 being 1584 bytes in size, a difference of 16 bytes:
================================================================= [EMAIL PROTECTED]/tmp/openafs-1.2.11/src/vfsck>./vfsck /dev/md/rdsk/d10 ----Open AFS (R) openafs 1.2.11 fsck---- ** /dev/md/rdsk/d10 DEBUG: The size of block 16 is 8192 bytes. read() rv is 1 DEBUG: The size of block 71619120 is 2048 bytes. read() rv is 1 DEBUG: The size of block 0 is 1568 bytes. read() rv is 0
CANNOT READ: BLK 0 CONTINUE? [yn] y
THE FOLLOWING DISK SECTORS COULD NOT BE READ: DEBUG: The size of block 0 is 1584 bytes. read() rv is 0
CANNOT READ: BLK 0 CONTINUE? [yn] =================================================================
So for some reason, the read() at utilities.c:408 is having issues with block 0 being something (I can't tell what yet - I have only a basic understanding of deep UFS internals) and is returning 0. If I tell vfsck to continue past the second error prompt (see above output snippet, it happily goes through the remaining blocks:
================================================================= CANNOT READ: BLK 0 CONTINUE? [yn] y
THE FOLLOWING DISK SECTORS COULD NOT BE READ: ** Last Mounted on /vicepa ** Phase 1 - Check Blocks and Sizes DEBUG: The size of block 64 is 8192 bytes. read() rv is 1 DEBUG: The size of block 80 is 8192 bytes. read() rv is 1 DEBUG: The size of block 96 is 8192 bytes. read() rv is 1 DEBUG: The size of block 112 is 8192 bytes. read() rv is 1 DEBUG: The size of block 128 is 8192 bytes. read() rv is 1 DEBUG: The size of block 144 is 8192 bytes. read() rv is 1 DEBUG: The size of block 160 is 8192 bytes. read() rv is 1 .... .... =================================================================
Hopefully this can help shed some light on this issue. If someone who knows more about this stuff wants me to try something, just let me know and I'll do it.
/dale
_______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
--
Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
