9.1-STABLE, live lock up, seems that it is ZFS lockup in zfskern{txg_thread_enter} state tx-tx
Hello, freebsd-fs.
I have 9.1-STABLE (r244958) system, amd64, 8GiB memory.
Two SATA disks, 750Gb each.
Disks are partitoned into 7 (BSD) partitons (exactly the same), 5 of
these pairs are joined into gmirrors for system FSes (UFS2), one
pair is used for swaps and 7th pair is used as zmirror for /usr/home.
Tonight system becomes unusable, as every process which try to read
directories in /usr/home (like ls ~ or find /usr/home -type f)
hangs forever. I could login to system, login shell starts, but if I
run ls right after -- it hangs. Every periodic process, which try
to read home FS (directories, not files!) hangs. It looks, like
stat() calls on this FS hangs, but not open()/read()/write()/close().
One thing I fins suspicious in different system diagnostics, is
kernel thread zfskern{txg_thread_enter} which is shown in state
tx-tx forever.
Disks looks completely OK according to smartd/smartctl, no hardware
errors in dmesg, etc.
===
# zpool status
pool: pool
state: ONLINE
status: The pool is formatted using a legacy on-disk format. The pool can
still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'. Once this is done, the
pool will no longer be accessible on software that does not support
feature
flags.
scan: resilvered 32.1G in 0h34m with 0 errors on Sat Jun 2 16:22:59 2012
config:
NAME STATE READ WRITE CKSUM
pool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ada0s1h ONLINE 0 0 0
ada1s1h ONLINE 0 0 0
errors: No known data errors
--
// Black Lion AKA Lev Serebryakov l...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: About kern.ipc.somaxconn and netstat
On 31/01/2013 4:54 AM, Efraín Déctor wrote: -Mensaje original- From: Kubilay Kocak Sent: Wednesday, January 30, 2013 3:25 AM To: Efraín Déctor Cc: freebsd-stable@freebsd.org Subject: Re: About kern.ipc.somaxconn and netstat On 30/01/2013 12:26 PM, Efraín Déctor wrote: Hello. We have a webserver using FreeBSD, we read about tunning kern.ipc.somaxconn (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html) so the OS can handle all the connections. Is there a way to know how many connections are established in a certain moment?. I know about netstat(1) but is there any other command that we can use to know the exact amount of how many connections are established?. This one might help: kern.ipc.numopensockets: Number of open sockets It's usefulness will depend on the granularity you require (in only, out only, established only, etc) but it's always represented system-wide resource consumption very well (matching observed workloads - some baseline value) Thank you, it is very helpfull, using kern.ipc.numopensockets with sockstat(1) and netstat(1) will give me a clue to tune kern.ipc.somaxconn Thank you all. Also, if you haven't already come across this one in your netstat travels, this one directly reports listen queue overflows: netstat -s -p tcp |grep listen -- Ta, Koobs ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9
On Thu, Jan 17, 2013 at 09:15:02AM -0600, Brooks Davis wrote: Not unless you consider adding new functions in a reserved namespace (str*) to be ABI breakage. Well, what often happens is that when we add new functions, ports break. I think deciding whether this is or is not ABI breakage is semantics. The fact is that regressions get introduced with these types of changes. The port should have continued to work unless it was recompiled so it should have preferred it's own version of the strnvis symbol. If its makefiles were properly constructed it would have failed to compile due to the signature mismatch. The mantra should be every possible combination of ways that a port's internal build glue can be wrong, is already included in the Ports Collection. In case after case we see fragile code that is written by people who are clearly not professionally trained. They get it to work on their system and then shove it out the door. Claiming that they shouldn't do that is correct but self-defeating. It's just the reality of open-source software. IMHO, the burden should be on whoever makes the change to find out whether or not regressions will be introduced. (And yes, I am very aware that we don't have -exp run capability right now, but this is one of the cases where I would like to suggest it would have helped.) mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
