search for: cv_wait

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

I''ve recently re-installed an X4500 running Nevada b109 and have been experiencing ZFS lock ups regularly (perhaps once every 2-3 days). The machine is a backup server and receives hourly ZFS snapshots from another thumper - as such, the amount of zfs activity tends to be reasonably high. After about 48 - 72 hours, the file system seems to lock up and I''m unable to do anything

...2 base genunix: [ID 179002 kern.notice] %l0-3: 0000000000000000 0000000000000000 00000180048279c0 000002a1035dbca0 Dec 27 04:42:12 base %l4-7: 0000000000000001 0000000001867800 0000000025be86dc 00000000018bbc00 Dec 27 04:42:12 base genunix: [ID 723222 kern.notice] 000002a10433f610 genunix:cv_wait+3c (3001365ba10, 3001365ba10, 1, 18d0c00, c44000, 0) Dec 27 04:42:12 base genunix: [ID 179002 kern.notice] %l0-3: 0000000000c44002 00000000018d0e58 0000000000000001 0000000000c44002 Dec 27 04:42:12 base %l4-7: 0000000000000000 0000000000000001 0000000000000002 0000000001326e5c Dec 27 04:42:...

Hi, There seems to be a few threads about zpool hang, do we have a workaround to resolve the hang issue without rebooting ? In my case, I have a pool with disks from external LUNs via a fiber cable. When the cable is unplugged while there is IO in the pool, All zpool related command hang (zpool status, zpool list, etc.), put the cable back does not solve the problem. Eventually, I

...# zfs list|wc -l 46 Using df I can see most file systems are already mounted. > ::ps!grep zfs R 254 163 7 7 0 0x4a004000 00000600219e1800 zfs > 00000600219e1800::walk thread|::findstack -v stack pointer for thread 300013026a0: 2a10069ebb1 [ 000002a10069ebb1 cv_wait+0x40() ] 000002a10069ec61 txg_wait_synced+0x54(3000052f0d0, 2f2216d, 3000107fb90, 3000052f110, 3000052f112, 3000052f0c8) 000002a10069ed11 zil_replay+0xbc(60022609c08, 600226a1840, 600226a1870, 700d13d8, 7ba2d000, 60006821200) 000002a10069ee01 zfs_domount+0x1f0(7ba35000, 700d1000, 60021a8bae0,...

...7 SUNW,UltraSPARC-T1 bcopy 12632788 unix kstat_hold 13037942 genunix cv_wait 13654225 genunix p_online 16763096 genunix syscall_mstate 1742...

...tech disk c6t7d0" to detech a mirror causes zpool command to hang with following kernel stack trace: PC: _resume_from_idle+0xf8 CMD: zpool detach disk1 c6t7d0 stack pointer for thread fffffe84d34b4920: fffffe8001c30c10 [ fffffe8001c30c10 _resume_from_idle+0xf8() ] swtch+0x110() cv_wait+0x68() spa_config_enter+0x50() spa_vdev_enter+0x2a() spa_vdev_detach+0x39() zfs_ioc_vdev_detach+0x48() zfsdev_ioctl+0x13e() cdev_ioctl+0x1d() spec_ioctl+0x50() fop_ioctl+0x25() ioctl+0xac() sys_syscall32+0x101() Other zpool commands, df, format all waiting...

...::ps ! grep find R 1248 1243 1248 1243 101 0x4a004000 ffffff02630d5728 find > ffffff02630d5728::walk thread | ::findstack stack pointer for thread ffffff025f15b3e0: ffffff000cb54650 [ ffffff000cb54650 _resume_from_idle+0xf1() ] ffffff000cb54680 swtch+0x145() ffffff000cb546b0 cv_wait+0x61() ffffff000cb54700 txg_wait_synced+0x7c() ffffff000cb54770 zil_replay+0xe8() ffffff000cb54830 zvol_create_minor+0x227() ffffff000cb54850 sdev_zvol_create_minor+0x19() ffffff000cb549c0 devzvol_create_link+0x49() ffffff000cb54ad0 sdev_call_dircallback+0xfe() ffffff000cb54c20...

...94900 4 <- schedctl_restore 9 95300 400 4 <- restorectx 8 95400 800 4 <- resume 7 95600 6500 4 <- cv_wait 6 95900 19600 4 <- ndi_devi_enter 5 97200 81726329100 I''m assuming since it is now running on a new proc, that it''s related to a context switch, and perhaps the per...

I have a ZFS pool that has been corrupted. The pool contains a single device which was actually a file on UFS. The machine was accidentally halted and now the pool is corrupt. There are (of course) no backups and I''ve been asked to recover the pool. The system panics when trying to do anything with the pool. root@:/$ zpool status panic[cpu1]/thread=fffffe8000758c80: assertion failed:

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 low priority/throttling it too much?

Hi, I am profiling some workloads for the voluntary and involuntary context switches. I am interested in finding out the reasons causing these two types of context switches. As far as I understand, involuntary context switch happens on expiration of time slice or when a higher priority process comes in. While the voluntary switch generally happens when a process is waiting for I/O etc. So to

...?m reading the output correctly, but 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_des...

The vendor wanted to come in and replace an HDD in the 2nd X4500, as it was "constantly busy", and since our x4500 has always died miserably in the past when a HDD dies, they wanted to replace it before the HDD actually died. The usual was done, HDD replaced, resilvering started and ran for about 50 minutes. Then the system hung, same as always, all ZFS related commands would just

...econds it exited all threads. While it was hanging I did: > ::ps!grep nfsd > 000006000a729068::walk thread|::findstack -v with output logged to a file. I attached output as nfsd.txt.gz You can see that one thread was in: stack pointer for thread 30003621660: 2a1038c7021 [ 000002a1038c7021 cv_wait+0x3c() ] 000002a1038c70d1 exitlwps+0x10c(0, 100000, 42100002, 6000a729068, 6000a72912e, 42000002) 000002a1038c7181 proc_exit+0x1c(1, 0, ff000000, 1, 0, e965) 000002a1038c7231 exit+8(1, 0, ffbff9d0, 1, ff164770, 16419) 000002a1038c72e1 syscall_trap32+0xcc(0, 0, ffbff9d0, 1, ff164770, 16419) stack po...

I just had a quick play with gzip compression on a filesystem and the result was the machine grinding to a halt while copying some large (.wav) files to it from another filesystem in the same pool. The system became very unresponsive, taking several seconds to echo keystrokes. The box is a maxed out AMD QuadFX, so it should have plenty of grunt for this. Comments? Ian