J?rgen Keil wrote: >> Dunc wrote: > >> ---------------- lwp# 4 / thread# 4 -------------------- >> feef1777 readlink (fe76d23c, fe76d63c, fe76ce38, 805a55d) + 7 >> 0805a77d devfsadm_mklink (fe76ddac, 818c898, 81a9210, 0) + 231 >> fd67097a zfs (81a9210, 818c898, 80a9fa8, 81a9240) + 17e >> 0805964a minor_process (818c898, 81a9210, fe76e314, 805939e) + 13e >> 080594c3 check_minor_type (818c898, 81a9210, fe76e89c, febdbe6a) + 133 >> febdbf27 walk_one_minor_list (fe76e2c8, 0, 10, fe76e89c, 8059390, ef7f000) + >> cb >> febdc000 di_walk_minor (816b058, 0, 10, fe76e89c, 8059390, 807d52c) + 90 >> 08057b89 devi_tree_walk (fe76e89c, df07, 0, 8058736) + 10d >> 08058749 sync_handler (0, fe76e8ec, 514, 0, 0, 80586ac) + 9d >> feef1ff2 __door_return () + 52 > > lwp #4 in devfsadm seems to be busy; > I suspect this thread is consuming (all?) the cpu time. > > A "prstat -L" will show which process threads consume cpu time. > Does devfsadm/4 (lwp#4 in process devfsadm) consume all of > devfsadm's cpu time? > > What system call activity is reported by "truss -l -v all -p `pgrep -x > devfsadm `" ?
I forgot to follow up on this. Thanks very much for all your help J?rgen, I'll remember these commands for the future. It turned out there was loads of snapshots of a zvol that had been created by timeslider. Someone in #opensolaris did point me at it being caused by many snapshots before I asked on here, and I'd deleted them all from my zfs filesystems, but not the zvols. It seems that devfsadm was running so much as lots of new devices were arriving in /dev/zvol/.... Thanks again for your help, Cheers, Dunc
