Re: /sys/.../enclosure_device:<something> ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 






----- Original Message -----
> From: "James Bottomley" <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
> To: "Anne Mulhern" <amulhern@xxxxxxxxxx>, linux-scsi@xxxxxxxxxxxxxxx
> Sent: Wednesday, January 13, 2016 2:15:05 PM
> Subject: Re: /sys/.../enclosure_device:<something> ?
> 
> On Wed, 2016-01-13 at 11:28 -0500, Anne Mulhern wrote:
> > Hi!
> > 
> > I'm looking for the most precise information available about the
> > meaning of <something>
> > and from what it is derived. I'm also interested in what the values
> > in the files in that directory
> > may mean. Could somebody point me there?
> 
> It's in drivers/misc/enclosure.c:enclosure_link_name()
> 

Thanks. I will do my best with that.

> > Also, how can there be more than one enclosure_device subdirectory
> > for the same device,
> > or, alternatively, why isn't <something> stored in a file in the more
> > regularly named directory
> > /sys/.../enclosure_device?
> 
> I'm not sure I parse the question, but if you're asking how can a
> single enclosure bay appear to have more than one device, that's when
> there are multiple paths to the device.

I'm afraid the word path is so overloaded...I'm assuming that you
are talking about a multipathed environment, where two device nodes, say
/dev/sdb, /dev/sdc correspond to the same disk, and are hence multipathed.
Of course, in that case, it makes sense that both devices should share a
bay. And that's what I observe.

If I understand you correctly, then my question is actually the opposite. Why does it
look as if the directories are set up so that there can be multiple bays
for a single device...i.e., the directory naming scheme allows me to specify
an arbitrary number of bays for /dev/sdb. It seems like there should never
be more than one?

- mulhern

> James
> 
> > (It would be nice to be able to obtain the value of <something> using
> > libudev's attribute
> > lookup facilities, but making that value a part of the specially
> > named directory enclosure_device:<something>
> > makes such a process especially difficult.)
> > 
> > Thanks,
> > 
> > - mulhern
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-scsi"
> > in
> > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux