Re: [zfs-discuss] [zfs] Oddly-persistent file error on ZFS root pool
On Mon, 2012-01-30 at 01:50 +, Lou Picciano wrote: Bayard, Indeed, you did answer it - and thanks for getting back to me - your suggestion was spot ON! However, the simple zpool clear/scrub cycle wouldn't work in our case - at least initially. In fact, after multiple 'rinse/repeats', the offending file - or its hex representation - would reappear. In fact, the CHSKUM errors would often mount... Logically, this seems to make some sense; that zfs would attempt to reconstitute the damaged file with each scrub...(?) As the truth is somewhere in between, I'll insert my comment accordingly. You should only see the errors continue if there's a dataset with a reference to the version of the file that creates those errors. I've seen this before: until all of the datasets are deleted, the errors will continue to be diagnosed, sometimes presented without databaset names, which might be considered a bug (it seems wrong that you don't get a dataset name for clones). You wouldn't happen to have preserved output that could be used to determine if/where there's a bug? In any case, after gathering the nerve to start deleting old snapshots - including the one with the offending file - the clear/scrub process worked a charm. Many thanks again! Lou Picciano - Original Message - From: Bayard G. Bell buffer.g.overf...@gmail.com To: z...@lists.illumos.org Cc: zfs-discuss@opensolaris.org Sent: Sunday, January 29, 2012 3:22:39 PM Subject: Re: [zfs] Oddly-persistent file error on ZFS root pool Lou, Tried to answer this when you asked on IRC. Try a zpool clear and scrub again to see if the errors persist. Cheers, Bayard signature.asc Description: This is a digitally signed message part ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] GUI to set ACLs
Hi all! I'm searching for a GUI tool to set ZFS (NFSv4) ACLs. I found some nautilus add ons in the web but they don't seen to work with nautilus shipped with OI. Any solution? Achim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] [zfs] Oddly-persistent file error on ZFS root pool
Bayard, You wouldn't happen to have preserved output that could be used to determine if/where there's a bug? Whoops - in fact, this was the gist of my email to the lists, really; that someone might be interested in diagnostic information. The short answer: After not hearing a lot of interest in that - apart from your own response - and now having deleted the datasets in question: I hope so! I certainly do have the last crash dump - intact, as the machine hasn't crashed since...(...sound of knocking on wood) Pls tell me what debug info I can provide. The fix itself turned out to be quite easy, as you've indicated. My first concern was in being a good 'Listizen' - identifying/reporting on a bug, if one exists. Thanks again for your help, Lou Picciano - Original Message - From: Bayard G. Bell buffer.g.overf...@gmail.com To: z...@lists.illumos.org Cc: zfs-discuss@opensolaris.org Sent: Tuesday, January 31, 2012 7:01:53 AM Subject: Re: [zfs] Oddly-persistent file error on ZFS root pool On Mon, 2012-01-30 at 01:50 +, Lou Picciano wrote: Bayard, Indeed, you did answer it - and thanks for getting back to me - your suggestion was spot ON! However, the simple zpool clear/scrub cycle wouldn't work in our case - at least initially. In fact, after multiple 'rinse/repeats', the offending file - or its hex representation - would reappear. In fact, the CHSKUM errors would often mount... Logically, this seems to make some sense; that zfs would attempt to reconstitute the damaged file with each scrub...(?) As the truth is somewhere in between, I'll insert my comment accordingly. You should only see the errors continue if there's a dataset with a reference to the version of the file that creates those errors. I've seen this before: until all of the datasets are deleted, the errors will continue to be diagnosed, sometimes presented without databaset names, which might be considered a bug (it seems wrong that you don't get a dataset name for clones). You wouldn't happen to have preserved output that could be used to determine if/where there's a bug? In any case, after gathering the nerve to start deleting old snapshots - including the one with the offending file - the clear/scrub process worked a charm. Many thanks again! Lou Picciano - Original Message - From: Bayard G. Bell buffer.g.overf...@gmail.com To: z...@lists.illumos.org Cc: zfs-discuss@opensolaris.org Sent: Sunday, January 29, 2012 3:22:39 PM Subject: Re: [zfs] Oddly-persistent file error on ZFS root pool Lou, Tried to answer this when you asked on IRC. Try a zpool clear and scrub again to see if the errors persist. Cheers, Bayard --- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22086598-09fa5b64 Modify Your Subscription: https://www.listbox.com/member/?member_id=22086598id_secret=22086598-86c7d407 Powered by Listbox: http://www.listbox.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] snv_123 to S10U10
I'm going to be moving a non root storage pool from snv_123(I think it's pre comstar) to s10u10 box. I have some zfs iscsi volumes on the pool. I'm wondering if zpool export vdipool on the old system and zpool import vdipool on the new system will work? Do i need to run any other commands to save the iscsi configuration on the old system? Thanks Karl CONFIDENTIALITY NOTICE: This communication (including all attachments) is confidential and is intended for the use of the named addressee(s) only and may contain information that is private, confidential, privileged, and exempt from disclosure under law. All rights to privilege are expressly claimed and reserved and are not waived. Any use, dissemination, distribution, copying or disclosure of this message and any attachments, in whole or in part, by anyone other than the intended recipient(s) is strictly prohibited. If you have received this communication in error, please notify the sender immediately, delete this communication from all data storage devices and destroy all hard copies. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Bad performance (Seagate drive related?)
Hi list! I have seen less-than-stellar ZFS performance on a setup of one main head connected to a JBOD (using SAS, but drives are SATA). There are 16 drives (8 mirrors) in this pool but I'm getting 180ish MB sequential writes (using dd, I know it's not precise, but those numbers should be higher). With some help on IRC, it seems that part of the reason I'm slowing down is some drives seem to be slower than the others. Initially, I had some drives running at 1.5 mode instead of 3.0 -- They are all running at 3.0 now. While running the following dd command, the output of iostat reflects a much higher %b which seems to say that those drives are slower (but could they really be slowing down everything else that much? --- Or am I looking at the wrong spot here?) -- The pool configuration is also included below dd if=/dev/zero of=4g bs=1M count=4000 extended device statistics r/sw/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 1.00.08.00.0 0.0 0.00.00.2 0 0 c1 1.00.08.00.0 0.0 0.00.00.2 0 0 c1t2d0 8.0 3857.8 64.0 337868.8 0.0 64.50.0 16.7 0 704 c5 0.0 259.00.0 26386.2 0.0 3.60.0 14.0 0 37 c5t50014EE0ACE4AEEFd0 1.0 266.08.0 27139.2 0.0 3.60.0 13.5 0 37 c5t50014EE056EB0356d0 2.0 276.0 16.0 19315.1 0.0 3.70.0 13.3 0 40 c5t50014EE00239C976d0 0.0 279.00.0 19699.0 0.0 3.60.0 13.0 0 37 c5t50014EE0577C459Cd0 1.0 232.08.0 23061.9 0.0 3.60.0 15.4 0 37 c5t50014EE0578F60F5d0 0.0 227.00.0 22677.9 0.0 3.60.0 15.8 0 37 c5t50014EE0AC407BAEd0 0.0 205.00.0 24870.2 0.0 3.40.0 16.6 0 35 c5t50014EE0AC408605d0 0.0 205.00.0 24870.2 0.0 3.40.0 16.6 0 35 c5t50014EE056EB0B94d0 1.0 210.08.0 15954.2 0.0 4.40.0 20.8 0 68 c5t5000C50010C77647d0 0.0 212.00.0 16082.2 0.0 4.10.0 19.2 0 42 c5t5000C50010C865DEd0 0.0 207.00.0 20093.9 0.0 4.20.0 20.3 0 45 c5t5000C50010C77679d0 0.0 208.00.0 19689.5 0.0 4.10.0 19.8 0 44 c5t5000C50010C7672Dd0 0.0 259.00.0 14013.7 0.0 5.10.0 19.7 0 53 c5t5000C5000A11B600d0 2.0 320.0 16.0 19942.9 0.0 6.90.0 21.5 0 84 c5t5000C50008315CE5d0 1.0 259.08.0 23380.2 0.0 3.60.0 13.9 0 37 c5t50014EE001407113d0 0.0 234.00.0 20692.4 0.0 3.60.0 15.4 0 38 c5t50014EE00194FB1Bd0 pool: tank state: ONLINE scan: scrub canceled on Mon Jan 30 11:07:02 2012 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 c5t50014EE0ACE4AEEFd0 ONLINE 0 0 0 c5t50014EE056EB0356d0 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 c5t50014EE00239C976d0 ONLINE 0 0 0 c5t50014EE0577C459Cd0 ONLINE 0 0 0 mirror-3 ONLINE 0 0 0 c5t50014EE0578F60F5d0 ONLINE 0 0 0 c5t50014EE0AC407BAEd0 ONLINE 0 0 0 mirror-4 ONLINE 0 0 0 c5t50014EE056EB0B94d0 ONLINE 0 0 0 c5t50014EE0AC408605d0 ONLINE 0 0 0 mirror-5 ONLINE 0 0 0 c5t5000C50010C77647d0 ONLINE 0 0 0 c5t5000C50010C865DEd0 ONLINE 0 0 0 mirror-6 ONLINE 0 0 0 c5t5000C50010C7672Dd0 ONLINE 0 0 0 c5t5000C50010C77679d0 ONLINE 0 0 0 mirror-7 ONLINE 0 0 0 c5t50014EE001407113d0 ONLINE 0 0 0 c5t50014EE00194FB1Bd0 ONLINE 0 0 0 mirror-8 ONLINE 0 0 0 c5t5000C50008315CE5d0 ONLINE 0 0 0 c5t5000C5000A11B600d0 ONLINE 0 0 0 cache c1t2d0 ONLINE 0 0 0 c1t3d0 ONLINE 0 0 0 spares c5t5000C5000D46F13Dd0AVAIL From c5t5000C50010C77647d0 to c5t5000C50008315CE5d0 are the 6 Seagate drives, they are 2 ST31000340AS and 4 ST31000340NS. The rest of the drives are all WD RE3 (WD1002FBYS). Could those Seagate's really be slowing down the array that much or there is something else in here that I should be trying to look at? I did the same dd on the main OS pool (2 mirrors) and got 63MB/s .. times 8 mirrors should give me 504MBs reads? tl;dr: My tank of 8 mirrors is giving 180MB writes, how to fix?! -- Mohammed Naser — vexxhost ___ zfs-discuss
Re: [zfs-discuss] GUI to set ACLs
On 31 Jan 2012, at 12:20, Achim Wolpers wrote: Hi all! I'm searching for a GUI tool to set ZFS (NFSv4) ACLs. I found some nautilus add ons in the web but they don't seen to work with nautilus shipped with OI. Any solution? Does Windows count? Windows can certainly edit ZFS ACLs when they're exposed to it over CIFS. ;-) Chris ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] (gang?)block layout question, and how to decipher ZDB output?
Hello, all I'm playing with ZDB again on another test system, the rpool being uncompressed with 512-byte sectors. Here's some output that puzzles me (questions follow): # zdb - -bb rpool/ROOT/nightly-2012-01-31 260050 ... 1e8 L0 DVA[0]=0:200972e00:20200 DVA[1]=0:391820a00:200 [L0 ZFS plain file] fletcher4 uncompressed LE gang unique single size=2L/2P birth=743480L/743480P fill=1 cksum=40ed72fd1a7e:10813724cba2f082:99adc8fc26918419:77a6a1f23fa0600 1ea L0 DVA[0]=0:206373000:2 [L0 ZFS plain file] fletcher4 uncompressed LE contiguous unique single size=2L/2P birth=743481L/743481P fill=1 cksum=3e813c892009:fe2666367dd7397:eab4fcda09e1eda:920af56056f956cb 1ec L0 DVA[0]=0:206599400:2 [L0 ZFS plain file] fletcher4 uncompressed LE contiguous unique single size=2L/2P birth=743481L/743481P fill=1 cksum=4213d7748915:10958bc56b9df6f3:514903c1c2a34d4f:92b907df21b16050 ... 322 L0 DVA[0]=0:191e41400:20200 DVA[1]=0:39c762600:200 [L0 ZFS plain file] fletcher4 uncompressed LE gang unique single size=2L/2P birth=743482L/743482P fill=1 cksum=3e7277e04a2c:fc89c0aa8f72a75:46132aa352fa4e80:9126a177ac19bfe4 324 L0 DVA[0]=0:191e41600:20200 DVA[1]=0:39c762800:200 [L0 ZFS plain file] fletcher4 uncompressed LE gang unique single size=2L/2P birth=743482L/743482P fill=1 cksum=7135eb7cbcd:34cb6fb5d8397c0:5d9d497e1e2f3942:72b840ca284a2130 326 L0 DVA[0]=0:191e41800:20200 DVA[1]=0:39c7b9600:200 [L0 ZFS plain file] fletcher4 uncompressed LE gang unique single size=2L/2P birth=743482L/743482P fill=1 cksum=0:0:0:0 328 L0 DVA[0]=0:191e70400:20200 DVA[1]=0:39c7b9800:200 [L0 ZFS plain file] fletcher4 uncompressed LE gang unique single size=2L/2P birth=743482L/743482P fill=1 cksum=0:0:0:0 segment [, 032a) size 50.6M 1) Why does each almost entry have several DVA addresses? I believe this has to do with gang-blocking, but why is it not consistent (some blocks are single-DVA, most are double-DVA). I thought it might be due to fragmentation - ZFS failed to find enough contiguous addresses... is it realistic? In this case, what does the single segment entry mean then? 2) The last two blocks are reported to have zero values for checksums. Why is that, and why doesn't it trigger a CKSUM error (I can read the whole file, no I/O errors)? 3) I tried to extract the blocks, they did not seem empty (that was my guess at why they would have zero checksums). However, I am not certain how to correctly extract such ganged blocks: 3.1) Trying the first DVA as-is fails (how does it know the correct power-of-two size for a direct request of on-VDEV data?): # zdb -R rpool 0:191e70400:20200:r /tmp/rp1 Found vdev: /dev/dsk/c4t0d0s0 Assertion failed: size = (1ULL 17) (0x20200 = 0x2), file ../../../uts/common/fs/zfs/zio.c, line 493 Abort 3.2) Disabling assertions seems to help: # zdb -AAA -R rpool 0:191e70400:20200:r /tmp/rp3 Found vdev: /dev/dsk/c4t0d0s0 Comparing RP1 and RP3 files showed that the latter indeed has 0x200 bytes added at the end; first 0x2 are identical... 3.3) Extracting a power-of-two sized block works, but is it everything there was in original on-disk data (sized 20200?) # zdb -R rpool 0:191e70400:2:r /tmp/rp1 Found vdev: /dev/dsk/c4t0d0s0 # zdb -R rpool 0:39c7b9800:200:r /tmp/rp2 Found vdev: /dev/dsk/c4t0d0s0 Thanks in advance for helping me decipher this all, :) //Jim Klimov ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] RAM failure led to data corruption
Hi! Today I encountered data corruption on two zfs pools due to a RAM failure in my OI box running on a dell T710. My rpool now looks like this (after reboot): pool: rpool state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scan: scrub repaired 0 in 1h1m with 1 errors on Tue Jan 31 19:59:50 2012 config: NAME STATE READ WRITE CKSUM rpoolONLINE 0 0 1 mirror-0 ONLINE 0 0 2 c4t50014EE10313DE5Dd0s0 ONLINE 0 0 2 c4t50014EE158688073d0s0 ONLINE 0 0 2 errors: Permanent errors have been detected in the following files: //var/pkg/lost+found/var/lib/gdm-20120131T195638Z/core //usr/lib/svn/libsvn_delta-1.so.0.0.0 //lib/libpam.so.1 //usr/lib/libXtsol.so.1 //usr/lib/gnome-settings-daemon //usr/ruby/1.8/lib/ruby/1.8/optparse.rb //usr/gnu/bin/rm //var/log/syslog //usr/lib/amd64/libpciaccess.so.0 //usr/local/lib/libiconv.so.2.5.0 /rpool/service/svn/dvg/db/revs/0/653 /rpool/service/svn/privat/db/revs/0/451 /rpool/service/svn/privat/db/revs/0/716 /rpool/service/svn/privat/db/revs/1/1276 /rpool/service/svn/privat/db/revs/0/377 /rpool/service/svn/privat/db/revs/0/835 /rpool/service/svn/privat/db/revs/0/364 I have 17 files that are permanently corrupted. The corruption of gdm/core was found while scrubbing the pool. All the other 16 files where displayed as corrupted after the pool fell in degraded state. I'm not sure if these files are really corrupted, though: I can access all these files and e.g. /usr/gnu/bin/rm works with no faults. All files have the identical md5 sum compared the the corresponding files of a different box, also running the same version of OI. How do I find out, if these files are corrupted? If they appear to be ok, how do I get rid of the errors? How can two healthy pools get that messed up, when a RAM DIMM gets broken? Achim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] RAM failure led to data corruption
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Achim Wolpers I'm not sure if these files are really corrupted, All files have the identical md5 sum compared the the corresponding files of a different box, also running the same version of OI. How do I find out, if these files are corrupted? If they appear to be ok, how do I get rid of the errors? Given that they all have the same md5sum as another copy on another box that you have solid reason to believe is not corrupted... Then I think it's pretty safe for you to conclude the corruption in the corrupt box was actually a miscomputed checksum. So... To get rid of the errors... Just copy the files from the other box, and overwrite the files in the supposedly corrupted box. This will force the supposedly corrupt system to calculate new checksums, and start using the new data with correct checksums. But that's only half of the problem. As far as I know, you'll have to wait for the corrupted data to cycle its way out through your normal snapshot rotation. Or you could start destroying snapshots. But some of the folks here are much better with zdb and so forth than I am - there may be a way to correct the incorrect cksum. Your child swallowed a plastic bead? Don't worry, it will pass. How can two healthy pools get that messed up, when a RAM DIMM gets broken? Two healthy pools? I thought you only mentioned one pool. No matter. Here's the answer: Suppose you are a processor. You have instructions to follow, and you have paper to write on, to keep track of all the variables you're using, which are too many to keep inside your short term memory all the time. But when you're not looking, somebody comes along and changes what you wrote in your notepad. You were in the middle of calculating a cksum for some block of data, and a cosmic flare or something caused your calculation to get messed up. Of course you didn't know it. So you wrote the data to disk, and you wrote the wrong checksum to disk too. Later you read it back, and the chksum fails, which does not tell you the data is corrupt - it tells you either the data or the cksum is corrupt. You don't know which, so the best thing to do is simply restore the data from a known good copy. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] need hint on pool setup
Dear all We have two JBODs with 20 or 21 drives available per JBOD hooked up to a server. We are considering the following setups: RAIDZ2 made of 4 drives RAIDZ2 made of 6 drives The first option wastes more disk space but can survive a JBOD failure whereas the second is more space effective but the system goes down when a JBOD goes down. Each of the JBOD comes with dual controllers, redundant fans and power supplies so do I need to be paranoid and use option #1? Of course it also gives us more IOPs but high end logging devices should take care of that Thanks for any hint Thomas ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] need hint on pool setup
On Tue, 31 Jan 2012, Thomas Nau wrote: Dear all We have two JBODs with 20 or 21 drives available per JBOD hooked up to a server. We are considering the following setups: RAIDZ2 made of 4 drives RAIDZ2 made of 6 drives The first option wastes more disk space but can survive a JBOD failure whereas the second is more space effective but the system goes down when a JBOD goes down. Each of the JBOD comes with dual controllers, redundant fans and power supplies so do I need to be paranoid and use option #1? Of course it also gives us more IOPs but high end logging devices should take care of that I think that the answer depends on the impact to your business if data is temporarily not available. If your business can not survive data being temporarily not available (for hours or even a week) then the more conserative approach may be warranted. If you have a service contract which assures that a service tech will show up quickly with replacement hardware in hand, then this may also influence the decision which should be made. Another consideration is that since these JBODs connect to a server, the data will also be unavailable when the server is down. The server being down may in fact be a more significant factor than a JBOD being down. 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] need hint on pool setup
what is your main application for ZFS? e.g. just NFS or iSCSI for home dir or VM? or Window client? Is performance important? or space is more important? what is the memory of your server? do you want to use ZIL or L2ARC? what is your backup or DR plan? You need to answer all these question first my 2c On 1/31/2012 3:44 PM, Thomas Nau wrote: Dear all We have two JBODs with 20 or 21 drives available per JBOD hooked up to a server. We are considering the following setups: RAIDZ2 made of 4 drives RAIDZ2 made of 6 drives The first option wastes more disk space but can survive a JBOD failure whereas the second is more space effective but the system goes down when a JBOD goes down. Each of the JBOD comes with dual controllers, redundant fans and power supplies so do I need to be paranoid and use option #1? Of course it also gives us more IOPs but high end logging devices should take care of that Thanks for any hint Thomas ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- Hung-Sheng Tsao Ph D. Founder Principal HopBit GridComputing LLC cell: 9734950840 http://laotsao.blogspot.com/ http://laotsao.wordpress.com/ http://blogs.oracle.com/hstsao/ attachment: laotsao.vcf___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zfs send and receive - how are people driving them?
I guess many of you on this list are using zfs send and receive to move data from one machine to another, or between pools on the same machine, for redundancy or for other purposes, and perhaps over ssh or other channels. Is there any standard way of doing this that people use, or has everyone made up her/his own mechanism? There are a bunch of flags that you want to get right regarding snapshots, meta data, and other things, if you are doing incremental snapshot transfers you want to make sure you don't remove any old snapshots before they are safely in the destination pool, and a probably a lot of other stuff, so a tested and tried out standard tool would be nice. Is there one? Thanks for any pointers! /ragge ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] HP JBOD D2700 - ok?
Just to follow up on this, in case there are others interested: The D2700s seems to work quite ok for us. We have four issues with them, all of which we will ignore for now: - They hang when I insert an Intel SSD SATA (!) disk (I wanted to test, both for log device and cache device, and I had those around). This could probably be fixed with a firmware upgrade, but: - It seems the firmware can't be upgraded if you don't have one of a few special HP raid cards! Silly! - The LEDs on the disks: On the first bay it is turned off, on the rest it is turned on. They all flash at activity. I have no idea why this is, and I know to little about SAS chassises to even guess. This could possibly change with a firmware upgrade of the chassis controllers, but maybe not. - In Solaris 11, the /dev/chassis/HP-D2700-SAS-AJ941A.xx.../Drive_bay_NN is supposed to contain a soft link to the device for the disk in the bay. This doesn't seem to work for bay 0. It may be related to the previous problem, but maybe not. (We may buy a HP raid card just to be able to upgrade their firmware.) If we have had the time we probably would have tested some other jbods too, but we need to get those rolling soon, and these seem good enough. We have tested them with multipathed SAS, using a single LSI SAS 9205-8e HBA and connecting the two ports on the HBA to the two controllers in the D2700. To get multipathing, you need to configure the scsi_vhci driver, in /kernel/drv/scsi_vhci.conf for sol10 or /etc/driver/drv/scsi_vhci.conf for sol11-x86. To get better performance, you probably want to use load-balance=logical-block instead of load-balance=round-robin. See examples below. You may also need to run stmsboot -e to enable multipathing. I still haven't figured out what that does (more than updating /etc/vfstab and /etc/dumpdates which you typically don't use with ifs), maybe nothing. Thanks to all that have helped with input! /ragge - For solaris 10u8 and later, in /kernel/drv/scsi_vhci.conf.DIST: ### ... device-type-scsi-options-list = HP D2700 SAS AJ941A, symmetric-option, HP EG, symmetric-option; # HP 600 GB 2.5 inch SAS disks: EG0600FBDBU, EG0600FBDSR symmetric-option = 0x100; device-type-mpxio-options-list = device-type=HP D2700 SAS AJ941A, load-balance-options=logical-block-options, device-type=HP EG, load-balance-options=logical-block-options; # HP 600 GB 2.5 inch SAS disks: EG0600FBDBU, EG0600FBDSR logical-block-options=load-balance=logical-block, region-size=20; ... ### For solaris 11, in /etc/driver/drv/scsi_vhci.conf on x86 (in /kernel/drv/scsi_vhci.conf.DIST on sparc?): ### ... #load-balance=round-robin; load-balance=logical-block; region-size=20; ... scsi-vhci-failover-override = HP D2700 SAS AJ941A, f_sym, HP EG, f_sym; # HP 600 GB 2.5 inch SAS disks: EG0600FBDBU, EG0600FBDSR ### ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] HP JBOD D2700 - ok?
what is the server you attach to D2700? the hp spec for d2700 did not include solaris, so not sure how you get support from hp:-( Sent from my iPad On Jan 31, 2012, at 20:25, Ragnar Sundblad ra...@csc.kth.se wrote: Just to follow up on this, in case there are others interested: The D2700s seems to work quite ok for us. We have four issues with them, all of which we will ignore for now: - They hang when I insert an Intel SSD SATA (!) disk (I wanted to test, both for log device and cache device, and I had those around). This could probably be fixed with a firmware upgrade, but: - It seems the firmware can't be upgraded if you don't have one of a few special HP raid cards! Silly! - The LEDs on the disks: On the first bay it is turned off, on the rest it is turned on. They all flash at activity. I have no idea why this is, and I know to little about SAS chassises to even guess. This could possibly change with a firmware upgrade of the chassis controllers, but maybe not. - In Solaris 11, the /dev/chassis/HP-D2700-SAS-AJ941A.xx.../Drive_bay_NN is supposed to contain a soft link to the device for the disk in the bay. This doesn't seem to work for bay 0. It may be related to the previous problem, but maybe not. (We may buy a HP raid card just to be able to upgrade their firmware.) If we have had the time we probably would have tested some other jbods too, but we need to get those rolling soon, and these seem good enough. We have tested them with multipathed SAS, using a single LSI SAS 9205-8e HBA and connecting the two ports on the HBA to the two controllers in the D2700. To get multipathing, you need to configure the scsi_vhci driver, in /kernel/drv/scsi_vhci.conf for sol10 or /etc/driver/drv/scsi_vhci.conf for sol11-x86. To get better performance, you probably want to use load-balance=logical-block instead of load-balance=round-robin. See examples below. You may also need to run stmsboot -e to enable multipathing. I still haven't figured out what that does (more than updating /etc/vfstab and /etc/dumpdates which you typically don't use with ifs), maybe nothing. Thanks to all that have helped with input! /ragge - For solaris 10u8 and later, in /kernel/drv/scsi_vhci.conf.DIST: ### ... device-type-scsi-options-list = HP D2700 SAS AJ941A, symmetric-option, HP EG, symmetric-option; # HP 600 GB 2.5 inch SAS disks: EG0600FBDBU, EG0600FBDSR symmetric-option = 0x100; device-type-mpxio-options-list = device-type=HP D2700 SAS AJ941A, load-balance-options=logical-block-options, device-type=HP EG, load-balance-options=logical-block-options; # HP 600 GB 2.5 inch SAS disks: EG0600FBDBU, EG0600FBDSR logical-block-options=load-balance=logical-block, region-size=20; ... ### For solaris 11, in /etc/driver/drv/scsi_vhci.conf on x86 (in /kernel/drv/scsi_vhci.conf.DIST on sparc?): ### ... #load-balance=round-robin; load-balance=logical-block; region-size=20; ... scsi-vhci-failover-override = HP D2700 SAS AJ941A, f_sym, HP EG, f_sym; # HP 600 GB 2.5 inch SAS disks: EG0600FBDBU, EG0600FBDSR ### ___ 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] HP JBOD D2700 - ok?
You will definitely want to have a Smart Array card (p411 or p811) on hand to update the firmware on the enclosure. Make sure you're on firmware version 0131. You may also want to update the disk firmware at the same time. I have multipath and my drive LEDs work well enough to perform drive identification. I'm on NexentaStor, though. My scsi_vhci.conf looks like: scsi-vhci-failover-override = HP EG0300, f_sym, HP MO0400, f_sym, HP DG0300, f_sym, HP DH072, f_sym; device-type-mpxio-options-list= device-type=HP EG0300, load-balance-options=logical-block-options, device-type=HP DG0300, load-balance-options=logical-block-options; logical-block-options=load-balance=logical-block, region-size=18; -- Edmund White ewwh...@mac.com On 1/31/12 7:25 PM, Ragnar Sundblad ra...@csc.kth.se wrote: Just to follow up on this, in case there are others interested: The D2700s seems to work quite ok for us. We have four issues with them, all of which we will ignore for now: - They hang when I insert an Intel SSD SATA (!) disk (I wanted to test, both for log device and cache device, and I had those around). This could probably be fixed with a firmware upgrade, but: - It seems the firmware can't be upgraded if you don't have one of a few special HP raid cards! Silly! - The LEDs on the disks: On the first bay it is turned off, on the rest it is turned on. They all flash at activity. I have no idea why this is, and I know to little about SAS chassises to even guess. This could possibly change with a firmware upgrade of the chassis controllers, but maybe not. - In Solaris 11, the /dev/chassis/HP-D2700-SAS-AJ941A.xx.../Drive_bay_NN is supposed to contain a soft link to the device for the disk in the bay. This doesn't seem to work for bay 0. It may be related to the previous problem, but maybe not. (We may buy a HP raid card just to be able to upgrade their firmware.) If we have had the time we probably would have tested some other jbods too, but we need to get those rolling soon, and these seem good enough. We have tested them with multipathed SAS, using a single LSI SAS 9205-8e HBA and connecting the two ports on the HBA to the two controllers in the D2700. To get multipathing, you need to configure the scsi_vhci driver, in /kernel/drv/scsi_vhci.conf for sol10 or /etc/driver/drv/scsi_vhci.conf for sol11-x86. To get better performance, you probably want to use load-balance=logical-block instead of load-balance=round-robin. See examples below. You may also need to run stmsboot -e to enable multipathing. I still haven't figured out what that does (more than updating /etc/vfstab and /etc/dumpdates which you typically don't use with ifs), maybe nothing. Thanks to all that have helped with input! /ragge - For solaris 10u8 and later, in /kernel/drv/scsi_vhci.conf.DIST: ### ... device-type-scsi-options-list = HP D2700 SAS AJ941A, symmetric-option, HP EG, symmetric-option; # HP 600 GB 2.5 inch SAS disks: EG0600FBDBU, EG0600FBDSR symmetric-option = 0x100; device-type-mpxio-options-list = device-type=HP D2700 SAS AJ941A, load-balance-options=logical-block-options, device-type=HP EG, load-balance-options=logical-block-options; # HP 600 GB 2.5 inch SAS disks: EG0600FBDBU, EG0600FBDSR logical-block-options=load-balance=logical-block, region-size=20; ... ### For solaris 11, in /etc/driver/drv/scsi_vhci.conf on x86 (in /kernel/drv/scsi_vhci.conf.DIST on sparc?): ### ... #load-balance=round-robin; load-balance=logical-block; region-size=20; ... scsi-vhci-failover-override = HP D2700 SAS AJ941A, f_sym, HP EG, f_sym; # HP 600 GB 2.5 inch SAS disks: EG0600FBDBU, EG0600FBDSR ### ___ 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] HP JBOD D2700 - ok?
Hi Ragge, On 1/02/12 11:25 AM, Ragnar Sundblad wrote: Just to follow up on this, in case there are others interested: ... To get multipathing, you need to configure the scsi_vhci driver, in /kernel/drv/scsi_vhci.conf for sol10 or /etc/driver/drv/scsi_vhci.conf for sol11-x86. To get better performance, you probably want to use load-balance=logical-block instead of load-balance=round-robin. See examples below. You may also need to run stmsboot -e to enable multipathing. I still haven't figured out what that does (more than updating /etc/vfstab and /etc/dumpdates which you typically don't use with ifs), maybe nothing. The supported way to enable MPxIO is to run # /usr/sbin/stmsboot -e You shouldn't need to do this for mpt_sas HBAs such as your 9205 controllers; we enable MPxIO by default on them. If you _do_ edit scsi_vhci.conf, you need to utter # /usr/sbin/stmsboot -u in order for those changes to be correctly propagated. You can (and should) read about this in the stmsboot(1m) manpage, and there's more information available in my blog post http://blogs.oracle.com/jmcp/entry/on_stmsboot_1m James C. McPherson -- Oracle http://www.jmcp.homeunix.com/blog ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] HP JBOD D2700 - ok?
On 1 feb 2012, at 02:38, Hung-Sheng Tsao (laoTsao) wrote: what is the server you attach to D2700? It is different Sun/Oracle X4NN0s, x86-86 boxes. the hp spec for d2700 did not include solaris, so not sure how you get support from hp:-( We don't. :-( /ragge ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] HP JBOD D2700 - ok?
On 1 feb 2012, at 02:43, Edmund White wrote: You will definitely want to have a Smart Array card (p411 or p811) on hand to update the firmware on the enclosure. Make sure you're on firmware version 0131. You may also want to update the disk firmware at the same time. I have multipath and my drive LEDs work well enough to perform drive identification. Ok, thanks for the tip! I will try that. We are at 0103 currently. I'm on NexentaStor, though. My scsi_vhci.conf looks like: scsi-vhci-failover-override = HP EG0300, f_sym, HP MO0400, f_sym, HP DG0300, f_sym, HP DH072, f_sym; Yes, you have to list all devices that you want to match, except for those (pretty few) that the driver itself matches. It uses partial string matching, so you can abbreviate to match more devices. I guess the EG0300 is 300 GB disks, and that the above won't match for example the 600 GB drives beginning with EG600. device-type-mpxio-options-list= device-type=HP EG0300, load-balance-options=logical-block-options, device-type=HP DG0300, load-balance-options=logical-block-options; logical-block-options=load-balance=logical-block, region-size=18; Interesting, they have listed those two in a separate device-type-mpxio-options-list instead of setting load-balance and region-size globally. I guess they don't want load-balance=logical-block for the MO0400 or DH072, whatever those are. /ragge ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] HP JBOD D2700 - ok?
Ragnar, Which Intel SSD do you use? We use 320 and 710. We have bad experience with 510 in the past Yes, logical-block make it faster in MPxIO setup. If you are using 9205-8E, you don't need to use stmsboot -e By default, mpt_sas driver for 9205-8E is already MPxIO enable. stmsboot-e is useful to enable old 3G HBA MPxIO feature. With MPxIO like the following setup, you can protect HBA, cable, JBOD SAS IO module failure http://dataonstorage.com/dataon-solutions/125-unified-storage-system.html the slot 0 issue is related to their SES mapping in JBOD FW. It seems their FW is not genius enough with other HBA under solaris 11. Using HP HBA and their tool should fix it. Rocky -Original Message- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Ragnar Sundblad Sent: Tuesday, January 31, 2012 5:26 PM To: Ragnar Sundblad Cc: zfs-discuss@opensolaris.org Discuss Subject: Re: [zfs-discuss] HP JBOD D2700 - ok? Just to follow up on this, in case there are others interested: The D2700s seems to work quite ok for us. We have four issues with them, all of which we will ignore for now: - They hang when I insert an Intel SSD SATA (!) disk (I wanted to test, both for log device and cache device, and I had those around). This could probably be fixed with a firmware upgrade, but: - It seems the firmware can't be upgraded if you don't have one of a few special HP raid cards! Silly! - The LEDs on the disks: On the first bay it is turned off, on the rest it is turned on. They all flash at activity. I have no idea why this is, and I know to little about SAS chassises to even guess. This could possibly change with a firmware upgrade of the chassis controllers, but maybe not. - In Solaris 11, the /dev/chassis/HP-D2700-SAS-AJ941A.xx.../Drive_bay_NN is supposed to contain a soft link to the device for the disk in the bay. This doesn't seem to work for bay 0. It may be related to the previous problem, but maybe not. (We may buy a HP raid card just to be able to upgrade their firmware.) If we have had the time we probably would have tested some other jbods too, but we need to get those rolling soon, and these seem good enough. We have tested them with multipathed SAS, using a single LSI SAS 9205-8e HBA and connecting the two ports on the HBA to the two controllers in the D2700. To get multipathing, you need to configure the scsi_vhci driver, in /kernel/drv/scsi_vhci.conf for sol10 or /etc/driver/drv/scsi_vhci.conf for sol11-x86. To get better performance, you probably want to use load-balance=logical-block instead of load-balance=round-robin. See examples below. You may also need to run stmsboot -e to enable multipathing. I still haven't figured out what that does (more than updating /etc/vfstab and /etc/dumpdates which you typically don't use with ifs), maybe nothing. Thanks to all that have helped with input! /ragge - For solaris 10u8 and later, in /kernel/drv/scsi_vhci.conf.DIST: ### ... device-type-scsi-options-list = HP D2700 SAS AJ941A, symmetric-option, HP EG, symmetric-option; # HP 600 GB 2.5 inch SAS disks: EG0600FBDBU, EG0600FBDSR symmetric-option = 0x100; device-type-mpxio-options-list = device-type=HP D2700 SAS AJ941A, load-balance-options=logical-block-options, device-type=HP EG, load-balance-options=logical-block-options; # HP 600 GB 2.5 inch SAS disks: EG0600FBDBU, EG0600FBDSR logical-block-options=load-balance=logical-block, region-size=20; ... ### For solaris 11, in /etc/driver/drv/scsi_vhci.conf on x86 (in /kernel/drv/scsi_vhci.conf.DIST on sparc?): ### ... #load-balance=round-robin; load-balance=logical-block; region-size=20; ... scsi-vhci-failover-override = HP D2700 SAS AJ941A, f_sym, HP EG, f_sym; # HP 600 GB 2.5 inch SAS disks: EG0600FBDBU, EG0600FBDSR ### ___ 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] HP JBOD D2700 - ok?
Hi Edmund, On Jan 31, 2012, at 5:43 PM, Edmund White wrote: You will definitely want to have a Smart Array card (p411 or p811) on hand to update the firmware on the enclosure. Make sure you're on firmware version 0131. You may also want to update the disk firmware at the same time. I have multipath and my drive LEDs work well enough to perform drive identification. I'm on NexentaStor, though. My scsi_vhci.conf looks like: scsi-vhci-failover-override = HP EG0300, f_sym, HP MO0400, f_sym, HP DG0300, f_sym, HP DH072, f_sym; Please file a support ticket with Nexenta and ask them to update issue #5664 to add these to the default list. device-type-mpxio-options-list= device-type=HP EG0300, load-balance-options=logical-block-options, device-type=HP DG0300, load-balance-options=logical-block-options; logical-block-options=load-balance=logical-block, region-size=18; IMHO, it is easier to set the default to logical-block in scsi_vhci.conf, which is exactly what Nexenta issue #5664 does. NB, the changes for issue #5664 can't be added to the NexentaStor 3.x branch. Look for them in the next major release. For new installations, you can add the changes, though. -- richard -- Edmund White ewwh...@mac.com On 1/31/12 7:25 PM, Ragnar Sundblad ra...@csc.kth.se wrote: Just to follow up on this, in case there are others interested: The D2700s seems to work quite ok for us. We have four issues with them, all of which we will ignore for now: - They hang when I insert an Intel SSD SATA (!) disk (I wanted to test, both for log device and cache device, and I had those around). This could probably be fixed with a firmware upgrade, but: - It seems the firmware can't be upgraded if you don't have one of a few special HP raid cards! Silly! - The LEDs on the disks: On the first bay it is turned off, on the rest it is turned on. They all flash at activity. I have no idea why this is, and I know to little about SAS chassises to even guess. This could possibly change with a firmware upgrade of the chassis controllers, but maybe not. - In Solaris 11, the /dev/chassis/HP-D2700-SAS-AJ941A.xx.../Drive_bay_NN is supposed to contain a soft link to the device for the disk in the bay. This doesn't seem to work for bay 0. It may be related to the previous problem, but maybe not. (We may buy a HP raid card just to be able to upgrade their firmware.) If we have had the time we probably would have tested some other jbods too, but we need to get those rolling soon, and these seem good enough. We have tested them with multipathed SAS, using a single LSI SAS 9205-8e HBA and connecting the two ports on the HBA to the two controllers in the D2700. To get multipathing, you need to configure the scsi_vhci driver, in /kernel/drv/scsi_vhci.conf for sol10 or /etc/driver/drv/scsi_vhci.conf for sol11-x86. To get better performance, you probably want to use load-balance=logical-block instead of load-balance=round-robin. See examples below. You may also need to run stmsboot -e to enable multipathing. I still haven't figured out what that does (more than updating /etc/vfstab and /etc/dumpdates which you typically don't use with ifs), maybe nothing. Thanks to all that have helped with input! /ragge - For solaris 10u8 and later, in /kernel/drv/scsi_vhci.conf.DIST: ### ... device-type-scsi-options-list = HP D2700 SAS AJ941A, symmetric-option, HP EG, symmetric-option; # HP 600 GB 2.5 inch SAS disks: EG0600FBDBU, EG0600FBDSR symmetric-option = 0x100; device-type-mpxio-options-list = device-type=HP D2700 SAS AJ941A, load-balance-options=logical-block-options, device-type=HP EG, load-balance-options=logical-block-options; # HP 600 GB 2.5 inch SAS disks: EG0600FBDBU, EG0600FBDSR logical-block-options=load-balance=logical-block, region-size=20; ... ### For solaris 11, in /etc/driver/drv/scsi_vhci.conf on x86 (in /kernel/drv/scsi_vhci.conf.DIST on sparc?): ### ... #load-balance=round-robin; load-balance=logical-block; region-size=20; ... scsi-vhci-failover-override = HP D2700 SAS AJ941A, f_sym, HP EG, f_sym; # HP 600 GB 2.5 inch SAS disks: EG0600FBDBU, EG0600FBDSR ### ___ 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 Performance and Training richard.ell...@richardelling.com +1-760-896-4422 ___ zfs-discuss mailing
Re: [zfs-discuss] HP JBOD D2700 - ok?
Hello Rocky! On 1 feb 2012, at 03:07, Rocky Shek wrote: Ragnar, Which Intel SSD do you use? We use 320 and 710. We have bad experience with 510 in the past I tried with Intel X25-M 160 and 80 GB and a X25-E 64 GB (only because that was what I had in my drawer). I am not sure which one of them that made it lock up, maybe it was all of them. Since the head is a X4150 with 8 slots and a plain LSI SAS HBA, I put them in there instead and went ahead. Yes, logical-block make it faster in MPxIO setup. If you are using 9205-8E, you don't need to use stmsboot -e By default, mpt_sas driver for 9205-8E is already MPxIO enable. stmsboot-e is useful to enable old 3G HBA MPxIO feature. Ok, thanks for the information, good! So it just changes the mpxio-disable=yes/no in the driver.conf files? With MPxIO like the following setup, you can protect HBA, cable, JBOD SAS IO module failure http://dataonstorage.com/dataon-solutions/125-unified-storage-system.html That is almost what I do, except that I only have one HBA. We haven't seen many HBAs fail during the years, none actually, so we thought it was overkill to double those too. But maybe we are wrong? the slot 0 issue is related to their SES mapping in JBOD FW. It seems their FW is not genius enough with other HBA under solaris 11. Using HP HBA and their tool should fix it. Thanks! I will try to update the firmware in the chassis and see what that gives. I really hesitate to use HP HBAs - if they have changed anything from the OEM firmware it is hard to tell how compatible they are. /ragge ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] HP JBOD D2700 - ok?
Hello James! On 1 feb 2012, at 02:43, James C. McPherson wrote: The supported way to enable MPxIO is to run # /usr/sbin/stmsboot -e You shouldn't need to do this for mpt_sas HBAs such as your 9205 controllers; we enable MPxIO by default on them. If you _do_ edit scsi_vhci.conf, you need to utter # /usr/sbin/stmsboot -u in order for those changes to be correctly propagated. You can (and should) read about this in the stmsboot(1m) manpage, and there's more information available in my blog post http://blogs.oracle.com/jmcp/entry/on_stmsboot_1m Thanks for the info! I have read the man page a few times, and I actually did read your blog post too when I started with this and just googled around like crazy. I still don't really get what stmsboot -u actually does (and if - and if so how much - this differs between x86 and sparc). Would it be impolite to ask you to elaborate on this a little? /ragge ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] HP JBOD D2700 - ok?
On 1/02/12 12:40 PM, Ragnar Sundblad wrote: ... I still don't really get what stmsboot -u actually does (and if - and if so how much - this differs between x86 and sparc). Would it be impolite to ask you to elaborate on this a little? Not at all. Here goes. /usr/sbin/stmsboot -u arms the mpxio-upgrade service so that it runs when you reboot. The mpxio-upgrade service #1 execs /lib/stmsboot_util -u, to do the actual rewriting of vfstab #2 execs metadevadm if you have any SVM metadevices #3 updates your boot archive #4 execs dumpadm to ensure that you have the correct dump device listed in /etc/dumpadm.conf #5 updates your boot path property on x64, if required. /lib/stmsboot_util is the binary which does the heavy lifting. Each vfstab device element is checked - the cache that was created prior to the reboot is used to identify where the new paths are. You can see this cache by running strings over /etc/mpxio/devid_path.cache. This is all available for your perusal at http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/stmsboot/ cheers, James -- Oracle http://www.jmcp.homeunix.com/blog ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS Comes to OS X Courtesy of Apple's Former Chief ZFS Architect
It looks like the first iteration has finally launched... http://tenscomplement.com/our-products/zevo-silver-edition http://www.macrumors.com/2012/01/31/zfs-comes-to-os-x-courtesy-of-apples-former-chief-zfs-architect ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
