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

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

[Anne Mulhern]

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?

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?

(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

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

[James Bottomley]

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()

> 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.

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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Anne Mulhern]

----- Original Message -----
> From: "James Bottomley" <James.Bottomley@HansenPartnership.com>
> To: "Anne Mulhern" <amulhern@redhat.com>, linux-scsi@vger.kernel.org
> 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@vger.kernel.org
> > 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[James Bottomley]

On Wed, 2016-01-13 at 15:15 -0500, Anne Mulhern wrote:
> 
> 
> 
> ----- Original Message -----
> > From: "James Bottomley" <James.Bottomley@HansenPartnership.com>
> > To: "Anne Mulhern" <amulhern@redhat.com>, 
> > linux-scsi@vger.kernel.org
> > 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.

Yes, that's what I meant.

> 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?

There is only one bay per device since a physical disk can't be in more
than one bay at once.  Why do you think it was set up to allow >1?

James

> - 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@vger.kernel.org
> > > 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@vger.kernel.org
> > 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Anne Mulhern]

----- Original Message -----
> From: "James Bottomley" <James.Bottomley@HansenPartnership.com>
> To: "Anne Mulhern" <amulhern@redhat.com>
> Cc: linux-scsi@vger.kernel.org
> Sent: Wednesday, January 13, 2016 3:30:07 PM
> Subject: Re: /sys/.../enclosure_device:<something> ?
> 
> On Wed, 2016-01-13 at 15:15 -0500, Anne Mulhern wrote:
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "James Bottomley" <James.Bottomley@HansenPartnership.com>
> > > To: "Anne Mulhern" <amulhern@redhat.com>,
> > > linux-scsi@vger.kernel.org
> > > 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.
> 
> Yes, that's what I meant.
> 
> > 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?
> 
> There is only one bay per device since a physical disk can't be in more
> than one bay at once.  Why do you think it was set up to allow >1?
> 

Purely because the naming scheme for the directory,
'enclosure_device:<identifier>' supports more than 1.

This directory pops up in the directory of the parent device representing
a block device, and should represent just the bay for that device, AFAIU.

The most compelling reason for this naming scheme to support more than 1
subdirectory is if it is necessary, i.e., there are more than one possible.

That might be true if my understanding of the block device's parent device's
meaning is incorrect or if something else doesn't mean what I think it means.

- mulhern

> James
> 
> > - 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@vger.kernel.org
> > > > 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@vger.kernel.org
> > > 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@vger.kernel.org
> > 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[James Bottomley]

On Fri, 2016-01-15 at 14:32 -0500, Anne Mulhern wrote:
> 
> 
> 
> ----- Original Message -----
> > From: "James Bottomley" <James.Bottomley@HansenPartnership.com>
> > To: "Anne Mulhern" <amulhern@redhat.com>
> > Cc: linux-scsi@vger.kernel.org
> > Sent: Wednesday, January 13, 2016 3:30:07 PM
> > Subject: Re: /sys/.../enclosure_device:<something> ?
> > 
> > On Wed, 2016-01-13 at 15:15 -0500, Anne Mulhern wrote:
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "James Bottomley" <James.Bottomley@HansenPartnership.com>
> > > > To: "Anne Mulhern" <amulhern@redhat.com>,
> > > > linux-scsi@vger.kernel.org
> > > > 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.
> > 
> > Yes, that's what I meant.
> > 
> > > 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?
> > 
> > There is only one bay per device since a physical disk can't be in
> > more
> > than one bay at once.  Why do you think it was set up to allow >1?
> > 
> 
> Purely because the naming scheme for the directory,
> 'enclosure_device:<identifier>' supports more than 1.
> 
> This directory pops up in the directory of the parent device
> representing
> a block device, and should represent just the bay for that device,
> AFAIU.
> 
> The most compelling reason for this naming scheme to support more
> than 1
> subdirectory is if it is necessary, i.e., there are more than one
> possible.
> 
> That might be true if my understanding of the block device's parent
> device's
> meaning is incorrect or if something else doesn't mean what I think 
> it means.

The enclosure_device: is a namespace prefix.  It's sysfs, so we can't
have two files of the same name and <identifier> is supplied by page 7
of the enclosure device ... it could be anything.  The only way to
ensure we don't have a clash is to use a namespace prefix.

James

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

[Anne Mulhern]

Thanks.

Are there any guidelines or rules available regarding the use
of namespaces in sysfs that you can refer me to?

I maintain pyudev, which is a python wrapper around libudev
with some added conveniences, and I'm wondering if there is
some functionality around namespaces that could be usefully
added.

- mulhern

----- Original Message -----
> From: "James Bottomley" <James.Bottomley@HansenPartnership.com>
> To: "Anne Mulhern" <amulhern@redhat.com>
> Cc: linux-scsi@vger.kernel.org
> Sent: Friday, January 15, 2016 2:38:05 PM
> Subject: Re: /sys/.../enclosure_device:<something> ?
> 
> On Fri, 2016-01-15 at 14:32 -0500, Anne Mulhern wrote:
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "James Bottomley" <James.Bottomley@HansenPartnership.com>
> > > To: "Anne Mulhern" <amulhern@redhat.com>
> > > Cc: linux-scsi@vger.kernel.org
> > > Sent: Wednesday, January 13, 2016 3:30:07 PM
> > > Subject: Re: /sys/.../enclosure_device:<something> ?
> > > 
> > > On Wed, 2016-01-13 at 15:15 -0500, Anne Mulhern wrote:
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "James Bottomley" <James.Bottomley@HansenPartnership.com>
> > > > > To: "Anne Mulhern" <amulhern@redhat.com>,
> > > > > linux-scsi@vger.kernel.org
> > > > > 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.
> > > 
> > > Yes, that's what I meant.
> > > 
> > > > 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?
> > > 
> > > There is only one bay per device since a physical disk can't be in
> > > more
> > > than one bay at once.  Why do you think it was set up to allow >1?
> > > 
> > 
> > Purely because the naming scheme for the directory,
> > 'enclosure_device:<identifier>' supports more than 1.
> > 
> > This directory pops up in the directory of the parent device
> > representing
> > a block device, and should represent just the bay for that device,
> > AFAIU.
> > 
> > The most compelling reason for this naming scheme to support more
> > than 1
> > subdirectory is if it is necessary, i.e., there are more than one
> > possible.
> > 
> > That might be true if my understanding of the block device's parent
> > device's
> > meaning is incorrect or if something else doesn't mean what I think
> > it means.
> 
> The enclosure_device: is a namespace prefix.  It's sysfs, so we can't
> have two files of the same name and <identifier> is supplied by page 7
> of the enclosure device ... it could be anything.  The only way to
> ensure we don't have a clash is to use a namespace prefix.
> 
> James
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[James Bottomley]

On Mon, 2016-01-18 at 13:24 -0500, Anne Mulhern wrote:
> Thanks.
> 
> Are there any guidelines or rules available regarding the use
> of namespaces in sysfs that you can refer me to?

I don't believe there are any, sorry.  What I'm describing isn't really
true namespacing, it's using namespace techniques to avoid potential
unique name clashes.  There's nothing formally documented about this in
sysfs-rules.txt;  it is simply the type of thing that often gets done
to avoid unique name issues in filesystems.

James

> I maintain pyudev, which is a python wrapper around libudev
> with some added conveniences, and I'm wondering if there is
> some functionality around namespaces that could be usefully
> added.
> 
> - mulhern
> 
> ----- Original Message -----
> > From: "James Bottomley" <James.Bottomley@HansenPartnership.com>
> > To: "Anne Mulhern" <amulhern@redhat.com>
> > Cc: linux-scsi@vger.kernel.org
> > Sent: Friday, January 15, 2016 2:38:05 PM
> > Subject: Re: /sys/.../enclosure_device:<something> ?
> > 
> > On Fri, 2016-01-15 at 14:32 -0500, Anne Mulhern wrote:
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "James Bottomley" <James.Bottomley@HansenPartnership.com>
> > > > To: "Anne Mulhern" <amulhern@redhat.com>
> > > > Cc: linux-scsi@vger.kernel.org
> > > > Sent: Wednesday, January 13, 2016 3:30:07 PM
> > > > Subject: Re: /sys/.../enclosure_device:<something> ?
> > > > 
> > > > On Wed, 2016-01-13 at 15:15 -0500, Anne Mulhern wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "James Bottomley" <
> > > > > > James.Bottomley@HansenPartnership.com>
> > > > > > To: "Anne Mulhern" <amulhern@redhat.com>,
> > > > > > linux-scsi@vger.kernel.org
> > > > > > 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.
> > > > 
> > > > Yes, that's what I meant.
> > > > 
> > > > > 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?
> > > > 
> > > > There is only one bay per device since a physical disk can't be
> > > > in
> > > > more
> > > > than one bay at once.  Why do you think it was set up to allow
> > > > >1?
> > > > 
> > > 
> > > Purely because the naming scheme for the directory,
> > > 'enclosure_device:<identifier>' supports more than 1.
> > > 
> > > This directory pops up in the directory of the parent device
> > > representing
> > > a block device, and should represent just the bay for that
> > > device,
> > > AFAIU.
> > > 
> > > The most compelling reason for this naming scheme to support more
> > > than 1
> > > subdirectory is if it is necessary, i.e., there are more than one
> > > possible.
> > > 
> > > That might be true if my understanding of the block device's
> > > parent
> > > device's
> > > meaning is incorrect or if something else doesn't mean what I
> > > think
> > > it means.
> > 
> > The enclosure_device: is a namespace prefix.  It's sysfs, so we
> > can't
> > have two files of the same name and <identifier> is supplied by
> > page 7
> > of the enclosure device ... it could be anything.  The only way to
> > ensure we don't have a clash is to use a namespace prefix.
> > 
> > James
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux
> > -scsi" in
> > the body of a message to majordomo@vger.kernel.org
> > 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>