lkml.org 
[lkml]   [2012]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 0/4] fat: fix ESTALE errors
On Tue, Aug 21, 2012 at 6:50 PM, Steven J. Magnani
<steve@digidescorp.com> wrote:
> 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).
>

We had initially tried both spins of Steve's patches for our test
scenario (ls -lR on the client, while continually doing a drop_caches
on the server) but still got ESTALE errors on the client. Since
Steve's v2 patch set got accepted, we tried to build on top of that.

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

We thought we got it right until the 'orphaned inode' flaw was pointed
out. At the expense of exposing my ignorance,could some one give me a
hint on what what would happen if there were writes continually to
two files- (i) one unlinked but still referenced by an open file
descriptor and (ii) the other one newly created but assigned the same
inode number(by virtue of this patch-set) on a FAT disk? From what I
tested, the writes to the first (zombie) file did not affect the
integrity of the contents of the second file and were in fact 'rolled
back' when the file descriptor was closed.Apparently, I'm missing
something here.

Thank you.

> 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

--
.-. .- ...- ..


\
 
 \ /
  Last update: 2012-08-21 20:41    [W:0.082 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site