-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Do real revalidation of "remote" file systems #4
Copy link
Copy link
Closed
Labels
area: container runtimeIssue related to docker, kubernetes, OCI runtimeIssue related to docker, kubernetes, OCI runtimearea: filesystemIssue related to filesystemIssue related to filesystemarea: integrationIssue related to third party integrationsIssue related to third party integrationspriority: p2Normal priorityNormal prioritytype: bugSomething isn't workingSomething isn't working
Metadata
Metadata
Assignees
Labels
area: container runtimeIssue related to docker, kubernetes, OCI runtimeIssue related to docker, kubernetes, OCI runtimearea: filesystemIssue related to filesystemIssue related to filesystemarea: integrationIssue related to third party integrationsIssue related to third party integrationspriority: p2Normal priorityNormal prioritytype: bugSomething isn't workingSomething isn't working
Type
Fields
Give feedbackNo fields configured for issues without a type.
Re this item in the FAQ:
DirentOperations(akin todentry_operationsin Linux; embedded inMountOperations, which are about to be renamedMountSourceOperations, and are akin tosuper_operations) currently haveRevalidateandKeepmethods.In Linux, revalidation will stat the inode to see if anything has changed. If it has, it re-walks to that node.
In gVisor, revalidation always returns false for host files, so the sandbox will notice the new file either when it falls out of the Dirent cache or when you readdir the containing directory. For Gofer files, revalidation is controlled by whether Dirents are cached or not, which should also not be the case.
We should be following Linux more closely here, which would also resolve the above problem. For Gofers, we should provide a configuration option to say "don't revalidate" that one can use as a performance optimization if they know only gVisor has access to that mount and nothing else can add/change/remove files.