On Sun, 31 Jul 2011, Dan Nelson wrote:
In the last episode (Aug 01), Dmitry Morozovsky said:
just noticed that contemporary nfsd does not fork children in accordance
to -n setting:
stable/8:
root@beaver:/usr/local/tb/scripts# pid nfs
1745 ?? Is 0:00.02 nfsd: master (nfsd)
The first BETA build of the 9.0-RELEASE release cycle is now available.
Since this will be the first release on a brand new branch I'll
cross-post the announcements on both -current and -stable. But just
so you know most of the developers active in head pay more attention
to the -current mailing
A server just all of a sudden dropped from the network.
uptime was 26days.
This got my ZFS server hanging:
Aug 1 23:39:58 zfs kernel: em0: Watchdog timeout -- resetting
Aug 1 23:39:58 zfs kernel: em0: Queue(0) tdh = 942, hw tdt = 977
Aug 1 23:39:58 zfs kernel: em0: TX(0) desc avail = 985,Next
On Mon, Aug 01, 2011 at 11:20:35AM +0700, Eugene Grosbein wrote:
01.08.2011 09:39, Jason Hellenthal ?:
What line of the newsyslog.conf file is your line inserted and can you
move that to a higher line number. FIFO
I don't get why position of line in newsyslog.conf can have any
On Mon, Aug 01, 2011 at 11:20:35AM +0700, Eugene Grosbein wrote:
01.08.2011 09:39, Jason Hellenthal ?:
What line of the newsyslog.conf file is your line inserted and can you
move that to a higher line number. FIFO
I don't get why position of line in newsyslog.conf can have any
On Tue, Aug 02, 2011 at 12:27:57AM +0200, Willem Jan Withagen wrote:
A server just all of a sudden dropped from the network.
uptime was 26days.
This got my ZFS server hanging:
Aug 1 23:39:58 zfs kernel: em0: Watchdog timeout -- resetting
Aug 1 23:39:58 zfs kernel: em0: Queue(0) tdh =
Do you happen to run nfs on the server?
I had weird problems with igb-timeouts when many nfs-reads occured and a down
and up on the interface would restore the network connection for a while. I had
vmware-servers on a nfs-share and either when booting or installing programs
from windows
Running the same example on amd64 has the same behavior as on i386 (granted
the backtrace is slightly different).
That is, the kernel panics immediately when you use the ustack() action.
Furthermore, the crashdump does not provide the nececcary information to get
at the root of the cause (i.e.,
Hi!
It seems, I've found a bug in the ZFS v28 on the latest stable:
if we have a snapshot with some files having an extended attributes,
then attempt to read an extended attributes's value leads to a well
reproducible kernel panic.
The part of backtrace follows:
#6 0x804bbe44 in
