Messages in this thread | | | Subject | Re: [PATCH 0/4] fat: fix ESTALE errors | From | "Steven J. Magnani" <> | Date | Tue, 21 Aug 2012 08:20:36 -0500 |
| |
On Mon, 2012-08-20 at 16:52 -0400, J. Bruce Fields wrote:
> Fo somebody that knows more about fat than me--is there really any hope > of making it play well with nfs?
I spent a lot of time looking into FAT ESTALE issues and had proposed something similar to Namjae (https://lkml.org/lkml/2012/7/3/378). In the discussions and experiments that followed, I eventually came to the conclusion that the best I could do was make FAT play "better" with NFS (https://lkml.org/lkml/2012/7/10/252).
If you define "well" as an absence of server-reported ESTALE due purely to inode/dentry cache eviction I'm skeptical that this is possible in any way that would be accepted into the mainline kernel. Code that addresses ESTALE on the client side (https://lkml.org/lkml/2012/8/8/244) seems to be successful, but since not everyone has control of the client code there are cases where a server-side solution is desirable.
There's just no unique way to identify FAT inodes that works across all the possible scenarios (renames, power cycles, zero-length files, deletion of an object and creation of another - potentially of a different type - at the same on-disk position, etc.). Also, clients are sensitive to changes in a file handle - any server "reconstitution" of an evicted inode must result in a NFS file handle that is identical to the "original" reported to the client, or the client will cry ESTALE despite the server's best efforts.
------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!"
#include <standard.disclaimer>
| |