On Tue, 15 Jan 2013 13:34:07 -0600
Steve French <smfrench@xxxxxxxxx> wrote:
> On Tue, Jan 15, 2013 at 1:01 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> > We've had a long-standing problem with DFS referral points. CIFS servers
> > generally try to make them look like directories in FIND_FIRST/NEXT
> > responses. When you go to try to do a FIND_FIRST on them though, the
> > server will then (correctly) return STATUS_PATH_NOT_COVERED. Mostly this
> > manifests as spurious EREMOTE errors back to userland.
>
> Why would we ever return STATUS_PATH_NOT_COVERED (converted to
> EREMOTE)? If we do a find first on a directory and get status path
> not covered - why don't we simply chase the DFS referral then rather
> than greatly slow down findfirst?
>
Note that I marked this RFC since I'm not 100% sold on the approach...
This doesn't slow down FIND_FIRST, it just means that we revalidate the
inode before trying to use it. The scenario goes something like this:
Suppose we have a share like this:
//server/share
...and under the top level of that share is a DFS referral "dfslink".
Now, we go and do a readdir on the top level directory and that causes
a FIND_FIRST to go out on the wire. The response has "dfslink" in it,
but it looks just like a directory. So, we instantiate a new dentry for
it with a directory inode, based on the info in the FIND_FIRST response.
Now, we go to try and do a readdir() on "dfslink". We do an opendir()
which doesn't cause any sort of call to go out onto the wire because we
just instantiated the dentry. So, we end up doing a FIND_FIRST
against //server/share/dfslink, and get back STATUS_PATH_NOT_COVERED.
This patch fixes that by forcing the client to revalidate the dentry at
lookup time (i.e. when the directory is opened in the above example).
The lookup will be redone (via QPathInfo) and we'll end up chasing the
referral as expected.
--
Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
