On Wed, May 22, 2024 at 4:21 PM Edouard Gaulué <edouard@xxxxxxxxxxxx> wrote: > > Hi Neil, > > Here are 2 remarks regarding: https://docs.kernel.org/filesystems/overlayfs.html > > * 1rst > > We have at the begining: > > Written by: Neil Brown Please see MAINTAINERS file for where to send questions. > > I tried to figure out where that MAINTAINERS file was, looking in overlayfs source code but without luck. I tried to google "overlayfs MAINTAINERS" without success. Hopefully chatGPT leads me to the right place. > https://github.com/torvalds/linux/blob/master/MAINTAINERS#L16875 which also lists the mailing list (now CCed) > * 2nd > > The doc states in Changes to underlying filesystems: > > 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. > > Offline changes, when the overlay is not mounted, are allowed to the upper tree. Offline changes to the lower tree are only allowed if the “metacopy”, “index”, “xino” and “redirect_dir” features have not been used. If the lower tree is modified and any of these features has been used, the behavior of the overlay is undefined, though it will not result in a crash or deadlock. > >From here below the NFS export story is my own blurb. I admit is it hard to understand. I do not consider myself a very good technical writer... > When the overlay NFS export feature is enabled, overlay filesystems behavior on offline changes of the underlying lower layer is different than the behavior when NFS export is disabled. > > On every copy_up, an NFS file handle of the lower inode, along with the UUID of the lower filesystem, are encoded and stored in an extended attribute “trusted.overlay.origin” on the upper inode. > > When the NFS export feature is enabled, a lookup of a merged directory, that found a lower directory at the lookup path or at the path pointed to by the “trusted.overlay.redirect” extended attribute, will verify that the found lower directory file handle and lower filesystem UUID match the origin file handle that was stored at copy_up time. If a found lower directory does not match the stored origin, that directory will not be merged with the upper directory. > > "Offline changes" expression is not really clear or we lack context. I did share it with colleagues and some understood it as: > > changes made while the overlay doesn't exists (is not mounted) > changes made while the overlay is not NFS exported (as the rest of this paragraph is concerned with NFS) It is the first one, as written: "Offline changes, *when the overlay is not mounted*,..." > > Most of the people who think the first is the right solution, don't understand why a change in the lower tree could have an impact on the overlay if it is not mount and so doesn't exist. It will need a new mount command anyway. The meaning is that making changes offline to the lower layers while the overlay is not mounted, will cause undefined behavior after mounting the overlay with those lower layers again. > > According to me, it's due to xattrs that remains in upper tree if “metacopy”, “index”, “xino” or “redirect_dir” have been in use once. Yes, those xattrs refer to the information observed in the lower layer during copy up. If you, for example, delete and recreate a file/dir of the same name in lower layer while overlayfs was offline, then after overlayfs is online again, you may not be able to access the re-created lower file/dir. > Would it be possible to clarify? > Feel free to suggest a different phrasing based on your understand. Submitting a patch to Documentation/filesystems/overlayfs.rst is the preferred format, but if you like to propose a text here that is fine too. Thanks, Amir.
