[OpenAFS] Odd vfsck behavior under Solaris 9

[Tim C.]

> the problem exhibits itself as such:
>
> [root@hfs6]~>/usr/lib/fs/afs/fsck /dev/md/rdsk/d1
> ----Open AFS (R) openafs 1.2.11 fsck----
> ** /dev/md/rdsk/d1
>
> CANNOT READ: BLK 0
> CONTINUE? [yn]
>
> If I answer "y" twice, the fsck performs.
>
> Now if I pass AFS fsck the block device, it goes on its merry way
> without complaining.
>
> So in summary, the problem is AFS fsck not liking to look at the raw
> device... but it should. UFS fsck does not complain at all.
>
  I've been working with Dale on this.  And I just built a completely
fresh machine in attempting to trace down the problem.  The machine is
solaris 9, patch set as of about April or so, kernel Generic_112233-12,
and opeanfs 1.2.11.

I've created two partitions on a 36g disk, with partition 6 taking up
most of the space.  Made a filesystem with newfs on it, and attempted to
fsck it with the afs fsck.

(2:49pm)Root@mrhat<sun/afsserver>echo "y" | newfs /dev/dsk/c0t1d0s6
Warning: cylinder groups must have a multiple of 16 cylinders with the
given parameters
Rounded cgsize up to 256
/dev/rdsk/c0t1d0s6:     71104068 sectors in 24612 cylinders of 27
tracks, 107 sectors
        34718.8MB in 770 cyl groups (32 c/g, 45.14MB/g, 5632 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
 32, 92592, 185152, 277712, 370272, 462832, 555392, 647952, 740512,
833072,
Initializing cylinder groups:
...............
super-block backups for last 10 cylinder groups at:
 70263200, 70355760, 70448320, 70540880, 70633440, 70726000, 70818560,
 70911120, 71000096, 71092656,

(2:49pm)Root@mrhat<sun/afsserver>/usr/lib/fs/afs/fsck /dev/rdsk/c0t1d0s6
----Open AFS (R) openafs 1.2.11 fsck----
** /dev/rdsk/c0t1d0s6

CANNOT READ: BLK 0
CONTINUE? [yn] n

Program terminated


  As Dale mentioned, if you give it the dsk device, it works fine, but
obviously something else is wrong if you can't give it the rdsk device.

  Is anyone using the inode fileserver on solaris 9 successfully?  I
don't really want to go to the iname on ufs, because the performance
goes down tremendously, from what I've heard.

Thanks for any help, insight, advice anyone can give us!
  Tim

-----------------------------------------------------------------------
Tim Craig            These are my opinions and not my employers. :)
OIT-Systems
tim@umbc.edu         It's hard to be serious when you're
                       naked. - Garfield
-----------------------------------------------------------------------