New SHARE and WORK variables pointing to the symlink'd location?

[ColemanTom]

Problem

In the global.cylc, we have our share and work directories on lustre, which are symlinked into our workflows area. Typically, we access those locations using things like CYLC_TASK_WORK_DIR and ROSE_DATAC - but they go through the symoblic link. Under low traffic, that is fine, but, we have shown under high traffic this can cause problems and it is less load on metadata servers to use the real path. Someone explained it to me a while ago, but I've forgotten what goes on each time a symbolic link is traversed.

Proposed Solution

When a workflow is installed, it obviously knows that real path as it sets the symlinks up. I would like those variables made available directly in a job script so we can avoid traversing the symbolic links when scripting. I think the symlinks are useful for navigating easily in interactive mode, but from an efficiency perspective, not using them inside a script is better.

[oliver-sanders]

Suggest using realpath to fix these variables in the workflow definition like so:

[runtime]
    [[root]]
        [[[environment]]]]
            CYLC_TASK_WORK_DIR = $(realpath "$CYLC_TASK_WORK_DIR")

This will ensure that all uses of the env var will pick up the resolved location if that is what you want.

[ColemanTom]

Suggest using realpath to fix these variables in the workflow definition like so:

[runtime]
    [[root]]
        [[[environment]]]]
            CYLC_TASK_WORK_DIR = $(realpath "$CYLC_TASK_WORK_DIR")

This will ensure that all uses of the env var will pick up the resolved location if that is what you want.

I know that is doable, but, that still adds some I/O load to the system via realpath. It is very simple to do via the Cylc side without adding any extra load to the remote platofrms. e.g. this MR. Looking at that old one, I'm suggesting what I did there, without the directory creation changes.

[hjoliver]

Seems reasonable to me. E.g. CYLC_TASK_WORKDIR_REAL. @oliver-sanders - are you aware of any downside to doing this?

[oliver-sanders]

The downsides are:

• Site specific, not clear if this will be used beyond BoM.
• More environment variables. We already have a lot, adding realpath variants of these will bloat environment and make things more confusing for users (which variant should I use and why?).
• Scripts may use the non-realpath variants of env vars (hard to enforce, difficult to manage with site-portability), whereas overwriting the env var always works so is a technically superior solution.

If there is no downside to resolving this symlink (requires thought), then we could consider making this the default.

Alternatively, if your site is keen to avoid symlink resolving, then perhaps we could consider a per-platform config to flatten the existing env vars?

[dpmatthews]

I don't think there is any way to safely avoid using realpath in which case I think Oliver's original suggestion makes sense rather than adding more variables.