Namjae Jeon <linkinj...@gmail.com> writes: >>> I think that it is unfixable because we can not know i_pos of inode >>> changed by rename. >>> And even though we know it, there is no rebuild inode routine in -mm. >>> And It even can not fix in our patches. >> >>>> And are you tried https://lkml.org/lkml/2012/6/29/381 patches? It sounds >>>> like to improve performance by enabling lookupcache. >>> We checked this patches when facing estale issue in -mm. >>> But It is no use, these patches just retry system call one more when >>> estale error. >> >> What happens if client retried from lookup() after -ESTALE? (client NFS >> doesn't have the name of entry anymore?) > Need to rebuild inode routine because inode cache is already evicted on > Server. >> >> I'm assuming the retry means - it restarts from building the NFS file >> handle. I might be just wrong here though. > As I remember, just retry in VFS of NFS client..I heard this patch is > needed for > a very specific set of circumstances where an entry goes stale once > between the lookup and the actual operation(s). > It is not related with current issues(inode cache eviction on server).
Supposing, the server/client state is after cold boot, and client try to rename at first without any cache on client/server. Even if this state, does the server return ESTALE? If it doesn't return ESTALE, I can't understand why it is really unfixable. If it returns ESTALE, why does it return? I'm assuming the previous code path is the cached FH path. -- OGAWA Hirofumi <hirof...@mail.parknet.co.jp> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
