In the S/390 port, it appears that the files put into AFS are never making it to the disk, or are at least not correctly making it to the disk. As long as something remains in the cache it is correctly readable. If you reboot, it is found in the disk cache, but the next to last byte of each 4K block is zeroed, and the last byte is often corrupted. If you restart with another cache directory, the directory structure of afs appears OK, but the files in it do not exist. If you try a memory cache, any attempt to read more than a directory structure hangs. Connecting with Arla from another machine shows the directories as plain files and any attempt to access them fails and hangs. My question is, where is the code that controls writing from the client's cache to AFS space? I suspect that's where my problem is. Umounting /afs gives me: Feb 22 10:56:18 lgate-is kernel: WARM shutting down of: CB... afs... BkG... CTrunc... RxEvent... RxListener... Feb 22 10:56:18 lgate-is kernel: osi_linux_verify_alloced_memory: address 0x7b83861 outside range, index=0, key=68656 Feb 22 10:56:18 lgate-is kernel: osi_linux_verify_alloced_memory: address 0x7b83811 outside range, index=0, key=47872 Feb 22 10:56:18 lgate-is kernel: osi_linux_verify_alloced_memory: address 0x47c2521 outside range, index=0, key=70592 and then a whole bunch more of the osi_linux errors. Any ideas? Adam _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo.cgi/openafs-devel
