From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: vscsi and /dev/tape/by-path Date: Tue, 11 Jan 2011 17:58:08 -0500 Message-ID: <20110111225808.GA15382@dumpdata.com> References: <20110111173724.GC14017@dumpdata.com> <20110111220057.GA11945@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: James Harper Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Wed, Jan 12, 2011 at 09:27:24AM +1100, James Harper wrote: > > > For disk, /dev/disk/by-uuid might be a better option, although it > > > depends on your requirements. For tape, my system /dev/tape/by-path > is > > > the only available option on my system, although I could probably > create > > > a /dev/tape/by-id path easily enough using the serial number or > > > something. by-id would allow the device to be moved across different > > > busses and still remain the same, but obviously breaks when a tape > drive > > > fails and has to be replaced, which happens fairly regularly. > > > > So could the fix you are thinking of, check both of those places? > > What would the syntax end up for the vSCSI? I presume not SCSI ID > > but now just the UUID (or perhaps the SCSI inq S/N? ?) > > > > Well all of those entries are just symlinks back to the /dev/stX or > /dev/sdX etc device, do I don't think we need to do anything else other > than follow the symlinks. I used os.realpath() (I think that was it) and > it works fine. I was just wondering if that was the right solution. I think yes, but we should get the input from the authors of the vscsi backend/frontend ...