On Tue, 2021-03-30 at 00:48 +0000, Al Viro wrote: > In nfs_lookup() we have > /* > * If we're doing an exclusive create, optimize away the > lookup > * but don't hash the dentry. > */ > if (nfs_is_exclusive_create(dir, flags) || flags & > LOOKUP_RENAME_TARGET) > return NULL; > OK, fair enough - we don't need to find out whether it's negative or > not for > mkdir() et.al.; if it isn't, server will tell us to sod off and we > can live > with not having it in cache - in the worst case, we'll have to do the > same > lookup we'd skipped here at some later point. Same for rename(2) > destination - > if it wasn't in dcache, we are not going to bother with sillyrename > anyway, and > that's the only thing where we might care about the destination. If > rename(2) > succeeds, we won't see whatever had been there anyway, and if it > fails, we won't > lose anything from having lookup done later. > > What I don't get is why, unlike rename(2) target, mkdir(2) > argument is > handled that way only for v3 and later. It's been a long time since > I looked > at NFSv2 servers, but shouldn't we get NFSERR_EXIST if the sucker > turns out to > have already been there? > > What am I missing? The check for NFS version > 2 is mainly there for the case of CREATE, which does not have an exclusive create mode in NFSv2. IOW: I believe we can indeed rely on LINK, MKDIR, and RENAME returning NFSERR_EXIST, but not the more common case of CREATE. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
