"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) -- 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/
