heavy NFS writes lead to corrup summary in superblock

[Scott Long]

Mikhail Teterin wrote:
> п'ятниця 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?
> 

Do it now, no need to wait for more corruption.  I just want to see what
the block+frag properties are.

> 
>>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 :-/
> 

Still, an unmount should flush everything and not leave you with any 
incorrect information on the filesystem.  I have an app that mounts and 
unmounts NFS filesystems on a frequent basis and does operations on them
that factor down into mmap calls, and I've never seen any problems like
this.  So, I'm very curious and concerned about what you're seeing.

Scott