Hi,
We're having problems with our AIX 4.3.2 AFS 3.5 servers. After a few
days the AFS partitions fsck dirty with errors like the following.
** Phase 5 - Check Inode Map
Bad Inode Map; SALVAGE? y
** Phase 5b - Salvage Inode Map
map agsize bad, vm1->agsize = 0 agrsize = 2048
map agsize bad, vm1->agsize = 56 agrsize = 2048
map agsize bad, vm1->agsize = 0 agrsize = 2048
...
** Phase 6 - Check Block Map
Bad Block Map; SALVAGE? y
** Phase 6b - Salvage Block Map
map agsize bad, vm1->agsize = -1 agrsize = 2048
map agsize bad, vm1->agsize = -1073741825 agrsize = 2048
map agsize bad, vm1->agsize = 1610612735 agrsize = 2048
map agsize bad, vm1->agsize = -536870913 agrsize = 2048
...
Some history: In December we decided upgrade the AFS fileservers from
AIX 4.1.5 to AIX 4.3.2 (migration install) and from AFS 3.4 to AFS
3.5. Soon after, one of the fileservers rebooted and stayed up a few
days then rebooted again. We decided to fsck (we are using the
Transarc fsck) the entire machine and found the AIX partitions ok but
all the AFS partitions had errors like the ones above. Soon after the
fileserver on another server crashed and we fscked all the AFS
partitions on all the AFS servers and found more errors like the ones
above on all but the least active partitions. It has been a few days
now and the AFS partitions are beginning to show fsck errors again.
Some more info: The AFS servers are all differant models of RS/6000s
and were very solid before the upgrade, so we don't think it is a
hardware problem. We are running AFS clients at the 3.5, 3.4, and
3.3(Linux) levels. Backups are now taking more than twice as long for
some reason.
If you can think of any reason why this is happening, we would be most
interested.
Thanks,
- Daniel
--
Daniel Blakeley (N2YEN) Cornell Center for Materials Research
[EMAIL PROTECTED] E20 Clark Hall
