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