[OpenAFS] zero length core files with OpenAFS 1.6.5
Thomas M. Payerle
Mon, 5 May 2014 18:44:47 -0400 (EDT)
On Mon, 5 May 2014, Renata Maria Dart wrote:
This sounds like it might be a volume quota issue. 0 byte files are
commonly caused by such on AFS; when writing a new file, a client will
typically create a 0 byte file by that name first, which gets flushed
to the fileservers, and then start writing the file to the local AFS
cache. If the resulting file would cause the volume quota to be
exceeded, it does NOT get written back to the server, but the initial
0 byte file would remain.
(I am sure others on the list can explain this in a more technically
precise manner, but I think the above gets the gist of it.)
AFS will have the error code returned on the close system call, but
many applications fail to check that. For core file generation, I am not sure
that there is much it could do to report the error anyway.
> Hi, we had a user report that he was only getting 0-length core files
> from his segfaulting executable when writing the core into AFS from a
> rhel6 64-bit linux system. We have confirmed that under OpenAFS 1.6.5
> this appears to be so. The executable can write a normal core file on
> that same linux system if writing to nfs or /tmp. Is this a known
> issue that might be fixed in a later version of OpenAFS?
> A bit more information...we had a rhel6 64-bit linux system running
> OpenAFS 1.6.1 and a back-level linux kernel 2.6.32-358.23.2 that could
> successfully write a core file into AFS. We upgraded the version of
> OpenAFS to 1.6.5 leaving the kernel at the same older level and now
> only get 0-length core files when writing to AFS. The same failure
> occurs with OpenAFS 1.6.5 and newer linux kernels like
> 2.6.32-431.11.2. Core files written to OpenAFS 1.6.2 are also fine.
> OpenAFS-info mailing list
University of Maryland (301) 405-6135
College Park, MD 20742-4111