Sorry, I missed the existence of this more specific mailing list. Below is the email I previously sent to the overall list (https://lkml.org/lkml/headers/2023/7/17/1478) ----- We would like to be able to "reset" an overlay-fs directory entry, i.e. remove whatever might exist for this entry in the upper layer and revert back to whatever is in lower layer. This operation would be akin to a regular removal, except without creating whiteouts to cover up anything in the lower layer. As far as our team could discern, the kernel currently does not support this operation. Thus, we are considering what would be necessary to implement this ourselves. Our initial exploration led us to `ovl_do_remove` within `fs/overlayfs/dir.c` and in particular this conditional: if (!lower_positive) err = ovl_remove_upper(dentry, is_dir, &list); else err = ovl_remove_and_whiteout(dentry, &list); That seemed like a good place to begin --- if one were to force the first case no new whiteouts would be created, correct? Assuming that is indeed the right place to start, I have two follow-up questions. 1. Since the desired end result of the operation is strictly closer to the lower layer, should we possibly eliminate some of the other operations in a fresh copy of this function? For instance, might `ovl_copy_up` be unnecessary because if the upper layer already doesn't "contribute" to this dir entry, no action would need to be taken? Additionally, what is the significance of `nlink`? We have not found much documentation for it; from what we understand, it's an `xattr` used so some information for the overlay-fs is persisted on disk. 2. What is the recommended approach to expose this functionality? We assume it would be through a new `ioctl`, but with no existing overlay-fs-specific `ioctl` as a reference, we are unsure if that would be the correct choice. We presume there are best practices on this matter that we are not currently aware of. Our intention is to upstream this patch if we write it. It would be therefore beneficial to discuss any objections or concerns beforehand. For instance, one possible issue could be overlay-fs usage which presumes that covered up lower layer data is private and inaccessible. To make it possible to preserve that invariant, permissions for this operation would have to be distinct from write permissions. This concern can thus be addressed, but it would increase the scope of the patch. Thanks, John
