In message <[EMAIL PROTECTED]>,Dr A V Le Blanc writes: >with kernel 2.6.11.7, and this time the machine is still accessible,
smp? > (5)Input/output error: access to [some file] failed > [notice] child pid 4601 exit signal Bus error (7) i dont believe these are from afs. > kernel: afs: failed to store file (partition full) > AFS_VMA_CLOSE(8072): Skipping Already locked vcp=de257f38 vmap=de257f48 seems like bad news. >For some reason the cache is filling far beyond the configured >limit. 'fs getca' ought to be seeing this and isn't. For some >reason the cache is not being cleared, even after hours of >inactivity. I'm a little puzzled by the numbers as well; >on a 2.4.30 machine with openafs 1.2.13-1, I get this: > > # df /var/cache/openafs > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/hda6 489992 279729 184963 61% /var/cache/openaf >s > # du -s /var/cache/openafs > 279729 /var/cache/openafs > >but on the 2.6.11.7 system I see this: > > # df /var/cache/openafs > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/sda6 521748 521748 0 100% /var/cache/openaf >s > # du -s /var/cache/openafs > 832908 /var/cache/openafs > >which suggest file system corruption. I did not remkfs the partition >before rebooting; perhaps I should try this? well it would be a good idea to mkfs the filesystem before you start 2.6/1.3.81 again just to make sure there are not residual bits. however, i would guess that looks like truncate's arent happening in a timely fashion. i believe someone else on the list has seen this behavior as well and might have a patch to make truncate() synchronize. just curious, is there any chance you could try a memcache? you wouldnt need a very big one. _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
