A cruncher on CPDN has posted the following.

I have a bunch of tasks on one of my computers which failed with exit code 12 or 25.

On ones with exit code 12 I see an error like:

checkdir:  cannot create extraction directory: hadam4h_a21t_209911_4_867_012014556
           File exists

On ones with exit code 25 I see a bunch of errors like:

Could not read directory attributes: Value too large for defined data type

or

checkdir error:  cannot create hadam4h_a0wt_209411_4_868_012016230/datain/ancil/ctldata
                 File exists
                 unable to process datain/ancil/ctldata/stasets

/.

Subsequent discussion leads the cruncher to think it is a problem with the executables from CPDN and the XFS file system.

I will try a clean install of Ubuntu to test this if we don't get an answer by the time my current work on the machine is finished. But I was wondering if anyone with experience of XFS and BOINC has anything to add.

detaching and re-attaching to the project in case of corrupted files was tried without success.

https://www.cpdn.org/forum_thread.php?id=8967 Is the original post and discussion.

I agree that

Could not read directory attributes: Value too large for defined data type

indicates that the volunteer operating environment has outgrown the assumptions made when compiling the CPDN applications for BOINC compatibility. That happens: BOINC was caught out when SETI task numbers and later workunit numbers outgrew the 32-bit integer storage space previously allocated. At this stage, that's a problem for CPDN to sort out.

But it reminds me of an older CPDN problem.

CPDN downloads a *lot* of data for each task, and to save time downloads it in .zip (compressed) format. When starting, the first thing it does is to decompress the data into a task-specific sub-directory in the project folder. As I remember it in the past, the CPDN app deleted the sub-directory on successful completion, but sometimes failed to clean it up when the app crashed - leaving a lot of unnecessary data lying around, wasting space. Looking at my new-ish Linux machines, that doesn't seem to be a problem now - I know I crashed at least one task while testing whether I had the 32-bit libs (I didn't). There no trace of that crashed task now - or maybe the 32-bit lib crash happens so early that the files never get decompressed.

Whatever. Maybe

checkdir:  cannot create extraction directory: hadam4h_a21t_209911_4_867_012014556
           File exists

is something similar. The app gets far enough to decompress the input data, then crashes, and exits leaving the data behind. If it tries to re-start, the data is still there, and the directory can't be created for the reason stated. That would be another problem for CPDN to solve: BOINC looks after the slot directories (cleaning them up after use), but the project has to manage its own private project directory.

Thanks Richard.

I will email Andy/Sarah with this.

Just thinking,

Could not read directory attributes: Value too large for defined data type

Would I guess be related to the partition size and so if when I finish the work on my laptop and do a clean install of Ubuntu20.04, with only a 500GB system SSD and a 1GB mechanical drive for data, even if I used XFS I probably wouldn't see the error?

User has managed to work out a solution.

LD_PRELOAD seems to work. What I did was:

Compile inode64.c from the link above based on the instructions in that file.
Place it at /usr/local/lib/inode64.so
Add LD_PRELOAD=/usr/local/lib/inode64.so to /etc/sysconfig/boinc-client (EnvironmentFile in the boinc-client systemd service points to this).



Now, CPDN is running nicely.