On Mon, 23 May 2011 09:02:55 -0500 Steve French <smfrench@xxxxxxxxx> wrote: > On Mon, May 23, 2011 at 8:50 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Mon, 23 May 2011 08:42:39 -0500 > > Steve French <smfrench@xxxxxxxxx> wrote: > > > >> On Mon, May 23, 2011 at 6:12 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > >> > On Sun, 22 May 2011 20:12:04 -0500 > >> > Steve French <smfrench@xxxxxxxxx> wrote: > >> > > >> >> On Sun, May 22, 2011 at 7:17 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > >> >> > On Sun, 22 May 2011 07:59:38 -0400 > >> >> > Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > >> >> > > >> >> >> On Sun, May 22, 2011 at 07:55:24AM -0400, Jeff Layton wrote: > >> >> >> > This will never work properly with CIFS, as the protocol has no ability > >> >> >> > whatsoever for looking up files by filehandle. It *might* be possible to > >> >> >> > eventually do this with SMB2, but that remains to be seen. > >> > >> Shirish had done some experiments (and AFAIK has a small patch > >> that fixed NFS export over CIFS which works, with the usual restrictions > >> about having to return ESTALE if the NFS client tries to access > >> an inode which has been flushed from the cache on the server side). > >> > > > > That restriction is not usual for servers, and makes the whole scheme > > unreliable. > > It must be reasonably common - as it was one of the motivations for > ESTALE return code, and was a motivation for the explicit "volatile > file handle" type that was introduced in nfs v4 (which makes it easier > for the client to tell when it has to be able to revalidate a file > handle). I see mention of this in Solaris, Oracle so it is presumably > fairly common. > It's not common on a properly working or implemented server. There are corner cases that can cause it to occur -- basically ESTALE is the server's way of saying "I don't recognize this filehandle". For cifs though, it's a real problem since you'll have no way to look up the filehandle if it doesn't happen to be in the cache. > >> >> For nfs v3 clients that can't handle ESTALE, we are probably > >> >> stuck with having to wait for Samba to implement the flag > >> > Flag? > >> > >> NTCreateX: ÂFILE_OPEN_BY_FILE_ID > >> > >> IIRC Shirish verified that the Windows client will emit this flag, but their > >> server had not gotten around to implementing it (although Samba could > >> implement it now that their is an open-by-handle syscall). > >> > > > > Again, that does absolutely nothing for directories which also need to > > be retrievable by filehandle. > > Why wouldn't that work? Samba and Windows both support opening > directories - why wouldn't queryfileinfo work on those handles? > QueryFileInfo might work. FIND_FIRST/NEXT won't. > > > I think it would be best to remove this code, but if that's > > unacceptable for some reason it should at least be marked BROKEN. > > if Shirish's patch can't (or doesn't) make it work I agree that it > should be removed or marked broken - but I have not tested his patch. > > I've not seen this patch so I can't comment. I remain very, very skeptical though without a solution that works for directories. A server that works only under specific, difficult to predict conditions is worse than useless. -- 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
