> On Jun 13, 2015, at 10:36 AM, Graham Stephens <gra...@thestephensdomain.com> > wrote: > > On 13/06/2015 15:01, Stephan Budach wrote: >> Am 13.06.15 um 14:54 schrieb Graham Stephens: >>> Perhaps another dumb question, but here goes... >>> >>> I currently have a FC disk array attached to a server acting, among >>> other things, as a Samba file server. I don't need the files serving >>> all the time, so mainly start the machine (it is normally off >>> overnight due to the noise) without the disk array turned on unless I >>> know I will need the files in advance. ZFS doesn't seem to mind as >>> long as the disks are attached/not attached at boot, and I don't try >>> turning the array on while the server is running. >>> >>> I am moving several boxes into one quieter zoned box that I would like >>> to have on 24/7, and the Samba server is intended to go into one of >>> those zones. I will eventually swap the external array over to >>> internal disks, but it isn't going to happen straight away; so what I >>> would like to ask is: >>> Is there a way for me to be able to turn the disk array on and off as >>> necessary (it will become the noisy part of the setup), without me >>> having to reboot the main box (with all the zones, etc) every time? >> >> Each FC equipment I know of will issue a FC reset upon booting and >> OmniOS will pick that up. However, there is of course also a means of >> having the OmniOS box perform a FC reset on the bus which would also >> spurr a disk discovery, after which ZFS will happily import your >> formerly exportet(!) zpool without fuss. >> >> Cheers >> > > Ah! I hadn't thought to export the zpools first. If that's all I need to do > then I'll be a very happy chap!
Yes, do make sure that the zpools are first exported (which implies an unmount of its constituent filesystems) so that the disks are properly quiesced. In FC-land and on the device level, there are a few old commands you can issue to get the view of things once you unplug your array, or plug it back in: # view configured FC drives and controllers cfgadm -al # force a re-probe of a specific (FC) controller on the driver level cfgadm -c configure <controller, eg: c3> # clean up no-longer present disk device links under /dev and /devices devfsadm -Cv disks # forcibly re-create them if for some reason they aren’t around devfsadm -v disks # if (a) drive(s) fails to show up on a known controller, send the whole thing a LIP (Loop Init Protocol) command fcinfo force-lip <controller port WWN> (the old old OLD solaris command to do this was/is luxadm -e forecelip) /dale
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
