> From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org] > On Behalf Of Gary Pitman > > I have recently been handed a couple storage systems and an HPC that was > built by some guys who took off for "greener" pastures. I am new to ZFS > and gmultipath and have a few questions if anyone is willing to help.
I do openindiana. There are definitely *some* differences between OI and freeBSD, but there's going to be a lot of overlapping knowledge, too. I suggest getting on some freebsd mailing list ... or the OI mailing list, which is where most zfs experts hang out. > For starters, I have a couple failed disks so I am trying to wrap my > head around the entire system before I go ripping disks out. Good. ;-) Nothing like yanking out the wrong disk and degrading your volume beyond its survival limits. ;-) I have unfortunately never found a good way to make a particular drive blink. I have to write a one-line while loop that reads half a gigabit (64MB) which takes about a half second, and sleep half a second, and then go look at the lights. Best is to make a drive map in advance, so you're prepared before you need it... > Question: Is the output of "zpool list -v array" the definitive proof > that it is raidz3 or is that just another label? I know this: On OI, I run "zpool status" and I see at indentation level 1, the name of the pool. At indentation level 2, the type of each volume (mirror, raidz3, etc) and at indentation level 3, the individual devices within those volumes. So yes, that's what you're showing below. raidz3-0 is a raidz3 volume, composed of ... I'm going to stop there before I say something wrong. It looks like you clipped your paste, or else something weird. So that's why I stopped here. raidz3-1 is another raidz3 volume, independent of raidz3-0, and since you said you have 8 raidz3-sets, it looks like your output below is clipped. > Question 2: One of the failed disks showing at the bottom there, but > should I be alarmed by some of the disks being displayed as > multipath/diskXXp1 instead of a gptid address? I have two possible explanations. I'm not sure which (if either) is correct. So be very skeptical. It could be diskXXp1 is an aggregator of the 4 multiple paths listed below it. That would be very sane and logical, but it's been a while since I was on a zfs system with actual multi paths, and I don't remember it being like that - The way I remember it, diskXX referred to local physical disks that lacked multipath, while the gptid addresses were used for anything on scsi/iscsi and certain other drivers. The gptid addresses, if I recall correctly, were randomly generated the first time the system saw the disk, and then used to uniquely identify any individual disk regardless of how many paths could reach it or what location the disk physically moved to. The second very dubious explanation I have is the former sysadmin simply made a mistake, adding disks by their diskXX labels instead of getting the gptid stuff up and working properly. You're getting into an area now, that will be freebsd specific. My best educated guess, is that the former sysadmin made a mistake adding those diskXX disks to the pool, and that each gptid address *actually* refers to an individual disk with potentially multiple paths to reach it, and the gptid will remain constantly associated to that specific disk, even if the disk is physically moved. Since I believe the gptid's are randomly generated, I have made a habit of building systems, adding disks one at a time, and recording their id's into a map so I can later figure out which disk is in which slot. _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
