Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Jun 2006 14:58:46 -0400
From:      Mikhail Teterin <mi+mx@aldan.algebra.com>
To:        Scott Long <scottl@samsco.org>
Cc:        fs@freebsd.org
Subject:   Re: heavy NFS writes lead to corrup summary in superblock
Message-ID:  <200606091458.46504.mi%2Bmx@aldan.algebra.com>
In-Reply-To: <4489C0B5.3010902@samsco.org>
References:  <20060609065656.31225.qmail@web30313.mail.mud.yahoo.com> <200606091333.42619.mi%2Bmx@aldan.algebra.com> <4489C0B5.3010902@samsco.org>

next in thread | previous in thread | raw e-mail | index | archive | help
п'ятниця 09 червень 2006 14:40, Scott Long написав:
> Well, before we get too far off on tangents, would you mind running
> dumpfs on the filesystem and posting the first block of information?

Do you want this now, or when/if I see the corruption again?

> It's hard to beleive that NFS would be responsible for corrupting the 
> filesystem.  You should be able to have a consistent and correct unmount
> regardless of whether NFS is in use or what options it is using.

The other potential "oddity" is that the files are eagerly awaited (via
kevent()) by a process running on my NFS server, which mmaps the freshly
written chunks (as soon as kevent() returns) and compresses them onto
another filesystem. It looks like this:

20060609:14:53:03: mzip: the input size grew from 201031680 to 201064448. Ok...
20060609:14:53:03: mzip: mmap-ing 32768 bytes of /staging/gonzo:4100/TD_THEIR_211-060609-145243.dmp (201064448) starting at 201031680
20060609:14:53:03: mzip: eaten: 32768 of 32768, produced 0
20060609:14:53:03: mzip: Unmapping 32768 bytes starting at 0x80052c000

As soon as the dump is over, and the last portion of it is compressed,
the dump is deleted. None of this should be causing the corruption I
observed a few times, but any of it could, for it is all mildly unusual :-/

Yours,

	-mi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200606091458.46504.mi%2Bmx>