SCSI IDs are moving around.

[Marc Christensen]

I'm having fits due to the fact my 8 SAS drives seem to come up with randomly assigned IDs.

[root@storage-server ~]# lsscsi -t
[0:0:0:0]    disk    sas:0x5000cca018853651          /dev/sda
[0:0:1:0]    disk    sas:0x5000cca04132bef5          /dev/sdb
[0:0:2:0]    disk    sas:0x5000cca01f19d0d5          /dev/sdc
[0:0:3:0]    disk    sas:0x5000cca041361a19          /dev/sdd
[0:0:4:0]    disk    sas:0x5000cca0188668a9          /dev/sde
[0:0:5:0]    disk    sas:0x5000cca018817e3d          /dev/sdf
[0:0:6:0]    disk    sas:0x5000cca01f208a0d          /dev/sdg
[0:0:7:0]    disk    sas:0x5000cca0413617bd          /dev/sdh
[5:0:0:0]    disk    usb: 2-1:1.0                    /dev/sdi

< After Reboot >

[root@storage-server ~]# lsscsi -t
[0:0:0:0]    disk    sas:0x5000cca018853651          /dev/sda
[0:0:1:0]    disk    sas:0x5000cca0413617bd          /dev/sdb
[0:0:2:0]    disk    sas:0x5000cca041361a19          /dev/sdc
[0:0:3:0]    disk    sas:0x5000cca0188668a9          /dev/sdd
[0:0:4:0]    disk    sas:0x5000cca018817e3d          /dev/sde
[0:0:5:0]    disk    sas:0x5000cca01f208a0d          /dev/sdf
[0:0:6:0]    disk    sas:0x5000cca04132bef5          /dev/sdg
[0:0:7:0]    disk    sas:0x5000cca01f19d0d5          /dev/sdh
[5:0:0:0]    disk    usb: 2-1:1.0                    /dev/sdi


I'm using general release version 0.1.9
It appears to be using mdev.
I can see mdev calling dev_nodes.sh & scsi_id.sh but they appear to be called with parameters of sd[a-z] which I presume
means the /dev/sdX devices have already been created.

I seen a note in mdev.conf stating not to bother editing it as it'll get blown away...

I see comments over the years and some source code that would appear to indicate switching to udev was planned and had been implemented.

however I don't think it's in my copy of 0.1.9

What is the current best practice to tie my local filesystems and shared devices to a specific drive?

I know /dev/disk-by-id is created, but the only options I see in the TUI for drive selections are either /dev/sdX or  [0:0:X:0] both of which change at every boot.
 
The disk controller is:04:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 02)
I don't see any option in the BIOS startup to assign or lock the LUNs of the disks.

Thanks.
Marc

[Marc Smith]

Hi Marc,

Yes, in the development branch ("master") we now employ udev (actually
eudev) so this is in-place now if you want to use builds from the
master branch, which will soon be the new stable/release branch.

>
> What is the current best practice to tie my local filesystems and shared
> devices to a specific drive?
>
> I know /dev/disk-by-id is created, but the only options I see in the TUI for
> drive selections are either /dev/sdX or [0:0:X:0] both of which change at
> every boot.
>

In the TUI it may seem its going to use the short device name (eg,
/dev/sda) but when it adds the SCST device (assuming you're using
vdisk_blockio) it will use the unique /dev/disk-by-id/unique_name
value. If you're using SCST pass-through mode, this uses the H:C:T:L
value, and this would be a problem since they keep changing with your
SAS controller.

> The disk controller is:04:00.0 Serial Attached SCSI controller: LSI Logic /
> Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 02)
> I don't see any option in the BIOS startup to assign or lock the LUNs of the
> disks.

Yeah, I haven't experienced this personally, but maybe I haven't used
stand-alone SAS HBAs enough either... it seems in my past encounters,
the order/names only changed if I changed slots or connector
positions.


--Marc

>
> Thanks.
> Marc
>
> --
> You received this message because you are subscribed to the Google Groups
> "esos-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to esos-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Marc Christensen]

It makes sense, I only started seeing problems when I started trying to add cache functionality to take advantage of the
96GB of ram in the machines by changing the disk volume access methods and adding Virtual Disk Files.

I think btrfs is supposed to deal with this on its own when you let it write its own non-partitioning volume IDs to the disks.
I've never used it before, but I may create a large striped filesystem over all the disks and create Virtual disks on it.

I think I'm going to try to set up a build server on a Virtual Machine and see if I can get it to build from scratch.
The problem is my VMs use the ESOS server, so it's a chicken and egg thing ;-).


Thanks Again.
Marc