caching problem with gluster

we started hitting errors under very small load caused by core_component.php being stored on gluster share

```
[2018-05-23 08:30:03.116483] W [MSGID: 109065] [dht-rename.c:1387:dht_rename_lock_cbk] 0-data-dht: acquiring inodelk failed rename (/moodledata/cache/core_component.php.tmp:5198d4b6-82fd-48a5-90f2-0813370dc81e:data-replicate-0 /moodledata/cache/core_component.php::(null)) [Stale file handle]
[2018-05-23 08:30:03.116582] W [fuse-bridge.c:1788:fuse_rename_cbk] 0-glusterfs-fuse: 581920: /moodledata/cache/core_component.php.tmp -> /moodledata/cache/core_component.php => -1 (Stale file handle)
[2018-05-23 09:57:55.228929] E [MSGID: 109040] [dht-helper.c:1198:dht_migration_complete_check_task] 0-data-dht: /moodledata/cache/core_component.php: failed to lookup the file on data-dht [Stale file handle]
[2018-05-23 09:57:55.229002] W [fuse-bridge.c:1355:fuse_unlink_cbk] 0-glusterfs-fuse: 586329: UNLINK() /moodledata/cache/core_component.php => -1 (No such file or directory)
```

changing it to local file system improved performance and got rid of the error
```
$CFG->alternative_component_cache = '/tmp/core_component.php';
```

Start by tracing how core_component.php is stored and replaced under /moodledata/cache, then compare that behavior with the alternative_component_cache setting shown in the report. The issue demonstrates a local-filesystem workaround but does not define the desired fix or a testable completion condition.

Written by the indexing model from the issue text.