Hi, In light of the recent discussion about ZFS stability, does anyone still = have kmem_map_too_small panics on AMD64 after tuning it (as presented in = http://wiki.freebsd.org/ZFSTuningGuide)? I'm interested in reports like this:=20 http://kerneltrap.org/mailarchive/freebsd-current/2007/9/21/271557 (note = that this report is for an untuned system).

Would having the option to specify the JID one wants for a jail that's launching solve this ? Regards, Hugo _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

I have 3 amd64 systems & an i386 system (workstation) using ZFS; I've seen panics related to ZFS only on the i386 machine as expected. (Not to mention it's still -CURRENT from months ago :)) The amd64 servers are a home server (with jails hosted on ZFS), and two servers in Canada. Of these two, one is also a jail server (one of the jails is a mail server that'll be fairly loaded when it goes live) and the other is a backup server (still not in production). The most I've thrown at...

Yes, I've had one such crash. The machine has 4GB of RAM and initially I set it up with vm.kmem_size and vm.kmem_size_max set to 1024M. It's my home fileserver and I'm the only regular user. After booting the box I had tested the transfer speed back and forth over the net and after that not really used it any more that day. The next day I discovered that it had crashed sometime during the night. I've since changed the two tuneables above to 1536M and I've not had any crashes since. I also tri...

ny of=20 This is somewhat a special case - you also did tuning besides kmem size. = I'm especially interested in this, hoping to gather the "combination=20 that works" from the reports.

hi, i found strange problem with working ssh on server: gr login failures: Jan 4 08:21:57 gr sshd[16218]: Received disconnect from 193.125.78.113: 2: Bad packet length 1626711409. Jan 4 08:35:37 gr sshd[16254]: Received disconnect from 77.123.194.155: 2: Bad packet length 236618258. what is it and what should i fix? FreeBSD gr.holydns.com 7.0-BETA4 FreeBSD 7.0-BETA4 #0: Wed Dec 5 01:12:18 UTC 2007 dexx@gr:/usr/obj/usr/src/sys/GR amd64 -- *#) _____________________________________...

If you have bcmwl5_sys_load in your loader.conf, this is causing the 32bit driver to load at boot, bcmwl563_sys_load needs to be placed in loader.conf for the 64 bit driver. To boot your system without the rescue CD, at the boot menu choose "Escape to loader prompt". Then use "unload" to unload all modules, and "unset bcmwl5_sys" to disable loading of the bcmwl5_sys module. Finally, use "boot" to continue booting. When the system has finished booting, check /boot/loader.conf, does it have bcmwl...

Last I heard, rsync didn't crash Solaris on ZFS :)

I can't provide citation about a thing that doesn't happen - you don't=20 hear things like "oh and yesterday I ran rsync on my Solaris with ZFS=20 and *it didn't crash*!" often. But, with some grains of salt taken, consider this Google results: * searching for "rsync crash solaris zfs": 790 results, most of them=20 obviously irrelevant * searching for "rsync crash freebsd zfs": 10,800 results; a small=20 number of the results is from this thread, some are duplicates, but it's = a large numbe...

Almost all Solaris systems are 64 bit. Kris _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

JFWIW - last night's trial OpenSolaris/Indiana' devel iso installed on Core-2 duo with 2GB created something it reported as 'Z-lite) (IIRC - it wasn;t worht wasting HDD space on...) Anyone know if this 'different' on Solaris for i386 from -64? i.e. - is do Sun use a 'lite' and full' version? And, if so, [is there | should there be ] an equivalent in the FreeBSd world? or Clearly so. So much so that IMNSHO, inclusion of most *remaining* ZFS issues more properly belongs on the ZFS-sp...

None are perfect. But ZFS is just *too* new. And not just on *BSD. If IBM had not already had GPFS, Sun might never even have 'invented' ZFS. The 'other' ones with the longest 'history' - where known-problems have knwon avoidance/workaround, may well be XFS and JFS. Heavy-lifters iwht commercial track-records, both. Not to mention UFS... I'm still in the practice of 'slicing' into 50 GB or so - 100GB max - no matter *what* the drive size is. So where's the 'beef'? Half-terabyte *file...

I guess what makes me mad about ZFS is that it's all-or-nothing; either it works, or it crashes. It doesn't automatically recognize limits and make adjustments or sacrifices when it reaches those limits, it just crashes. Wanting multiple gigabytes of RAM for caching in order to optimize performance is great, but crashing when it doesn't get those multiple gigabytes of RAM is not so great, and it leaves a bad taste in my mouth about ZFS in general. Scott ________________________________________...

Scott Long wrote: To be fair - every fs on the planet had to go through this at one time or another. We have been perhaps 'spoiled' by the odd runaway log or such that has pushed UFS to over 103% 'full', struggled on regardless, allowing us to ssh in from 12,000 miles away, kill the offender, clean up the mess, and soldier-on w/o even a reboot, let alone a crash. ZFS will (probably) get there one day as well. But at present, it has become a distraction we don't need. We're chasing pro...

Solaris nowadays refuses to install on anything without at least 1 GB of = memory. I'm all for ZFS refusing to run on inadequatly tuned hardware,=20 but apparently there's no algorithmic way to say what *is* adequately=20 tuned, except for "try X and if it crashes, try Y, repeat as necessary". The reason why I'm arguing this topic is that it isn't a matter of=20 tuning like "it will run slowly if you don't tune it" - it's more like=20 "it won't run at all if you don't go through the laborious=20...

Citation needed. I'm interested.

Thanks for the pointer. I'm looking at the archives. So far I've found this:=20 http://www.archivum.info/zfs-discuss@opensolaris.org/2007-07/msg00016.htm= l=20 which doesn't mention panics; and this:=20 http://www.archivum.info/zfs-discuss@opensolaris.org/2007-07/msg00054.htm= l=20 which didn't get any replies but the backtrace doesn't include anything=20 resembling a malloc-like call.

It's not generally true since kmem problems with rsync are often hard to repeat - I have them on one machine, but not on another, similar Mostly. I did have a ZFS crash with rsync that wasn't kmem related, but only once. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

I encounter 2 times a deadlock during high I/O activity (the last one during rsync + rm -r on a 5GB hierarchy (openoffice-2/work). I was running with this patch: http://people.freebsd.org/~pjd/patches/zgd_done.patch db> show allpcpu Current CPU: 1 cpuid = 0 curthread = 0xa5ebe440: pid 3422 "txg_thread_enter" curpcb = 0xeb175d90 fpcurthread = none idlethread = 0xa5529aa0: pid 12 "idle: cpu0" APIC ID = 0 currentldt = 0x50 cpuid = 1 curthread = 0xa5...

I add it to my kernel config I do this after the second deadlock and arc_reclaim_thread was always there and second cpu was idle. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

I agree that ZFS is pretty stable itself. I use 32bit machine with 2gigs od RAM and all hang cases are kmem related, but the fact is that I haven't found any way of tuning to stop it crashing. When I do some rsyncing, especially beetwen different pools - it hangs or reboots - mostly on bigger files (i.e. rsyncing ports tree with distfiles). At the moment I patched the kernel with vm_kern.c.2.patch and it just stopped crashing, but from time to time the machine looks like beeing freezed for a second...

As Ivan said - tuning kmem_size only delay the moment system crash, You're right - I turned debugging off, because it's not a production machine and I can afford such behaviour. Right now, using kernel with kmem patch applied it's ,,usable''. -- regards, Maciej Suszko. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

I was playing around with kmem_max_size mainly. I suppose messing up with KVA_PAGES is not a good idea unless you exactly know how much memory you software consume... -- regards, Maciej Suszko. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

That's an assertion directly contradicted by my experience running a heavily loaded 8-core i386 package builder. Please explain in detail the steps you have taken to tune your kernel. Do you have the vm_kern.c patch applied? > See also the possibility > of deadlocks in the ZIL, reported by some users. Yes, this is an outstanding issue. There are a couple of others I run I am not set up to test this right now. Kris _______________________________________________ freebsd-c...

No, clearly it is not enough (and you claimed previously to have done more tuning than this). I have it set to 600MB on the i386 system with ZFS already tells you up front that it's experimental code and likely to have problems. Users of 7.0-RELEASE should not have unrealistic Perhaps, but that only applies to 7.0-RELEASE. Kris _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To uns...