NFS Insanity, v2

NFS Insanity, v2

[Christian Robottom Reis]

Hooray. Or rather, darn. I managed to reproduce the bug again. And now I
even have what I think might be a testcase model. Numbers:  raid-1,
reiserfs, nfs-utils 0.3.1, linux-2.4.5-pre4 now with no extra patching
(well, does iptables-patches count?). fstab line:

anthem:/mondo   /mondo  nfs defaults,rsize=3072,wsize=3072,suid,async 0 0

exports line:

/mondo      foo.bar.com.br(no_root_squash,rw)

Every day at the same time I pull mozilla-latest through http, and untar
it into a directory that is served by nfs. The file isn't too big - around
9MB. It creates a set of files inside /mondo/local/mozilla. One of the
files (same one for some reason), components/libgkcontent.so, always ends
up corrupted on the client side. There is no server-side corruption.

Remounting (and thus rebooting) the client mount gets things back to
normal. Anyone willing to track this down with me? Or is it something
known (and being worked on, hopefully)?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [NFS] NFS Insanity, v2

[Trond Myklebust]

>>>>> " " == Christian Robottom Reis <kiko@async.com.br> writes:

     > Every day at the same time I pull mozilla-latest through http,
     > and untar it into a directory that is served by nfs. The file
     > isn't too big - around 9MB. It creates a set of files inside
     > /mondo/local/mozilla. One of the files (same one for some
     > reason), components/libgkcontent.so, always ends up corrupted
     > on the client side. There is no server-side corruption.

     > Remounting (and thus rebooting) the client mount gets things
     > back to normal. Anyone willing to track this down with me? Or
     > is it something known (and being worked on, hopefully)?

Is libgkcontents.so in use on the client? If so it's a known problem:
mmap() screws up the page cache invalidation routine
invalidate_inode_page(). If you do the untar on the client, then all
will be fine...

However the last time your report was of a problem in which the server
was corrupted, and the client was good. Was that a typo, or is it
still the case?

Cheers,
  Trond

Re: [NFS] NFS Insanity, v2

[Christian Robottom Reis]

On 23 Jun 2001, Trond Myklebust wrote:

> Is libgkcontents.so in use on the client? If so it's a known problem:
> mmap() screws up the page cache invalidation routine
> invalidate_inode_page(). If you do the untar on the client, then all
> will be fine...

Hah! Yeah, you're right; both times it happened because mozilla was
running at the time. I can't have it untarred on the client because the
client isn't on every day. It's a minor nuisance now that I've understood
it.

Is there a fix in the works for this?

> However the last time your report was of a problem in which the server
> was corrupted, and the client was good. Was that a typo, or is it
> still the case?

Possible typo. I did the diff on the server so perhaps I gave the
impression the problem was there, and it wasn't.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [NFS] NFS Insanity, v2

[Trond Myklebust]

>>>>> " " == Christian Robottom Reis <kiko@async.com.br> writes:

     > On 23 Jun 2001, Trond Myklebust wrote:
    >> Is libgkcontents.so in use on the client? If so it's a known
    >> problem: mmap() screws up the page cache invalidation routine
    >> invalidate_inode_page(). If you do the untar on the client,
    >> then all will be fine...

     > Hah! Yeah, you're right; both times it happened because mozilla
     > was running at the time. I can't have it untarred on the client
     > because the client isn't on every day. It's a minor nuisance
     > now that I've understood it.

     > Is there a fix in the works for this?

There are workarounds, but Linus isn't particular happy with
them. It's therefore unfortunately still work in progress...

Cheers,
   Trond