On Sun, Apr 19, 2020 at 07:12:33PM +0300, Amir Goldstein wrote: > On Sun, Apr 19, 2020 at 7:05 PM Eryu Guan <guan@xxxxxxx> wrote: > > > > On Thu, Apr 09, 2020 at 02:29:00PM +0300, Amir Goldstein wrote: > > > When overlayfs index feature is enabled by default in either kernel > > > config or module parameters, this test fails: > > > > > > mount: /tmp/8751/mnt: mount(2) system call failed: Stale file handle. > > > cat: /tmp/8751/mnt/bar: No such file or directory > > > > > > The reason is that with index feature enabled, an upper/work dirs cannot > > > be reused for mounting with a different lower layer. > > > > I re-built my test kernel with CONFIG_OVERLAY_FS_INDEX=y, and confirmed > > /sys/module/overlay/parameters/index is 'Y', but test still passes for > > me. And I do notice the following info in dmesg: > > > > [ 598.663923] overlayfs: fs on '/mnt/scratch/ovl-mnt/up' does not support file handles, falling back to index=off,nfs_export=off. > > [ 598.674299] overlayfs: fs on '/mnt/scratch/ovl-mnt/low' does not support file handles, falling back to index=off,nfs_export=off. > > [ 598.684594] overlayfs: fs on '/mnt/scratch/ovl-mnt/' does not support file handles, falling back to index=off,nfs_export=off. > > > > Seems it has something to do with nfs_export feature? I have it disabled > > by default. > > > > # CONFIG_OVERLAY_FS_NFS_EXPORT is not set > > > > Could you please help confirm? > > > > I confirm. enabling index on nested overlay requires that > the lower overlay has nfs_export enabled. Thanks! > > Missed that, but in the bug report, CONFIG_OVERLAY_FS_NFS_EXPORT > was indeed set. Would you please update the commit log accordingly as well? > > You do not need to rebuild the kernel. > You can reproduce the failure by setting overlay module parameter before > running the tests. > > echo Y > /sys/module/overlay/parameters/index > echo Y > /sys/module/overlay/parameters/nfs_export Ah, forgot about that.. it's easier now :) Thanks, Eryu
