On Wed, Sep 19, 2012 at 05:13:03PM -0700, Simon Kirby wrote: > On Wed, Sep 12, 2012 at 02:20:35PM -0700, Simon Kirby wrote: > > > On Wed, Sep 12, 2012 at 08:16:13AM -0400, J. Bruce Fields wrote: > > > > > The symptoms sound similar to > > > http://marc.info/?l=linux-fsdevel&m=134738157303017&w=2 > > > > > > Might be worth checking whether it's that patch? > > > > Indeed! I tried this hack: > > > > diff --git a/fs/dcache.c b/fs/dcache.c > > index 8086636..649a112 100644 > > --- a/fs/dcache.c > > +++ b/fs/dcache.c > > @@ -2404,6 +2404,10 @@ out_unalias: > > if (likely(!d_mountpoint(alias))) { > > __d_move(alias, dentry); > > ret = alias; > > + } else { > > + printk(KERN_WARNING "VFS: __d_move()ing a d_mountpoint(), uh oh\n"); > > + __d_move(alias, dentry); > > + ret = alias; > > } > > out_err: > > spin_unlock(&inode->i_lock); > > > > With this applied, "ls -l flick" prints: > > > > [ 77.217420] VFS: __d_move()ing a d_mountpoint(), uh oh > > [ 77.222390] VFS: __d_move()ing a d_mountpoint(), uh oh > > > > ...and "pics" and "raid" then work as they did before, or with "nordirplus" > > set. So, is something broken with nordirplus or the NFS layer, or should > > __d_unalias() really move a mountpoint? With nordirplus, it works without > > complaining about moving a mountpoint. > > By the way, This seems fixed in 3.6-rc6, likely due to > c3f52af3e03013db5237e339c817beaae5ec9e3a. Thanks! I confused myself with my own patch here. This still happens to me in release 3.6, making it not possible for me to use these NFS mounts unless I set "nordirplus" or apply my above call-__d_move-anyway patch. I'm also getting file data corruption when mounted TCP, for some stupid reason, even with all TSO/GSO/GRO disabled, and this goes away with UDP. Reproducible on different client hardware, and on client kernels back to 2.6.32. Probably related to the 3.4.1 server. More debugging to do... Simon- -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
