Date: Sun, 22 Aug 1999 15:50:24 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Rob Snow <rsnow@lgc.com> Cc: Doug <Doug@gorean.org>, "John S. Dyson" <dyson@iquest.net>, current@FreeBSD.ORG Subject: Re: Patches available (was Re: NFS HEADS UP) Message-ID: <199908222250.PAA77319@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
:When copying over (FreeBSD client) the multipatch from a Linux (2.2.11)
:box before the patch I got this garbage in the file, -current as of 4am
:this morning. gzip'ed version has bad crc's. Went the other way and it
:worked fine (Linux client), this is v2 via amd.
:
:...
:Update: after reboot with new kernel I get the same thing. It's
:reproducible. It doesn't happen between linux boxen and doesn't happen
:on loopback mounts.
:
:-Rob
Same thing before and after the patch, so the patch itself is not the
problem? Then this is a preexisting bug of some sort.
Hmm. The question is how to focus on the bug. The FreeBSD 'cp' command
uses mmap(). On the linux box 'cp' the file to a different name and then
try using 'cat' on the freebsd client to read it, redirected to a
localfile. Then see if the local file is corrupted. Copy the file to
a different name on the linux box again, and this time use 'cp' on the
freebsd box to see if you get the corruption. ( the act of copying the
file on the linux box to a different name removes any possibility of
it being already-cached on the freebsd client when we run our test ).
linux> cp multipatch-1.diff test1
fbsd> cat <remotelinuxbox>/test1 local1
fbsd> (check for corruption in local1)
linux> cp multipatch-1.diff test2
fbsd> cp <remotelinuxbox>/test2 local2
fbsd> (check for corruption in local2)
If the corruption occurs with 'cp' but not 'cat' then we know it has
something to do with mmap. If it occurs with both commands then the
corruption may be a bug on the linux server.
If you can repeat the corruption using the above test the next step is
to try to determine whether the bug is in the linux server or the freebsd
client. I kinda suspect the linux box because there are no cache
interaction issues w/ the freebsd box if the client is simply reading the
file.
-Matt
Matthew Dillon
<dillon@backplane.com>
:+ if (vp->v_object &&
:+ (vp->v_object->flags & OBJ_MIGHTBEDIRTY)) {
:
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
:^@^@^@^@^@^@^@^@requested range. Note: we are assuming that
:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908222250.PAA77319>