Re: [zfs-discuss] Kernel panic on zpool import. 200G of data inaccessible!
On Fri, 19 Aug 2011, Edho Arief wrote: Asking Oracle for help without support contract would be like shouting in vacuum space... It seems that obtaining an Oracle support contract or a contract renewal is equally frustrating. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Kernel panic on zpool import. 200G of data inaccessible!
On Fri, Aug 19, 2011 at 12:19 AM, Stu Whitefish wrote: >> From: Thomas Gouverneur > >> To: zfs-discuss@opensolaris.org >> Cc: >> Sent: Thursday, August 18, 2011 5:11:16 PM >> Subject: Re: [zfs-discuss] Kernel panic on zpool import. 200G of data >> inaccessible! >> >> Have you already extracted the core file of the kernel crash ? > > Nope, not a clue how to do that and I have installed Windows on this box > instead of Solaris since I can't get my data back from ZFS. > I have my two drives the pool is on disconnected so if this ever gets > resolved I can reinstall Solaris and start learning again. > >> (and btw activated dump device for such dumping happen at next reboot...) > > This was a development box for me to see how I get along with Solaris. I'm > afraid I don't have any experience in Solaris to understand your question. > >> Have you also tried applying the latest kernel/zfs patches and try importing >> the pool afterwards ? > > Wish I had them and knew what to do with them if I had them. Somebody on OTN > noted this is supposed to be fixed by 142910 but > I didn't hear back yet whether it fixes an pool ZFS won't import, or it only > stops it from happening in the first place. Don't have a service > contract as I say this box was my first try with Solaris and it is a homebrew > system not on Oracle's support list. > > I am sure if there is a patch for this or a way to get my 200G of data back > some kind soul at Oracle will certainly help me since I lost > my data and getting it back isn't a matter of convenience. What an > opportunity to generate some old fashioned goodwill! :-) > lots of replies and no suggestion to try on FreeBSD. How about trying on one? I believe if it crashed on FreeBSD, the developers would be interested in helping to solve it. Try using the 9.0-beta1 since 8.2-release has some problems importing certain zpools. Asking Oracle for help without support contract would be like shouting in vacuum space... ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS performance question over NFS
On Thu, 18 Aug 2011, Thomas Nau wrote: Tim the client is identical as the server but no SAS drives attached. Also right now only one 1gbit Intel NIC Is available I don't know what the request pattern from filebench looks like but it seems like your ZEUS RAM devices are not keeping up or else many requests are bypassing the ZEUS RAM devices. Note that very large synchronous writes will bypass your ZEUS RAM device and go directly to a log in the main store. Small (<= 128K) writes should directly benefit from the dedicated zil device. Find a copy of zilstat.ksh and run it while filebench is running in order to understand more about what is going on. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS performance question over NFS
Tim the client is identical as the server but no SAS drives attached. Also right now only one 1gbit Intel NIC Is available Thomas Am 18.08.2011 um 17:49 schrieb Tim Cook : > What are the specs on the client? > > On Aug 18, 2011 10:28 AM, "Thomas Nau" wrote: > > Dear all. > > We finally got all the parts for our new fileserver following several > > recommendations we got over this list. We use > > > > Dell R715, 96GB RAM, dual 8-core Opterons > > 1 10GE Intel dual-port NIC > > 2 LSI 9205-8e SAS controllers > > 2 DataON DNS-1600 JBOD chassis > > 46 Seagate constellation SAS drives > > 2 STEC ZEUS RAM > > > > > > The base zpool config utilizes 42 drives plus the STECs as mirrored > > log devices. The Seagates are setup as a stripe of 7 times 6-drive-RAIDZ2 > > junks plus as said a dedicated ZIL made of the mirrored STECs. > > > > As a quick'n dirty check we ran "filebench" with the "fileserver" > > workload. Running locally we get > > > > statfile1 5476ops/s 0.0mb/s 0.6ms/op 179us/op-cpu > > deletefile1 5476ops/s 0.0mb/s 1.0ms/op 454us/op-cpu > > closefile3 5476ops/s 0.0mb/s 0.0ms/op 5us/op-cpu > > readfile1 5476ops/s 729.5mb/s 0.2ms/op 128us/op-cpu > > openfile2 5477ops/s 0.0mb/s 0.8ms/op 204us/op-cpu > > closefile2 5477ops/s 0.0mb/s 0.0ms/op 5us/op-cpu > > appendfilerand1 5477ops/s 42.8mb/s 0.3ms/op 184us/op-cpu > > openfile1 5477ops/s 0.0mb/s 0.9ms/op 209us/op-cpu > > closefile1 5477ops/s 0.0mb/s 0.0ms/op 6us/op-cpu > > wrtfile1 5477ops/s 688.4mb/s 0.4ms/op 220us/op-cpu > > createfile1 5477ops/s 0.0mb/s 2.7ms/op 1068us/op-cpu > > > > > > > > with a single remote client (similar Dell System) using NFS > > > > statfile1 90ops/s 0.0mb/s 27.6ms/op 145us/op-cpu > > deletefile1 90ops/s 0.0mb/s 64.5ms/op 401us/op-cpu > > closefile3 90ops/s 0.0mb/s 25.8ms/op 40us/op-cpu > > readfile1 90ops/s 11.4mb/s 3.1ms/op 363us/op-cpu > > openfile2 90ops/s 0.0mb/s 66.0ms/op 263us/op-cpu > > closefile2 90ops/s 0.0mb/s 22.6ms/op 124us/op-cpu > > appendfilerand1 90ops/s 0.7mb/s 0.5ms/op 101us/op-cpu > > openfile1 90ops/s 0.0mb/s 72.6ms/op 269us/op-cpu > > closefile1 90ops/s 0.0mb/s 43.6ms/op 189us/op-cpu > > wrtfile1 90ops/s 11.2mb/s 0.2ms/op 211us/op-cpu > > createfile1 90ops/s 0.0mb/s 226.5ms/op 709us/op-cpu > > > > > > > > the same remote client with zpool sync disabled on the server > > > > statfile1 479ops/s 0.0mb/s 6.2ms/op 130us/op-cpu > > deletefile1 479ops/s 0.0mb/s 13.0ms/op 351us/op-cpu > > closefile3 480ops/s 0.0mb/s 3.0ms/op 37us/op-cpu > > readfile1 480ops/s 62.7mb/s 0.8ms/op 174us/op-cpu > > openfile2 480ops/s 0.0mb/s 14.1ms/op 235us/op-cpu > > closefile2 480ops/s 0.0mb/s 6.0ms/op 123us/op-cpu > > appendfilerand1 480ops/s 3.7mb/s 0.2ms/op 53us/op-cpu > > openfile1 480ops/s 0.0mb/s 13.7ms/op 235us/op-cpu > > closefile1 480ops/s 0.0mb/s 11.1ms/op 190us/op-cpu > > wrtfile1 480ops/s 60.3mb/s 0.2ms/op 233us/op-cpu > > createfile1 480ops/s 0.0mb/s 35.6ms/op 683us/op-cpu > > > > > > Disabling ZIL is no option but I expected a much better performance > > especially the ZEUS RAM only gets us a speed-up of about 1.8x > > > > Is this test realistic for a typical fileserver scenario or does it require > > many > > more clients to push the limits? > > > > Thanks > > Thomas > > ___ > > zfs-discuss mailing list > > zfs-discuss@opensolaris.org > > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Kernel panic on zpool import. 200G of data inaccessible!
> From: Thomas Gouverneur > To: zfs-discuss@opensolaris.org > Cc: > Sent: Thursday, August 18, 2011 5:11:16 PM > Subject: Re: [zfs-discuss] Kernel panic on zpool import. 200G of data > inaccessible! > > Have you already extracted the core file of the kernel crash ? Nope, not a clue how to do that and I have installed Windows on this box instead of Solaris since I can't get my data back from ZFS. I have my two drives the pool is on disconnected so if this ever gets resolved I can reinstall Solaris and start learning again. > (and btw activated dump device for such dumping happen at next reboot...) This was a development box for me to see how I get along with Solaris. I'm afraid I don't have any experience in Solaris to understand your question. > Have you also tried applying the latest kernel/zfs patches and try importing > the pool afterwards ? Wish I had them and knew what to do with them if I had them. Somebody on OTN noted this is supposed to be fixed by 142910 but I didn't hear back yet whether it fixes an pool ZFS won't import, or it only stops it from happening in the first place. Don't have a service contract as I say this box was my first try with Solaris and it is a homebrew system not on Oracle's support list. I am sure if there is a patch for this or a way to get my 200G of data back some kind soul at Oracle will certainly help me since I lost my data and getting it back isn't a matter of convenience. What an opportunity to generate some old fashioned goodwill! :-) Jim > > > Thomas > > On 08/18/2011 06:40 PM, Stu Whitefish wrote: >> Hi Thomas, >> >> Thanks for that link. That's very similar but not identical. > There's a different line number in zfs_ioctl.c, mine and Preston's fail > on line 1815. It could be because of a difference in levels in that module of > course, but the traceback is not identical either. Ours show brand_sysenter > and > the one you linked to shows brand_sys_syscall. I don't know what all that > means but it is different. Anyway at least two of us have identical failures. >> >> I was not using crypto, just a plain jane mirror on 2 drives. Possibly I > had compression on a few file systems but everything else was allowed to > default. >> >> Here are our screenshots in case anybody doesn't want to go through the > thread. >> >> >> http://imageshack.us/photo/my-images/13/zfsimportfail.jpg/ >> >> http://prestonconnors.com/zvol_get_stats.jpg >> >> >> I hope somebody can help with this. It's not a good feeling having so > much data gone. >> >> Thanks for your help. Oracle, are you listening? >> >> Jim >> >> >> >> - Original Message - >> >>> From: Thomas Gouverneur >>> To: zfs-discuss@opensolaris.org >>> Cc: Stu Whitefish >>> Sent: Thursday, August 18, 2011 1:57:29 PM >>> Subject: Re: [zfs-discuss] Kernel panic on zpool import. 200G of data > inaccessible! >>> >>> You're probably hitting bug 7056738 -> >>> http://wesunsolve.net/bugid/id/7056738 >>> Looks like it's not fixed yet @ oracle anyway... >>> >>> Were you using crypto on your datasets ? >>> >>> >>> Regards, >>> >>> Thomas >>> >> ___ >> zfs-discuss mailing list >> zfs-discuss@opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >> > > ___ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Kernel panic on zpool import. 200G of data inaccessible!
Have you already extracted the core file of the kernel crash ? (and btw activated dump device for such dumping happen at next reboot...) Have you also tried applying the latest kernel/zfs patches and try importing the pool afterwards ? Thomas On 08/18/2011 06:40 PM, Stu Whitefish wrote: Hi Thomas, Thanks for that link. That's very similar but not identical. There's a different line number in zfs_ioctl.c, mine and Preston's fail on line 1815. It could be because of a difference in levels in that module of course, but the traceback is not identical either. Ours show brand_sysenter and the one you linked to shows brand_sys_syscall. I don't know what all that means but it is different. Anyway at least two of us have identical failures. I was not using crypto, just a plain jane mirror on 2 drives. Possibly I had compression on a few file systems but everything else was allowed to default. Here are our screenshots in case anybody doesn't want to go through the thread. http://imageshack.us/photo/my-images/13/zfsimportfail.jpg/ http://prestonconnors.com/zvol_get_stats.jpg I hope somebody can help with this. It's not a good feeling having so much data gone. Thanks for your help. Oracle, are you listening? Jim - Original Message - From: Thomas Gouverneur To: zfs-discuss@opensolaris.org Cc: Stu Whitefish Sent: Thursday, August 18, 2011 1:57:29 PM Subject: Re: [zfs-discuss] Kernel panic on zpool import. 200G of data inaccessible! You're probably hitting bug 7056738 -> http://wesunsolve.net/bugid/id/7056738 Looks like it's not fixed yet @ oracle anyway... Were you using crypto on your datasets ? Regards, Thomas ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Kernel panic on zpool import. 200G of data inaccessible!
Hi Thomas, Thanks for that link. That's very similar but not identical. There's a different line number in zfs_ioctl.c, mine and Preston's fail on line 1815. It could be because of a difference in levels in that module of course, but the traceback is not identical either. Ours show brand_sysenter and the one you linked to shows brand_sys_syscall. I don't know what all that means but it is different. Anyway at least two of us have identical failures. I was not using crypto, just a plain jane mirror on 2 drives. Possibly I had compression on a few file systems but everything else was allowed to default. Here are our screenshots in case anybody doesn't want to go through the thread. http://imageshack.us/photo/my-images/13/zfsimportfail.jpg/ http://prestonconnors.com/zvol_get_stats.jpg I hope somebody can help with this. It's not a good feeling having so much data gone. Thanks for your help. Oracle, are you listening? Jim - Original Message - > From: Thomas Gouverneur > To: zfs-discuss@opensolaris.org > Cc: Stu Whitefish > Sent: Thursday, August 18, 2011 1:57:29 PM > Subject: Re: [zfs-discuss] Kernel panic on zpool import. 200G of data > inaccessible! > > You're probably hitting bug 7056738 -> > http://wesunsolve.net/bugid/id/7056738 > Looks like it's not fixed yet @ oracle anyway... > > Were you using crypto on your datasets ? > > > Regards, > > Thomas ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS performance question over NFS
What are the specs on the client? On Aug 18, 2011 10:28 AM, "Thomas Nau" wrote: > Dear all. > We finally got all the parts for our new fileserver following several > recommendations we got over this list. We use > > Dell R715, 96GB RAM, dual 8-core Opterons > 1 10GE Intel dual-port NIC > 2 LSI 9205-8e SAS controllers > 2 DataON DNS-1600 JBOD chassis > 46 Seagate constellation SAS drives > 2 STEC ZEUS RAM > > > The base zpool config utilizes 42 drives plus the STECs as mirrored > log devices. The Seagates are setup as a stripe of 7 times 6-drive-RAIDZ2 > junks plus as said a dedicated ZIL made of the mirrored STECs. > > As a quick'n dirty check we ran "filebench" with the "fileserver" > workload. Running locally we get > > statfile1 5476ops/s 0.0mb/s 0.6ms/op 179us/op-cpu > deletefile1 5476ops/s 0.0mb/s 1.0ms/op 454us/op-cpu > closefile3 5476ops/s 0.0mb/s 0.0ms/op 5us/op-cpu > readfile1 5476ops/s 729.5mb/s 0.2ms/op 128us/op-cpu > openfile2 5477ops/s 0.0mb/s 0.8ms/op 204us/op-cpu > closefile2 5477ops/s 0.0mb/s 0.0ms/op 5us/op-cpu > appendfilerand1 5477ops/s 42.8mb/s 0.3ms/op 184us/op-cpu > openfile1 5477ops/s 0.0mb/s 0.9ms/op 209us/op-cpu > closefile1 5477ops/s 0.0mb/s 0.0ms/op 6us/op-cpu > wrtfile1 5477ops/s 688.4mb/s 0.4ms/op 220us/op-cpu > createfile1 5477ops/s 0.0mb/s 2.7ms/op 1068us/op-cpu > > > > with a single remote client (similar Dell System) using NFS > > statfile1 90ops/s 0.0mb/s 27.6ms/op 145us/op-cpu > deletefile1 90ops/s 0.0mb/s 64.5ms/op 401us/op-cpu > closefile3 90ops/s 0.0mb/s 25.8ms/op 40us/op-cpu > readfile1 90ops/s 11.4mb/s 3.1ms/op 363us/op-cpu > openfile2 90ops/s 0.0mb/s 66.0ms/op 263us/op-cpu > closefile2 90ops/s 0.0mb/s 22.6ms/op 124us/op-cpu > appendfilerand1 90ops/s 0.7mb/s 0.5ms/op 101us/op-cpu > openfile1 90ops/s 0.0mb/s 72.6ms/op 269us/op-cpu > closefile1 90ops/s 0.0mb/s 43.6ms/op 189us/op-cpu > wrtfile1 90ops/s 11.2mb/s 0.2ms/op 211us/op-cpu > createfile1 90ops/s 0.0mb/s 226.5ms/op 709us/op-cpu > > > > the same remote client with zpool sync disabled on the server > > statfile1 479ops/s 0.0mb/s 6.2ms/op 130us/op-cpu > deletefile1 479ops/s 0.0mb/s 13.0ms/op 351us/op-cpu > closefile3 480ops/s 0.0mb/s 3.0ms/op 37us/op-cpu > readfile1 480ops/s 62.7mb/s 0.8ms/op 174us/op-cpu > openfile2 480ops/s 0.0mb/s 14.1ms/op 235us/op-cpu > closefile2 480ops/s 0.0mb/s 6.0ms/op 123us/op-cpu > appendfilerand1 480ops/s 3.7mb/s 0.2ms/op 53us/op-cpu > openfile1 480ops/s 0.0mb/s 13.7ms/op 235us/op-cpu > closefile1 480ops/s 0.0mb/s 11.1ms/op 190us/op-cpu > wrtfile1 480ops/s 60.3mb/s 0.2ms/op 233us/op-cpu > createfile1 480ops/s 0.0mb/s 35.6ms/op 683us/op-cpu > > > Disabling ZIL is no option but I expected a much better performance > especially the ZEUS RAM only gets us a speed-up of about 1.8x > > Is this test realistic for a typical fileserver scenario or does it require many > more clients to push the limits? > > Thanks > Thomas > ___ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS performance question over NFS
Dear all. We finally got all the parts for our new fileserver following several recommendations we got over this list. We use Dell R715, 96GB RAM, dual 8-core Opterons 1 10GE Intel dual-port NIC 2 LSI 9205-8e SAS controllers 2 DataON DNS-1600 JBOD chassis 46 Seagate constellation SAS drives 2 STEC ZEUS RAM The base zpool config utilizes 42 drives plus the STECs as mirrored log devices. The Seagates are setup as a stripe of 7 times 6-drive-RAIDZ2 junks plus as said a dedicated ZIL made of the mirrored STECs. As a quick'n dirty check we ran "filebench" with the "fileserver" workload. Running locally we get statfile15476ops/s 0.0mb/s 0.6ms/op 179us/op-cpu deletefile1 5476ops/s 0.0mb/s 1.0ms/op 454us/op-cpu closefile3 5476ops/s 0.0mb/s 0.0ms/op5us/op-cpu readfile15476ops/s 729.5mb/s 0.2ms/op 128us/op-cpu openfile25477ops/s 0.0mb/s 0.8ms/op 204us/op-cpu closefile2 5477ops/s 0.0mb/s 0.0ms/op5us/op-cpu appendfilerand1 5477ops/s 42.8mb/s 0.3ms/op 184us/op-cpu openfile15477ops/s 0.0mb/s 0.9ms/op 209us/op-cpu closefile1 5477ops/s 0.0mb/s 0.0ms/op6us/op-cpu wrtfile1 5477ops/s 688.4mb/s 0.4ms/op 220us/op-cpu createfile1 5477ops/s 0.0mb/s 2.7ms/op 1068us/op-cpu with a single remote client (similar Dell System) using NFS statfile1 90ops/s 0.0mb/s 27.6ms/op 145us/op-cpu deletefile190ops/s 0.0mb/s 64.5ms/op 401us/op-cpu closefile3 90ops/s 0.0mb/s 25.8ms/op 40us/op-cpu readfile1 90ops/s 11.4mb/s 3.1ms/op 363us/op-cpu openfile2 90ops/s 0.0mb/s 66.0ms/op 263us/op-cpu closefile2 90ops/s 0.0mb/s 22.6ms/op 124us/op-cpu appendfilerand190ops/s 0.7mb/s 0.5ms/op 101us/op-cpu openfile1 90ops/s 0.0mb/s 72.6ms/op 269us/op-cpu closefile1 90ops/s 0.0mb/s 43.6ms/op 189us/op-cpu wrtfile1 90ops/s 11.2mb/s 0.2ms/op 211us/op-cpu createfile190ops/s 0.0mb/s226.5ms/op 709us/op-cpu the same remote client with zpool sync disabled on the server statfile1 479ops/s 0.0mb/s 6.2ms/op 130us/op-cpu deletefile1 479ops/s 0.0mb/s 13.0ms/op 351us/op-cpu closefile3480ops/s 0.0mb/s 3.0ms/op 37us/op-cpu readfile1 480ops/s 62.7mb/s 0.8ms/op 174us/op-cpu openfile2 480ops/s 0.0mb/s 14.1ms/op 235us/op-cpu closefile2480ops/s 0.0mb/s 6.0ms/op 123us/op-cpu appendfilerand1 480ops/s 3.7mb/s 0.2ms/op 53us/op-cpu openfile1 480ops/s 0.0mb/s 13.7ms/op 235us/op-cpu closefile1480ops/s 0.0mb/s 11.1ms/op 190us/op-cpu wrtfile1 480ops/s 60.3mb/s 0.2ms/op 233us/op-cpu createfile1 480ops/s 0.0mb/s 35.6ms/op 683us/op-cpu Disabling ZIL is no option but I expected a much better performance especially the ZEUS RAM only gets us a speed-up of about 1.8x Is this test realistic for a typical fileserver scenario or does it require many more clients to push the limits? Thanks Thomas ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Kernel panic on zpool import. 200G of data inaccessible!
You're probably hitting bug 7056738 -> http://wesunsolve.net/bugid/id/7056738 Looks like it's not fixed yet @ oracle anyway... Were you using crypto on your datasets ? Regards, Thomas On Tue, 16 Aug 2011 09:33:34 -0700 (PDT) Stu Whitefish wrote: > - Original Message - > > > From: Alexander Lesle > > To: zfs-discuss@opensolaris.org > > Cc: > > Sent: Monday, August 15, 2011 8:37:42 PM > > Subject: Re: [zfs-discuss] Kernel panic on zpool import. 200G of data > > inaccessible! > > > > Hello Stu Whitefish and List, > > > > On August, 15 2011, 21:17 wrote in [1]: > > > >>> 7. cannot import old rpool (c0t2d0s0 c0t3d0s0), any attempt causes a > >>> kernel panic, even when booted from different OS versions > > > >> Right. I have tried OpenIndiana 151 and Solaris 11 Express (latest > >> from Oracle) several times each as well as 2 new installs of Update 8. > > > > When I understand you right is your primary interest to recover your > > data on tank pool. > > > > Have you check the way to boot from a Live-DVD, mount your "safe > > place" > > and copy the data on a other machine? > > Hi Alexander, > > Yes of course...the problem is no version of Solaris can import the pool. > Please refer to the first message in the thread. > > Thanks, > > Jim > > ___ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- Gouverneur Thomas ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs-discuss Digest, Vol 70, Issue 37
Please check whether you have latest ' MPT ' patch installed on your server ? If not , please install MPT patch . It will fix the issue . Regards, Gowrisankar . On Thu, Aug 18, 2011 at 5:30 PM, wrote: > Send zfs-discuss mailing list submissions to >zfs-discuss@opensolaris.org > > To subscribe or unsubscribe via the World Wide Web, visit >http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > or, via email, send a message with subject or body 'help' to >zfs-discuss-requ...@opensolaris.org > > You can reach the person managing the list at >zfs-discuss-ow...@opensolaris.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of zfs-discuss digest..." > > > Today's Topics: > > 1. Re: solaris 10u8 hangs with message Disconnected command > timeout for Target 0 (Richard Elling) > > > -- > > Message: 1 > Date: Wed, 17 Aug 2011 17:20:23 -0700 > From: Richard Elling > To: Ding Honghui > Cc: zfs-discuss@opensolaris.org > Subject: Re: [zfs-discuss] solaris 10u8 hangs with message >Disconnectedcommand timeout for Target 0 > Message-ID: > Content-Type: text/plain; charset=iso-8859-1 > > On Aug 15, 2011, at 11:17 PM, Ding Honghui wrote: > > My solaris storage hangs. I login to the console and there is messages[1] > display on the console. > > I can't login into the console and seems the IO is totally blocked. > > > > The system is solaris 10u8 on Dell R710 with disk array Dell MD3000. 2 > HBA cable connect the server and MD3000. > > The symptom is random. > > This symptom is consistent with a broken SATA disk behind a SAS expander. > > Unfortunately, the mpt driver is closed source, so we can only infer what > the > code does by using the open source mpt_sas driver as (hopefully) a > derivative. > > > > > It is very appreciated if any one can help me out. > > > > Regards, > > Ding > > > > [1] > > Aug 16 13:14:16 nas-hz-02 scsi: WARNING: /pci@0,0/pci8086,3410@9 > /pci8086,32c@0/pci1028,1f04@8 (mpt1): > > Aug 16 13:14:16 nas-hz-02 Disconnected command timeout for Target 0 > > A command did not complete and the mpt driver reset the target. > If that target is an expander, then everything behind the expander can > reset, resulting in the aborts of any in-flight commands, as follows... > > > Aug 16 13:14:16 nas-hz-02 scsi: WARNING: > /scsi_vhci/disk@g60026b900053aa1802a44b8f0ded (sd47): > > Aug 16 13:14:16 nas-hz-02 Error for Command: write(10) > Error Level: Retryable > > Aug 16 13:14:16 nas-hz-02 scsi: Requested Block: 1380679073 > Error Block: 1380679073 > > Aug 16 13:14:16 nas-hz-02 scsi: Vendor: DELL > Serial Number: > > Aug 16 13:14:16 nas-hz-02 scsi: Sense Key: Unit Attention > > Aug 16 13:14:16 nas-hz-02 scsi: ASC: 0x29 (device internal > reset), ASCQ: 0x4, FRU: 0x0 > > Aug 16 13:14:16 nas-hz-02 scsi: WARNING: > /scsi_vhci/disk@g60026b900053aa18029e4b8f0d61 (sd41): > > Aug 16 13:14:16 nas-hz-02 Error for Command: write(10) > Error Level: Retryable > > Aug 16 13:14:16 nas-hz-02 scsi: Requested Block: 1380679072 > Error Block: 1380679072 > > Aug 16 13:14:16 nas-hz-02 scsi: Vendor: DELL > Serial Number: > > Aug 16 13:14:16 nas-hz-02 scsi: Sense Key: Unit Attention > > Aug 16 13:14:16 nas-hz-02 scsi: ASC: 0x29 (device internal > reset), ASCQ: 0x4, FRU: 0x0 > > Aug 16 13:14:16 nas-hz-02 scsi: WARNING: > /scsi_vhci/disk@g60026b900053aa1802a24b8f0dc5 (sd45): > > Aug 16 13:14:16 nas-hz-02 Error for Command: write(10) > Error Level: Retryable > > Aug 16 13:14:16 nas-hz-02 scsi: Requested Block: 1380679073 > Error Block: 1380679073 > > Aug 16 13:14:16 nas-hz-02 scsi: Vendor: DELL > Serial Number: > > Aug 16 13:14:16 nas-hz-02 scsi: Sense Key: Unit Attention > > Aug 16 13:14:16 nas-hz-02 scsi: ASC: 0x29 (device internal > reset), ASCQ: 0x4, FRU: 0x0 > > Aug 16 13:14:16 nas-hz-02 scsi: WARNING: > /scsi_vhci/disk@g60026b900053aa18029c4b8f0d35 (sd39): > > Aug 16 13:14:16 nas-hz-02 Error for Command: write(10) > Error Level: Retryable > > Aug 16 13:14:16 nas-hz-02 scsi: Requested Block: 1380679072 > Error Block: 1380679072 > > Aug 16 13:14:16 nas-hz-02 scsi: Vendor: DELL > Serial Number: > > Aug 16 13:14:16 nas-hz-02 scsi: Sense Key: Unit Attention > > Aug 16 13:14:16 nas-hz-02 scsi: ASC: 0x29 (device internal > reset), ASCQ: 0x4, FRU: 0x0 > > Aug 16 13:14:16 nas-hz-02 scsi: WARNING: > /scsi_vhci/disk@g60026b900053aa1802984b8f0cd2 (sd35): > > Aug 16 13:14:16 nas-hz-02 Error for Command: write(10) > Error Level: Retryable > > Aug 16 13:14:16 nas-hz-02 scsi: Requested Block: 1380679072 > Error Block: 1380679072 > > Aug 16 13:14:16 nas-hz-02 scsi: Vendor: DELL > Serial
