Skip to content

DPL: add option to force parentFile colocation#15391

Open
ktf wants to merge 1 commit into
AliceO2Group:devfrom
ktf:pr15391
Open

DPL: add option to force parentFile colocation#15391
ktf wants to merge 1 commit into
AliceO2Group:devfrom
ktf:pr15391

Conversation

@ktf

@ktf ktf commented May 11, 2026

Copy link
Copy Markdown
Member

No description provided.

@ktf ktf requested a review from a team as a code owner May 11, 2026 20:07
@alibuild

Copy link
Copy Markdown
Collaborator

Error while checking build/O2/fullCI_slc9 for 883a847 at 2026-06-11 01:41:

## sw/BUILD/O2Physics-latest/log
CMake Error at /sw/slc9_x86-64/CMake/v4.1.4-2/share/cmake-4.1/Modules/CMakeTestCCompiler.cmake:67 (message):
    ninja: build stopped: subcommand failed.

Full log here.

@jgrosseo

Copy link
Copy Markdown
Collaborator

@costing I vaguely remember that there are SEs which are counted equivalent because they are close by. Would the check created by @ktf work for this case?

@costing

costing commented Jun 11, 2026

Copy link
Copy Markdown
Collaborator

I think the exact SE name is checked in the whereis output. Which is ok, the secondary files are supposed to be stored in the same locations as the original ones, not in nearby SEs.

Just that enabling this check for every file will double the load on the catalogue. We already return the list of PFNs at a ::Open() of the original and the secondary files. So if the check could be deferred to when the files are actually about to be used it would not put additional pressure on the databases. In this form it can be used for one time debugging / optimizing step, but it cannot be done regularly or by default.

@jgrosseo

Copy link
Copy Markdown
Collaborator

I agree. This should run as an extra special train and not be enabled for user trains.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

4 participants