Hi Eric, On Fri, 2014-06-20 at 15:16 +0000, Eric Murphy wrote: > I'm not sure what category this would go under - > > I'm evaluating RHEL 7, so the version is whatever they're using. It > looks like kernel 3.10.0-123.1.2.el7.x86_64 with targetcli version > 2.1.fb34 > > So for testing purposes I did a few things that you wouldn't normally > do in a production environment. > > The server is running two 4 disk RAID 10 arrays on an Adaptec 8805 > controller. > > On the original setup it had /dev/sda as the boot drive, /dev/sdb as > the first array and /dev/sdc as the second array. > > So for fun I removed one of the arrays while the server was running - > I removed the array from targetcli, parted, and finally from the RAID > controller, and then swapped the disks out and made a new array, then > ran partprobe. The new array was automatically assigned /dev/sdd, > which I partitioned using parted and assigned to LUN's as block > backstores using targetcli. I saved the config. > > Then I rebooted the server. You can probably guess what happened > - /dev/sdd became /dev/sdb. Target refused to start initially, then > when I started targetcli it wiped the entire configuration. It didn't > just remove the disk that it couldn't find (/dev/sdd which is > now /dev/sdb), it removed everything. All the luns, iscsi targets, > and backstores. > > So two questions: > 1. Is this expected behavior? Yes, the ordering of /dev/sdX can change arbitrarily. > 2. Is there a better way to refer to a physical disk partition in targetcli than /dev/sdd1? You'll want to use the persistent symlinks in /dev/disk/by-id/* instead of /dev/sdX to avoid having the path change from underneath a saved target configuration. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
