Re: [zfs-discuss] LSI SAS3081E = unstable drive numbers?
Hi Kent: So, in using the lsiutil utility, what do I find, but the following option: (this was under the hidden option 15) 12. Change (enable/disable) persistence I have not had a chance to try it, but it says the default is Enabled. Let me know if you try it. Paul Kent Watsen wrote: Paul Jochum wrote: What the lsiutil does for me is clear the persistent mapping for all of the drives on a card. Since James confirms that I'm doomed to ad hoc methods tracking device-ids to bays, I'm interested in knowing if somehow your ability to clear the persistent mapping for *all* of the drives on the card somehow gets you to a stable-state? Seems to me that, if the tool is run from the BIOS, like the LSI Configuration Utility, then it kind defeats the uptime that I'm trying to achieve by having a RAID system in the first place... Is it, by chance, a user land program? I don't know of a way to disable the mapping completely (but that does sound like a nice option). Since SUN is reselling this card now (that is how I got my cards), I wonder if they can put in a request to LSI to provide this enhancement? Yes, please! - can someone from SUN please request LSI to add a feature to selectively disable their card's persistent drive mapping feature? Thanks, Kent ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] LSI SAS3081E = unstable drive numbers?
Hi Kent: I have run into the same problem before, and have worked with LSI and SUN support to fix it. LSI calls this persistant drive mapping, and here is how to clear it 1) obtain the latest version of the program lsiutil from LSI. They don't seem to have the Solaris versions on their website, but I got it by email when entering a ticket into their support system. I know that they have a version for Solaris x86 (and I believe a Sparc version also). The version I currently have is: LSI Logic MPT Configuration Utility, Version 1.52, September 7, 2007 2) Execute the lsiutil program on your target box. a) first it will ask you to select which card to use (I have multiple cards in my machine, don't know if it will ask if you only have 1 card in your box) b) then you need to select option 15 (it is a hidden option, not shown on the menu) c) then you select option 10 (Clear all persistant mappings) d) then option 0 multiple times to get out of the program e) I normally than reboot the box, and the next time it comes up, the drives are back in order. e) or (instead of rebooting) option 99, to reset the chip (causes new mappings to be established), then option 8 (to verify lower target IDs), then devfsadm. After devfsadm completes, lsiutil option 42 should display valid device names (in /dev/rdsk), and format should find the devices so that you can label them. Hope this helps. I happened to need it last night again (I normally have to run it after re-imaging a box, assuming that I don't want to save the data that was on those drives). Paul Jochum This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] LSI SAS3081E = unstable drive numbers?
Hi Kent: What the lsiutil does for me is clear the persistent mapping for all of the drives on a card. I don't know of a way to disable the mapping completely (but that does sound like a nice option). Since SUN is reselling this card now (that is how I got my cards), I wonder if they can put in a request to LSI to provide this enhancement? Paul Kent Watsen wrote: Hi Paul, Already in my LSI Configuration Utility I have an option to clear the persistent mapping for drives not present, but then the card resumes its normal persistent-mapping logic. What I really want is to disable to persistent mapping logic completely - is the `lsiutil` doing that for you? Thanks, Kent Paul Jochum wrote: Hi Kent: I have run into the same problem before, and have worked with LSI and SUN support to fix it. LSI calls this persistant drive mapping, and here is how to clear it 1) obtain the latest version of the program lsiutil from LSI. They don't seem to have the Solaris versions on their website, but I got it by email when entering a ticket into their support system. I know that they have a version for Solaris x86 (and I believe a Sparc version also). The version I currently have is: LSI Logic MPT Configuration Utility, Version 1.52, September 7, 2007 2) Execute the lsiutil program on your target box. a) first it will ask you to select which card to use (I have multiple cards in my machine, don't know if it will ask if you only have 1 card in your box) b) then you need to select option 15 (it is a hidden option, not shown on the menu) c) then you select option 10 (Clear all persistant mappings) d) then option 0 multiple times to get out of the program e) I normally than reboot the box, and the next time it comes up, the drives are back in order. e) or (instead of rebooting) option 99, to reset the chip (causes new mappings to be established), then option 8 (to verify lower target IDs), then devfsadm. After devfsadm completes, lsiutil option 42 should display valid device names (in /dev/rdsk), and format should find the devices so that you can label them. Hope this helps. I happened to need it last night again (I normally have to run it after re-imaging a box, assuming that I don't want to save the data that was on those drives). Paul Jochum This message posted from opensolaris.org ___ 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] Suggestion/Request: ZFS-aware rm command
I agree, being able to delete the snapshot that a clone is attached to would be a nice feature. Until we get that, this is what I have done (in case this helps anyone else): 1) snapshot the filesystem 2) clone the snapshot into a seperate pool 3) only nfs mount the seperate pool with clones That way, if I need to delete a file from the backups, I can delete it from the clones. Since users only have access to the clones, they would not see the deleted files. On the other hand, the deleted files still exist in the snapshots, so I am never 'corrupting' my backups. Note, this only works for limited situations like mine I believe, not sure if there is a way to prevent users from having access to their .zfs/snapshot directory when they have local access to the zfs filesystem. Paul This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
