> Does this maybe ring a bell with someone?
Update: The cause of the problem was
OpenSolaris bug 6826836 "Deadlock possible in dmu_object_reclaim()
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6826836
It could be fixed by upgrading the OpenSolaris 2009.06 system to
0.5.11-0.111.17
> I'm not very familar with mdb. I've tried this:
Ah, this looks much better:
root 641 0.0 0.0 7660 2624 ?S Nov 08 2:16 /sbin/zfs receive
-dF datapool/share/ (...)
# echo "0t641::pid2proc|::walk thread|::findstack -v" | mdb -k
stack pointer for thread ff09236198e0: f
> I'm wondering if #6975124 could be the cause of my problem, too.
there are several zfs send (and receive) related issues with 111b. You might
seriously want to consider upgrading to more recent opensolaris (134) or
openindiana
Yours
Markus Kovero
_
Does anyone know the current state of bug #6975124? Has there been any progress
since August?
I currently have an OpenSolaris 2009.06 snv_111b system (entire
0.5.11-0.111.14) which *repeatedly* gets stuck after a couple of minutes during
a large (xxx GB) incremental zfs receive operation. The p
Andrew,
Correct. The reason I initially opened the case was because I could
essentially hang a "zfs receive" operation and any further zfs commands issued
on the box would never come back. Just today I had one of my "slow" receives
just come to a screaching halt and where I saw 1 cpu spike al
Jim Barker wrote:
Just an update, I had a ticket open with Sun regarding this and it looks like
they have a CR for what I was seeing (6975124).
That would seem to describe a zfs receive which has stopped for 12 hours.
You described yours as slow, which is not the term I personally would
us
Just an update, I had a ticket open with Sun regarding this and it looks like
they have a CR for what I was seeing (6975124).
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.or
I have been looking at why a zfs receive operation is terribly slow and one
observation that seemed directly linked to why it is slow is that at any one
time one of the cpus is pegged at 100% sys while the other 5 in my case are
relatively quiet. I haven't dug any deeper than that, but was curi
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Thomas Maier-Komor
>
> you can probably improve overall performance by using mbuffer [1] to
> stream the data over the network. At least some people have reported
> increased performance. mbuff
On 25.06.2010 14:32, Mika Borner wrote:
>
> It seems we are hitting a boundary with zfs send/receive over a network
> link (10Gb/s). We can see peak values of up to 150MB/s, but on average
> about 40-50MB/s are replicated. This is far away from the bandwidth that
> a 10Gb link can offer.
>
> Is i
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Mika Borner
>
> It seems we are hitting a boundary with zfs send/receive over a network
> link (10Gb/s). We can see peak values of up to 150MB/s, but on average
> about 40-50MB/s are replicated
It seems we are hitting a boundary with zfs send/receive over a network
link (10Gb/s). We can see peak values of up to 150MB/s, but on average
about 40-50MB/s are replicated. This is far away from the bandwidth that
a 10Gb link can offer.
Is it possible, that ZFS is giving replication a too
12 matches
Mail list logo
