ZFS: 'checksum mismatch' all over the place

[Pawel Jakub Dawidek]

On Fri, Aug 31, 2007 at 11:04:37PM +0200, Kenneth Vestergaard Schmidt wrote:
> Kenneth Vestergaard Schmidt <kvs at pil.dk> writes:
> >> How do you know it was fine? Did you have something that did
> >> checksumming? You could try geli with integrity verification feature
> >> turned on, fill the disks with some random data and then read it back,
> >> if your controller corrupts the data, geli should tell you this.
> >
> > I may have to do this. The previous drive was almost filled to the brim
> > with data, which rsync looked at each day, and we didn't have a lot of
> > re-transfer, but that doesn't necessarily mean anything.
> 
> *blush*
> 
> This turned out to be a firmware-issue with the Eonstor
> RAID-enclosure. After upgrading to v3.47, everything is fine in the
> checksum-department.
> 
> Now, however, I can't seem to keep the box running. We've rsync'd 1.56
> TB data to an 8.18 TB raidz2 pool, and we're getting panics all the
> time.
> 
> It's an x86 with 4 GB RAM. I've got the following in /boot/loader.conf:
> 
>   vfs.zfs.prefetch_disable="1"
>   vfs.zfs.arc_max="107772160"
>   vm.kmem_size_max="629145600"
>   vm.kmem_size_min="629145600"
> 
> and kern.maxvnodes is set to 50000. When the machine is finished
> booting, 'vmstat -m' says:
> 
>          Type InUse MemUse HighUse Requests  Size(s)
>       solaris 49972 158199K       -   455307  16,32,64,128,256,512,1024,2048,4096
> 
> and after about an hours worth of rsync'ing, we get:
> 
>          Type InUse MemUse HighUse Requests  Size(s)
>       solaris 198797 449675K       - 404226785  16,32,64,128,256,512,1024,2048,4096
>   panic: kmem_malloc(28672): kmem_map too small: 614682624 total allocated
> 
> I'm not quite sure what knobs to twiddle with, or what values to watch,
> so any help in this department would be much appreciated. I'm sure it'd
> be nice to update the Wiki, too, with that info, since the values there
> don't make things stable.

Is this recent HEAD? If so, this may be because of too much metadata
caching in ZFS. This was fixed in ZFS, so now ARC can limit metadata
cache, but this change is not yet in the tree (only in my perforce
branch).

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20070831/6e5807d2/attachment.pgp