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