EIO when entry changes file type about cvmfs

[jblomer]

Many thanks for the report and the detailed analysis!

That's an interesting problem. In any case, it seems cvmfs needs to remember the type of the active inodes. That should be relatively easy to do. The question is what to do with this information when a type conflict arises. What we cannot do is invalidating the inode within a fuse callback because that can lead to a deadlock. So most likely, in such a case we'd need to issue a new inode for the entry. The tricky bit is how this will be handled in the cvmfs inode tables. Because at this point, we'd have two inodes for the same path, which is currently not foreseen.

Let me think a little about it.

[jblomer]

Just for information, the corresponding JIRA ticket

[mharvey-jt]

Our mitigation for this is to set the kernel cache timeout for off-cvmfs symlinks to zero.
#2950

[jblomer]

This issue is linked to the problem described in CVM-2001. In both cases, it seems we need to break the current relationship between a path and exactly one live inode. Here's a sketch on how this may work

1. In the LOOKUP callback, there are two conditions where instead of the live inode we place the unique inode from the file catalogs in the inode tracker: when the file type changed and when we have an open file of that inode with a different content than its current version
2. We can use the most significant bits in the inode tracker to store the file type
3. The FORGET call need to take careful about the removal of path --> inode entries now that multiple inodes may point to the same path
4. For open, old inodes, we still need to be able to handle GETATTR queries, so we need to store the struct stat information of open files
5. When the file type changes, we may need to trigger an inode invalidatation (as usual, in a different thread) on the old one

This change requires a hard look an all the possible corner cases.

[jblomer]

Much simpler, turns out to be essentially a one-liner (modulo class rename and integration test): We need to track positive name lookups in the dentry tracker, which has been renamed because it is now not only tracking negative lookups anymore. Tracking the positive name lookups results in eviction of the corresponding kernel-cached dentries during catalog reload.

So this issue is quite different from CVM-2001. I'll create a separate PR addressing CVM-2001.

[jblomer]

Much simpler, turns out to be essentially a one-liner (modulo class rename and integration test): We need to track positive name lookups in the dentry tracker, which has been renamed because it is now not only tracking negative lookups anymore. Tracking the positive name lookups results in eviction of the corresponding kernel-cached dentries during catalog reload.

Hm, it seems that this is too strong a measure. Test case 076 fails and there may be more problems because with this approach entries appear to be deleted after a catalog reload. So for the moment, we are only at a point where we detect changed file system types. More effort is needed on this issue.

[jblomer]

Related discussion found by @HereThereBeDragons

[jblomer]

For the record, CVM-2001 got fixed with #3043

[jblomer]

This should be fixed as a side effect of #2949, specifically of the new fuse_expire_entry

[jblomer]

We should adjust integration test 698 on platforms supporting fuse_expire_entry.

[HereThereBeDragons]

Yes PR #2949 should fix this issue.

Made a new issue #3172 for the integration test