[OpenAFS] Solaris 9 issues - making some progress

[Douglas E. Engert]

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:
> 
> =================================================================
> [root@hfs6]/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
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444