4

I have an iSCSI disk array connected to a server (Ubuntu). When I login with

iscsiadm -m node --login -p 192.168.1.240

the device used to appear as /dev/sdb. I created a volume group with LVM using /dev/sdb, and eventually ext4 partitions on it. After a reboot the device is appearing as /dev/sdd, and I can no longer mount any of the partitions I had created. vgscan can see the VG (called a), but the devices mapped onto the partitions give an error:

vgscan
...
/dev/dm-9: read failed after 0 of 4096 at 4096: Input/output error
Found volume group "a" using metadata type lvm2

I would have thought that the system would be able to cope by itself with such a change (via the uuid of the devices), but I'm obviously missing something. So my questions are:

  • is there a way to force my iSCSI device to go back to /dev/sdb?
  • if not, is there a way to point my dev/dm-n devices to use /dev/sdd
  • what is a robust way to go about it? I have learned today how to make my iSCSI device appear with the same name (say, /dev/iscsi/array): is this what I should have done? The issue of the iSCSI device not appearing back on the same /dev/sdx device is not mentioned anywhere as far as I can tell, so perhaps I'm missing something else.

Addition: rebooting the machine has the desired effect. The device reappears at the right place. The questions remain: I'd appreciate it if anybody had any pointers so they can be answered.

4
  • JFTR except for the Input/output error everything looks fine, you may want to run vgchange -a y Dec 24, 2012 at 0:15
  • I have run vgchange as you say, what comes back is that the 5 volumes are activated (and the I/O errors). Now lvscan says, for instance, ACTIVE '/dev/a/vgrepos' [20.00 GiB] inherit, but when I try to mount that device on which I know there is a valid ext4 fs, I get invalid block error. Dec 24, 2012 at 7:43
  • Are you sure your disk array has no problems? The I/O error seems to indicate that there is either a error with the exported disks and/or with the network connection? Dec 24, 2012 at 9:21
  • Yes, I'm sure. Rebooting the server caused the disk to appear again at /dev/sdb which solved the problem. The question now is whether there is any way to make the process resilient against device name changes. Dec 24, 2012 at 9:25

2 Answers 2

2

I'm answering my own questions after some further research.

  • First of all, as far as I can tell, one cannot affect on which sdx device a given SCSI device will appear. The decision is take by the kernel. One solution is, as pointed out by Andreas Florath, to use a more permanent name. So the answer to the first bullet is NO.
  • If the device has changed name and you get dm-n errors, refresh the volume group with vgchange VGNAME --refresh and the errors will go away. Now you can mount the logical volumes as you used to.
  • A robust manner to go about the problem is to identify a persistent device ID before starting with LVM. The uuid-type of names are however not the most convenient to use. Then follow a recipe like the one given here http://jablonskis.org/2011/persistent-iscsi-lun-device-name/ to have udev create a name like /dev/iscsi/NAME.
1
1

Do not use drive names like /dev/sdX for this kind of usage. As you detected, they might (and will) change over and over again.

Have a look at the /dev/disk/by-id directory. The entries here are unique and stay the same - even after a reboot, because the information is taken only from the disks.

3
  • I cannot vote the answer up. It addresses what to do if I had to start from scratch, not the rest. But thanks for that. Dec 26, 2012 at 18:53
  • @GiuseppeVacanti: After re-reading your question I'm thinking about using udev for this. There are some resources about this - but I personally never tried this. Dec 26, 2012 at 19:15
  • This OP's question wasn't really what I was looking for, but this answer turned out to be the answer I needed. Thank you. Dec 16, 2013 at 18:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .