search for: fcip

Is it possible to use DTrace to display the number of arguments and their types for userland or kernel functions that are not explicitly instrumented or documented by their authors? We''re talking about functions provided by Veritas VxVM/VxFS and the like, and for example, we might want to try tracing I/Os from App => VxFS => VxVM => ssd driver to see where I/Os get aggregated or

I executed sync just before this happened.... ultra:ultra# mdb -k unix.0 vmcore.0 Loading modules: [ unix krtld genunix specfs dtrace ufs sd pcipsy md ip sctp usba fctl nca crypto zfs random nfs ptm cpc fcip sppp lofs ] > $c vpanic(7b653bd8, 7036fca0, 7036fc70, 7b652990, 0, 60002d0b480) zio_done+0x284(60002d0b480, 0, a8, 7036fca0, 0, 60000b08d80) zio_vdev_io_assess+0x178(60002d0b480, 8000, 10, 0, 0, 10) taskq_thread+0x1a4(6000080e210, 6000080e1b8, 50001, 2e6a0862848b, 2a10071daca, 2a10071dac8) threa...

Have you considered the mdb dcmd ::pfiles? mfe at inker:~/Code/dtrace/examples$ *pfexec mdb -k* Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp scsi_vhci zfs ip hook neti sockfs arp usba uhci fctl s1394 stmf stmf_sbd md lofs random idm sd crypto fcp cpc fcip smbsrv nfs ufs logindmux ptm nsmb sppp nsctl sdbc rdc sv ii ipc ] > *::ps ! grep clock-applet* R 1744 1 1705 1705 101 0x4a004000 ffffff01e5183018 clock-applet > *ffffff01e5183018::pfiles* FD TYPE VNODE INFO 0 CHR ffffff01d1180440 /devices/pseudo/mm at 0:null...

We have a 32 GB RAM server running about 14 zones. There are multiple databases, application servers, web servers, and ftp servers running in the various zones. I understand that using ZFS will increase kernel memory usage, however I am a bit concerned at this point. root at servername:~/zonecfg #mdb -k Loading modules: [ unix krtld genunix specfs dtrace uppc pcplusmp ufs md mpt ip indmux ptm

...both an ZFS and an Solaris newbie, but I''ve managed to gather some information that I''ve seen others pasting: bash-3.00# mdb 0 Loading modules: [ unix krtld genunix specfs dtrace uppc pcplusmp scsi_vhci ufs ip sctp arp usba uhci nca lofs zfs random sppp ptm nfs crypto ipc md cpc fcip fctl fcp logindmux ] > ::status debugging crash dump vmcore.0 (32-bit) from unknown operating system: 5.11 snv_48 (i86pc) panic message: ZFS: bad checksum (read on <unknown> off 0: zio dbbf8880 [L1 ZFS plain file] 4000L/400P DVA[0]=<0:6aa000:800> DVA[1]=<0:b80a7000:800> fletche...

I have just recently (physically) moved a system with 16 hard drives (for the array) and 1 OS drive; and in doing so, I needed to pull out the 16 drives so that it would be light enough for me to lift. When I plugged the drives back in, initially, it went into a panic-reboot loop. After doing some digging, I deleted the file /etc/zfs/zpool.cache. When I try to import the pool using the zpool

on Solaris 10 5.10 Generic_118822-23 sun4v sparc SUNW,Sun-Fire-T200 I run #iostat -xn 5 to monitor the IO statistics on SF T2000 server. The system also have a heavy IO load, for some reason iostat donot refresh (no any update). It seems like iostat is calling pause() and stucked there. Also my HBA driver''s interrupt stack trace indicates there is a lot of swtch(), the overall IOPS

...0 1.5 0.0 0.0 0.0 1.7 0 1 c2t42d0 ^C bash-3.00# Not really much is happening here - looks like CPU is the limiting factor. bash-3.00# mdb -k Loading modules: [ unix krtld genunix specfs dtrace ufs sd px md ip sctp usba fcp fctl qlc crypto lofs zfs random nfs ptm ssd logindmux cpc fcip ] > ::ps!grep zpool R 17472 15928 17472 15928 0 0x4a004000 00000303b55647f8 zpool > 00000303b55647f8::walk thread|::findstack -v stack pointer for thread 307939f6fc0: 2a102d5cf41 [ 000002a102d5cf41 cv_wait+0x38() ] 000002a102d5cff1 txg_wait_synced+0x54(6000c977d90, 337e86, 337e84,...

Hello ZFS, System was rebooted and after reboot server again System is snv_39, SPARC, T2000 bash-3.00# ptree 7 /lib/svc/bin/svc.startd -s 163 /sbin/sh /lib/svc/method/fs-local 254 /usr/sbin/zfs mount -a [...] bash-3.00# 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