On Thu, Sep 13, 2012 at 02:38:11AM +0900, OGAWA Hirofumi wrote: > "J. Bruce Fields" <bfie...@fieldses.org> writes: > > >> On other view (as server side solution), we are thinking there is > >> possible to make the stable filehandle on FAT if we disabled some > >> operations (e.g. rename(), unlink()) which change inode location in FAT. > >> > >> Yes, it would be stable, but supporting limited operations. > >> > >> This is server side solution, and we comparing it with client solution. > > > > Is that useful to anyone? > > Good question. I'm not sure though, Namjae is asking. And I was asked > about stable read-only export in past. > > >> >> LOOKUP return NFS FH->[inode number changed at NFS Server] -> > >> >> But we still use old NFS FH returned from LOOKUP for any file > >> >> operation(write,read,etc..) > >> >> -> ESTALE will be returned. > >> > >> Yes. And I'm expecting as client side solution, > >> > >> -> ESTALE will be returned -> discard old FH -> restart from LOOKUP -> > >> make cached inode -> use returned new FH. > >> > >> Yeah, I know this is unstable (there is no perfect solution for now), > > > > You may end up with a totally different file, of course: > > > > client: server: > > > > open "/foo/bar" > > rename "/foo/baz"->"/foo/bar" > > write to file > > > > And now we're writing to the file that was originally named /foo/baz > > when we should have gotten ESTALE. > > I see. So, client can't solve the ESTALE if inode cache was evicted, > right? (without application changes)
I don't see how. As another server-side workaround: maybe they could try tuning the inode caching to make eviction less likely? Grepping around... Documentation/sysctl/vm.txt mentions a vfs_cache_pressure parameter. --b. -- 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/
