On Wed, 2019-08-14 at 20:20 +0200, J. Roeleveld wrote: > On woensdag 14 augustus 2019 14:17:23 CEST Stefan G. Weichinger > wrote: > > Am 14.08.19 um 13:20 schrieb J. Roeleveld: > > > See next item, make sure you do NOT mount both at the same time. > > > > I understand and agree ;-) > > good :) > > > > > # /usr/bin/sg_vpd --page=di /dev/sdb > > > > > > > > Device Identification VPD page: > > > > Addressed logical unit: > > > > designator type: NAA, code set: Binary > > > > > > > > 0x600605b00d0ce810217ccffe19f851e8 > > > > > > Yes, this one is different. > > > > > > I checked the above ID and it looks like it is already correctly > > > configured. Is " multipathd " actually running? > > > > no! > > Then "multipath -l" will not show anything either. When you have a > chance for > downtime (and that disk can be umounted) you could try the following: > 1) stop all services requiring that "disk" to be mounted > 2) umount that "disk" > 3) start the "multipath" service > 4) run "multipath -ll" to see if there is any output > > If yes, you can access the "disk" via the newly added entry under > "/dev/ > mapper/" > If you modify "/etc/fstab" for this at the point, ensure multipath is > started > BEFORE the OS tries to mount it during boot. > > Other option (and only option of "multipath -ll" still doesn't show > anything) > is to stop the "multipath" service and leave it all as-is. > > > > If it were running correctly, you would mount " /dev/mapper/.... > > > " instead > > > of " /dev/sdc " or " /dev/sdd ". > > > > > > > In the first week of september I travel there and I have the > > > > job to > > > > reinstall that server using Debian Linux (yes, gentoo-users, I > > > > am > > > > getting OT here ;-)). > > > > > > For something that doesn't get updated/managed often, Gentoo > > > might not be > > > the best choice, I agree. > > > I would prefer Centos for this one though, as there is far more > > > info on > > > multipath from Redhat. > > > > I will consider this ... > > The choice is yours. I just haven't found much info about multipath > for other > distributions. (And I could still use a decent document/guide > describing all > the different options) > > > As I understand things here: > > > > the former admin *tried to* setup multipath and somehow got stuck. > > My guess: multipath wasn't enabled before the boot-proces would try > to mount > it, the following needs to be done (and finished) in sequence for it > to work: > > 1) The OS needs to detect the disks (/dev/sdc + /dev/sdd). This > requires > modules to be loaded and the fibrechannel disks to be detected > > 2) multipathd needs to be running and correctly identified the > fibrechannel disk > and the paths > > 3) The OS needs to mount the fibrechannel disk using the > "/dev/mapper/..." > entry created by multipath. > > I run ZFS on top of the multipath entries, which makes it all a bit > "simpler", > as the HBA module is built-in and the "zfs" services depend on > "multipath". > All the mounting is done by the zfs services. > > > That's why it isn't running and not used at all. He somehow > > mentioned > > this in an email back then when he was still working there. > > > > So currently it seems to me that the storage is attached via > > "single > > path" (is that the term here?) only. "directly"= no redundancy > > Exactly, and using non-guaranteed drive-letters. (I know for a fact > that they > can chance as I've had disks move to different letters during > subsequent boots. > I do have 12 disks getting 4 entries each, which means 48 entries ;) > > > That means using the lpfc-kernel-module to run the FibreChannel- > > adapters > > ... which failed to come up / sync with a more recent gentoo > > kernel, as > > initially mentioned. > > Are these modules not included in the main kernel? > And maybe they require firmware which, sometimes, requires specific > versions > between module/kernel versions. > > > (right now: 4.1.15-gentoo-r1 ... ) > > Old, but if it works, don't fix it. (Just don't expose it to the > internet) > > > I consider sending a Debian-OS on a SSD there and let the (low > > expertise) guy there boot from it. (or a stick). Which in fact is > > risky > > as he doesn't know anything about linux. > > I wouldn't take that risk on a production server > > > Or I simply wait for my on-site-appointment and start testing when > > I am > > there. > > Safest option. > > > Maybe I am lucky and the debian lpfc stuff works from the start. > > And > > then I could test multipath as well. > > You could test quickly with the gentoo-install present as described > above. The > config should be the same regardless. > > > I assume that maybe the adapters need a firmware update or so. > > When I added a 2nd HBA to my server, I ended up patching the firmware > on both > to ensure they were identical. > > > The current gentoo installation was done with "hardened" profile, > > not > > touched for years, no docs .... so it somehow seems way too much > > hassle > > to get it up to date again. > > I migrated a few "hardened" profile installations to non-hardened, > but it > required preparing binary packages on a VM and reinstalling the whole > lot with > a lot of effort. (empty /var/lib/portage/world, run emerge -- > depclean, do > @system with --empty and than re-populate /var/lib/portage/world and > let that > be installed using the before-mentioned binaries). > > A clean install is quicker and simpler. > > > Additionally no experts on site there, so it > > should be low maintenance anyway. > > A binary distro would be a better choice then. How far is this from > your > location? > > -- > Joost >
Note that, in my experience at least, binary distros also tend to break hard if you leave them without updates for a year or more and then try to bring them current. And they're usually harder to fix when they do. So make sure that whatever you put in is kept up to date. The stable branch of a good binary distro has a big advantage there, especially with a snapshottable filesystem, because the updates can be handed off to a trained monkey, leaving the experts free for the important stuff. But it's not a magic bullet. If you don't write good documentation and keep the system up to date you'll end up in the exact same position a few years down the road no matter what distro you use. LMP
signature.asc
Description: This is a digitally signed message part
