ZFS and disk naming change (ex. da0->da4)

Attila Nagy bra at fsn.hu
Thu Oct 25 05:45:08 PDT 2007


On 10/24/07 17:57, Pawel Jakub Dawidek wrote:
> ZFS caches components names in /boot/zfs/zpool.cache. You may remove
> this file and import the pool again.
>   
Pawel, thanks for the quick answer.

On the same machine I do an rsync from another machine. The first run 
went OK, but the next (incremental, both sides contain nearly the same 
amount of stuff) ones result in a panic:
rsync -va --progress --delete root at 192.168.1.1:/home/cyrus/spool/ 
/people/mail/var/spool/imap/
receiving file list ...
586728 files to consider
 169500 files... (crash)

There are bigger and smaller files in many directories. There are 
mid-sized directories with several thousands of small files (40-50000), 
because this is a cyrus (maildir-like) mailspool.

The target machine (which crashes) is:
uname -a
FreeBSD artax 7.0-BETA1 FreeBSD 7.0-BETA1 #1: Thu Oct 25 09:10:32 CEST 
2007     root at artax:/usr/obj/usr/src/sys/ARTAX  i386

The machine has only 1G RAM, the ZFS and other kmem related settings are 
left on their default values.
Unread portion of the kernel message buffer:
panic: kmem_malloc(131072): kmem_map too small: 335319040 total allocated
cpuid = 0
Uptime: 18m22s
Physical memory: 1015 MB
Dumping 372 MB: 357 341 325 309 293 277 261 245 229 213 197 181 165 149 
133 117 101 85 69 53 37 21 5

#0  doadump () at pcpu.h:195
195             __asm __volatile("movl %%fs:0,%0" : "=r" (td));

I've tried to lower vfs.zfs.arc_max first to 32, then 16 MB, but the 
panics still occur.

Setting
vm.kmem_size="500M"
vm.kmem_size_max="500M"
in loader.conf helps it to survive the rsync run, but I think it would 
be better not to have this kind of instability on an out of the box OS...

How is this problem solved in Solaris?

-- 
Attila Nagy                                   e-mail: Attila.Nagy at fsn.hu
Free Software Network (FSN.HU)                 phone: +3630 306 6758
http://www.fsn.hu/



More information about the freebsd-fs mailing list