Date: Sat, 4 Dec 1999 12:51:59 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Dan Nelson <dnelson@emsphone.com> Cc: current@FreeBSD.ORG Subject: Re: NFS client zeroing out blocks on write? Message-ID: <199912042051.MAA56920@apollo.backplane.com> References: <19991203112518.A43843@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:I just upgraded a server from 2.2.8 to -current (991201 kernel) and am
:seeing some NFS corruption. It looks like byte ranges are getting
:zeroed out by the client (or not getting written at all, and the server
:at the other end is filling with zeros?). I've seen it while writing
:to both a Solaris 2.6 server (NFSv3) and a Netware NFS server (NFSv2),
:so I'm pretty sure it's the client causing the problem.
Hmm. I thought we had fixed all the zeroing problems. Are you sure
you compiled your current up from the latest source?
I am presuming there are no other clients accessing the output files
while the split is running?
Also, change your blankcheck program to display the ranges in hex,
doing so brings to light the pattern.
: fileaa
: fileab
: 168173568-168179199(5632) A062000-A063FFF
: 384966656-384972287(5632) 16F22000-16F235FF
Interesting. It looks very similar to a problem we fixed months ago.
That problem was related only to NFSv3 and mmap(), and you aren't using
mmap() here. It's disturbing to see this problem occur with both NFSv2
and NFSv3.
I wonder if the problem occurs between a FreeBSD client and server.
-Matt
Matthew Dillon
<dillon@backplane.com>
:All the zeroed out blocks start on an 8k NFS boundary, and I have
:verified that the rest of the 8k block has the correct data in it.
:Each corrupted block is always a multiple of 512 bytes long (so far
:multiples are 6, 7, 11, and 12).
:
:On this example run, each file either has no corruption at all, or has
:corruption with all the zeroed out ranges the same size. Dunno if this
:matters, but it's interesting.
:
:If I run without nfsiod, or copy from a remote NFS mount to a remote
:NFS mount, the corruption goes way down but still happens. I got only
:one corrupted block in my 7-gig test run in each of those test cases.
:
:I'm afraid I don't know much about the internal workings of NFS, so I'm
:hoping my description is enough to pinpoint the problem.
:
:--
: Dan Nelson
: dnelson@emsphone.com
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?199912042051.MAA56920>