search for: txg_wait_open

...19) stack pointer for thread 3000351b620: 2a101f864b1 Which is ok. However all the other threads (650 of them) were in cv_wait: bash-3.00# cat nfsd.txt | grep -c "nfssys+" 650 bash-3.00# cat nfsd.txt | grep -c "cv_wait+" 651 bash-3.00# bash-3.00# cat nfsd.txt | grep -c "txg_wait_open+" 360 bash-3.00# cat nfsd.txt | grep "txg_wait_open+" | grep -c "337d1e" 360 So all those txg_wait_open are for the same transaction group - txg_wait_open+0x58(6000ad0c910, 337d1e, All the other threads were in: bash-3.00# cat nfsd.txt | grep -c "zfs_range_lock_rea...

Hi zfs-discuss, I have some questions about throttling on ZFS 1) I know that throttling is activating while one sync is waiting for another. (http://blogs.sun.com/roller/page/roch?entry=the_dynamics_of_zfs) Is it possible to throttle only selected processes (e.g. nfsd) ? 2) How can I obtain some statistics about it? I want to know how often throttling is activating on my host etc. 3) Is it

...uot;zfs mount space" works fine, but "zfs mount space/postfix" hangs. A look at the zfs-process shows: # echo "0t236::pid2proc|::walk thread|::findstack -v" | mdb -k stack pointer for thread 30001cecc00: 2a100fa2181 [ 000002a100fa2181 cv_wait+0x3c() ] 000002a100fa2231 txg_wait_open+0x58(60014aa1158, d000b, 0, 60014aa119c, 60014aa119e, 60014aa1150) 000002a100fa22e1 dmu_tx_assign+0x3c(60022dd3780, 1, 7, 60013cd5918, 5b, 1) 000002a100fa2391 dmu_free_long_range_impl+0xc4(600245fbdb0, 60025f69750, 0, 400, 0, 1) 000002a100fa2451 dmu_free_long_range+0x44(600245f...

I have historically noticed that in ZFS, when ever there is a heavy writer to a pool via NFS, the reads can held back (basically paused). An example is a RAID10 pool of 6 disks, whereby a directory of files including some large 100+MB in size being written can cause other clients over NFS to pause for seconds (5-30 or so). This on B70 bits. I''ve gotten used to this behavior over NFS, but

...t it appears that ZFS is continuing to delete a snapshot/FS from before (reading from the top down): stack pointer for thread ffffff01ce408e00: ffffff0008f2b1f0 [ ffffff0008f2b1f0 _resume_from_idle+0xf1() ] ffffff0008f2b220 swtch+0x145() ffffff0008f2b250 cv_wait+0x61() ffffff0008f2b2a0 txg_wait_open+0x7a() ffffff0008f2b2e0 dmu_tx_wait+0xb3() ffffff0008f2b320 dmu_tx_assign+0x4b() ffffff0008f2b3b0 dmu_free_long_range_impl+0x12b() ffffff0008f2b400 dmu_free_object+0xe6() ffffff0008f2b710 dsl_dataset_destroy+0x122() ffffff0008f2b740 dsl_destroy_inconsistent+0x5f() ffffff0008f2b...

Now at 36 hours since zdb process start and: PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 827 root 4936M 4931M sleep 59 0 0:50:47 0.2% zdb/209 Idling at 0.2% processor for nearly the past 24 hours... feels very stuck. Thoughts on how to determine where and why? -- This message posted from opensolaris.org