If you can then there might be a workable solution to your problems:
- Instead of chown -R to copy up all dirs and metacopy all files
create an identical opaque directory hierarchy and *move* all the
files into the opaque directory hierarchy.
- When the service detects a new subdir on NFS, add the subdir to the
opaque directory hierarchy and *move* the files from the merged subdir
to the opaque subdir of the same name.
The result is that:
- all the directories in the opaque hierarchy are opaque as you wanted
- all the files have metacopy and absolute redirect
- if you take care no to expose the merged hierarchy to users (only to
the service), then the overlayfs merged hierarchy will not have any
readdir caches (service only iterates on NFS directly)
- if service only ever accesses the merged hierarchy as the move source
then there should be no negative lookup caches in the merged hierarchy
- all this happens legitimately while overlayfs is mounted, without
having to manually tweak trusted.overlay xattrs and drop caches
Assuming that I didn't miss anything and this can work for you,
how can we document it to make the behavior "defined"?
My thinking is:
"Changes to the underlying filesystems while part of a mounted overlay
filesystem are not allowed. If the underlying filesystem is changed,
the behavior of the overlay is undefined, though it will not result in
a crash or deadlock.
One exception to this rule is changes to underlying filesystem objects
that were not accessed by a overlayfs prior to the change.
In other words, once accessed from a mounted overlay filesystem,
changes to the underlying filesystem objects are not allowed."
But this claim needs to be proved and tested (write tests),
before the documentation defines this behavior.
I am not even sure if the claim is correct.
One more thing that could help said service is if overlayfs
supported a hybrid mode of redirect_dir=follow,metacopy=on,
where redirect is enabled for regular files for metacopy, but NOT
enabled for directories (which was redirect_dir original use case).
This way, the service could run the command line:
$ mv /ovl/blah/thing /ovl/local
then "mv" will get EXDEV for moving directories and will create
opaque directories in their place and it will recursively move all
the files to the opaque directories.
Actually, current code does not even check for redirect_dir=on
(i.e. in ovl_can_move()) before setting redirect xattr on regular
metacopy files.
So as far as I can tell, the following UNTESTED patch might
be acceptable, so you can try it out if you like if you think this
will help you implement to suggestions above:
--- a/fs/overlayfs/params.c
+++ b/fs/overlayfs/params.c
@@ -824,15 +824,9 @@ int ovl_fs_params_verify(const struct ovl_fs_context *ctx,
config->metacopy = true;
}
- /*
- * This is to make the logic below simpler. It doesn't make any other
- * difference, since redirect_dir=on is only used for upper.
- */
- if (!config->upperdir && config->redirect_mode == OVL_REDIRECT_FOLLOW)
- config->redirect_mode = OVL_REDIRECT_ON;
-
/* Resolve verity -> metacopy -> redirect_dir dependency */
- if (config->metacopy && config->redirect_mode != OVL_REDIRECT_ON) {
+ if (config->metacopy && config->redirect_mode != OVL_REDIRECT_ON &&
+ config->redirect_mode != OVL_REDIRECT_FOLLOW) {
if (set.metacopy && set.redirect) {
pr_err("conflicting options:
metacopy=on,redirect_dir=%s\n",
ovl_redirect_mode(config));
--
Apologies in advance if this idea is flawed.
Thanks,
Amir.
