Did you try devlabel

Did you try devlabel

[Gary_Lerhaupt]

Anybody happen to try devlabel with their hotplug devices?  Is it reasonable
to have the (rather small) patches accepted?  

Gary Lerhaupt
ESG Linux Solutions
Dell Computer Corporation



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: Did you try devlabel

[Gary_Lerhaupt]

I put it up tarred instead of a source RPM.  hope this makes it easier for
all


http://domsch.com/linux/devlabel/

gary

-----Original Message-----
From: Lerhaupt, Gary 
Sent: Thursday, September 12, 2002 1:46 PM
To: 'Linux-hotplug-devel@lists.sourceforge.net'
Subject: Did you try devlabel


Anybody happen to try devlabel with their hotplug devices?  Is it reasonable
to have the (rather small) patches accepted?  

Gary Lerhaupt
ESG Linux Solutions
Dell Computer Corporation



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Did you try devlabel

[Greg KH]

On Thu, Sep 12, 2002 at 01:46:24PM -0500, Gary_Lerhaupt@Dell.com wrote:
> Anybody happen to try devlabel with their hotplug devices?  Is it reasonable
> to have the (rather small) patches accepted?  

I looked briefly at the patches and did have some minor questions:
	- is this for SCSI based devices only?
	- is this for symlinks to those scsi devices only?

thanks,

greg k-h


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: Did you try devlabel

[Gary_Lerhaupt]

No, ide and scsi based (scsi, usb, firewire, etc).  Basically, anything
that'll show in /proc/partitions.  As well, (an aside), but it can do
rawdevice connections as well to assure consistency with those.  
-Gary

-----Original Message-----
From: Greg KH [mailto:greg@kroah.com] 
Sent: Thursday, September 12, 2002 5:15 PM
To: Gary_Lerhaupt@exchange.dell.com
Cc: Linux-hotplug-devel@lists.sourceforge.net
Subject: Re: Did you try devlabel


On Thu, Sep 12, 2002 at 01:46:24PM -0500, Gary_Lerhaupt@Dell.com wrote:
> Anybody happen to try devlabel with their hotplug devices?  Is it 
> reasonable to have the (rather small) patches accepted?

I looked briefly at the patches and did have some minor questions:
	- is this for SCSI based devices only?
	- is this for symlinks to those scsi devices only?

thanks,

greg k-h



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Did you try devlabel

[Greg KH]

On Thu, Sep 12, 2002 at 06:21:11PM -0500, Gary_Lerhaupt@Dell.com wrote:
> No, ide and scsi based (scsi, usb, firewire, etc).  Basically, anything
> that'll show in /proc/partitions.  As well, (an aside), but it can do
> rawdevice connections as well to assure consistency with those.  

Have you thought about how this will interact with driverfs in 2.5?

Other than that, it looks ok to me, but I really don't have a need for
it, do others?

thanks,

greg k-h


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: Did you try devlabel

[Gary_Lerhaupt]

Assuming I get the rc.sysinit patch right, you can create a symlink to your
swap partition and then use this in /etc/fstab.  In fact, you can do this
for all your partitions to keep from failures if your device names shuffle
(basically where e2label wont let you label).  Separately its also good for
rawdevices. 

Hotplug wise, I think it is also valuable especially if you hotplug various
storage types.

As for driverfs, which I haven't really worked with, I figured I could start
using that directly for the UUIDs instead of the methods that are currently
being used (scsi inquiries, /proc/ide/hd#/identify)

gary

-----Original Message-----
From: Greg KH [mailto:greg@kroah.com] 
Sent: Thursday, September 12, 2002 6:27 PM
To: Gary_Lerhaupt@exchange.dell.com
Cc: Linux-hotplug-devel@lists.sourceforge.net
Subject: Re: Did you try devlabel


On Thu, Sep 12, 2002 at 06:21:11PM -0500, Gary_Lerhaupt@Dell.com wrote:
> No, ide and scsi based (scsi, usb, firewire, etc).  Basically, 
> anything that'll show in /proc/partitions.  As well, (an aside), but 
> it can do rawdevice connections as well to assure consistency with those.

Have you thought about how this will interact with driverfs in 2.5?

Other than that, it looks ok to me, but I really don't have a need for it,
do others?

thanks,

greg k-h



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Did you try devlabel

[Greg KH]

On Thu, Sep 12, 2002 at 06:38:59PM -0500, Gary_Lerhaupt@Dell.com wrote:
> Assuming I get the rc.sysinit patch right, you can create a symlink to your
> swap partition and then use this in /etc/fstab.  In fact, you can do this
> for all your partitions to keep from failures if your device names shuffle
> (basically where e2label wont let you label).  Separately its also good for
> rawdevices. 

Ah, that's very handy, I know lots of people that have been wanting that
for some time.  Does this also trigger on the SCSI disk add that I think
/sbin/hotplug gets called on in 2.5?

> Hotplug wise, I think it is also valuable especially if you hotplug various
> storage types.

Ok, I'll trust you on this one :)

> As for driverfs, which I haven't really worked with, I figured I could start
> using that directly for the UUIDs instead of the methods that are currently
> being used (scsi inquiries, /proc/ide/hd#/identify)

Yes, the UUIDs should soon be exported through driverfs, and that will
help you out a lot.  I think there are some SCSI developers working on
this right now.

Hm, as you are really only needing a hook into the existing hotplug
scripts to run your program, isn't there some generic way of doing this
already without needing a patch?

thanks,

greg k-h


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: Did you try devlabel

[Gary_Lerhaupt]

I haven't written the scsi hotplug patch but it should be trivial.  On all
storage hotplugs, at the very bottom of the add & remove calls, there should
be:

if [ -x /sbin/devlabel ]; then
	devlabel restart
fi

If you can think of a less intrusive method to get this kicked off on all
add/remove events, I am game.

gary

-----Original Message-----
From: Greg KH [mailto:greg@kroah.com]
Sent: Friday, September 13, 2002 12:50 AM
To: Gary_Lerhaupt@exchange.dell.com
Cc: Linux-hotplug-devel@lists.sourceforge.net
Subject: Re: Did you try devlabel

Ah, that's very handy, I know lots of people that have been wanting that
for some time.  Does this also trigger on the SCSI disk add that I think
/sbin/hotplug gets called on in 2.5?

Yes, the UUIDs should soon be exported through driverfs, and that will
help you out a lot.  I think there are some SCSI developers working on
this right now.

Hm, as you are really only needing a hook into the existing hotplug
scripts to run your program, isn't there some generic way of doing this
already without needing a patch?

thanks,

greg k-h



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Did you try devlabel

[David Brownell]

I'd kind of thought that this stuff should happen through some
kind of "disk" hotplug event.   And maybe the natural spot for
such calls is driverfs: for devices in the "disk" class; but it
could also be called directly from each of the bus-specific disk
drivers (IDE, SCSI-over-{SCSI,USB,IDE,Firewire,...}, Flash, etc).

Given such a hotplug event, I think this package would simplify
a bit -- "/etc/hotplug/disk.agent" would replace patches for all
current (and future) bus agents.  I'd prefer such a structure;
it could still handle SCSI of course.

I'd see SCSI hotplug as responsible for loading the SCSI disk or
cdrom driver ... and when those drivers found a device, they'd
trigger a "disk" hotplug event.  Which would have the benefit of
whatever smarts the bus-specific disk driver could share.

There've been a lot of discussions about how to identify disks,
multipathing and so on.  I think the conclusion was that some
user mode policy input was needed.  Your scsi_unique_id program
seems like it'd be important for a number of SCSI configs, and
could grow to handle the bigger ones.

- Dave

p.s. Was /dev/hda supposed to work as input to 'scsi_unique_id'?
      the man page implied it should, but that didn't work.
      And I'd expect /usr/sbin for such sysadin tools.


Gary_Lerhaupt@Dell.com wrote:
> I haven't written the scsi hotplug patch but it should be trivial.  On all
> storage hotplugs, at the very bottom of the add & remove calls, there should
> be:
> 
> if [ -x /sbin/devlabel ]; then
> 	devlabel restart
> fi
> 
> If you can think of a less intrusive method to get this kicked off on all
> add/remove events, I am game.
> 
> gary
> 




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: Did you try devlabel

[Gary_Lerhaupt]

Yeah, a generic disk.agent would probably be a good idea to handle the
devlabel calls and the rest of the agents could funnel through that or
whatever.  As for scsi_unique_id, its only good for SCSI devices.  I think
the man page should call this out clearly.  For IDE things, you get the
serial number from words 10-19 of /proc/ide/hd[a-z]/identify.

So, in the meantime, to get devlabel officially working through hotplug,
what direction should be taken?

Gary

-----Original Message-----
From: David Brownell [mailto:david-b@pacbell.net]
Sent: Friday, September 13, 2002 2:19 PM
To: Gary_Lerhaupt@exchange.dell.com
Cc: greg@kroah.com; Linux-hotplug-devel@lists.sourceforge.net
Subject: Re: Did you try devlabel


I'd kind of thought that this stuff should happen through some
kind of "disk" hotplug event.   And maybe the natural spot for
such calls is driverfs: for devices in the "disk" class; but it
could also be called directly from each of the bus-specific disk
drivers (IDE, SCSI-over-{SCSI,USB,IDE,Firewire,...}, Flash, etc).

Given such a hotplug event, I think this package would simplify
a bit -- "/etc/hotplug/disk.agent" would replace patches for all
current (and future) bus agents.  I'd prefer such a structure;
it could still handle SCSI of course.

I'd see SCSI hotplug as responsible for loading the SCSI disk or
cdrom driver ... and when those drivers found a device, they'd
trigger a "disk" hotplug event.  Which would have the benefit of
whatever smarts the bus-specific disk driver could share.

There've been a lot of discussions about how to identify disks,
multipathing and so on.  I think the conclusion was that some
user mode policy input was needed.  Your scsi_unique_id program
seems like it'd be important for a number of SCSI configs, and
could grow to handle the bigger ones.

- Dave

p.s. Was /dev/hda supposed to work as input to 'scsi_unique_id'?
      the man page implied it should, but that didn't work.
      And I'd expect /usr/sbin for such sysadin tools.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Did you try devlabel

[Greg KH]

On Fri, Sep 13, 2002 at 12:18:47PM -0700, David Brownell wrote:
> I'd kind of thought that this stuff should happen through some
> kind of "disk" hotplug event.   And maybe the natural spot for
> such calls is driverfs: for devices in the "disk" class; but it
> could also be called directly from each of the bus-specific disk
> drivers (IDE, SCSI-over-{SCSI,USB,IDE,Firewire,...}, Flash, etc).

Yes, /sbin/hotplug events for class adds and removals is coming soon to
the 2.5 kernel.  I just have to get all this other stuff done first....

greg k-h


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Did you try devlabel

[David Brownell]

Greg KH wrote:
> On Fri, Sep 13, 2002 at 12:18:47PM -0700, David Brownell wrote:
> 
>>I'd kind of thought that this stuff should happen through some
>>kind of "disk" hotplug event.   And maybe the natural spot for
>>such calls is driverfs: for devices in the "disk" class; but it
>>could also be called directly from each of the bus-specific disk
>>drivers (IDE, SCSI-over-{SCSI,USB,IDE,Firewire,...}, Flash, etc).
> 
> 
> Yes, /sbin/hotplug events for class adds and removals is coming soon to
> the 2.5 kernel.  I just have to get all this other stuff done first....

Well if you're committed to delivering that, I won't worry too much.  :)
Unless that's something Gary could help with?

It's good to know I'm not the only one thinking along those particular
lines, in any case.  Though it does seem to beg a question:  I think
Gary's current stuff works on 2.4, but driverfs won't.

- Dave





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Did you try devlabel

[Greg KH]

On Fri, Sep 13, 2002 at 01:18:14PM -0700, David Brownell wrote:
> Though it does seem to beg a question:  I think Gary's current stuff
> works on 2.4, but driverfs won't.

Yes, and I think /sbin/hotplug will start changing a lot for 2.5, once
it starts to interact with driverfs.  I've been ignoring the ability for
things to work the same on 2.4, as driverfs isn't going to be
backported.

Hm, once this support gets added to the kernel, it might be time to fork
the script into two versions.

greg k-h


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: Did you try devlabel

[Gary_Lerhaupt]

So, in the meantime for us 2.4 folks, would it not be best to add the
patches as I have them and then work it differently for the 2.5
implementation?

gary

-----Original Message-----
From: Greg KH [mailto:greg@kroah.com]
Sent: Friday, September 13, 2002 3:39 PM
To: David Brownell
Cc: Gary_Lerhaupt@exchange.dell.com;
Linux-hotplug-devel@lists.sourceforge.net
Subject: Re: Did you try devlabel


On Fri, Sep 13, 2002 at 01:18:14PM -0700, David Brownell wrote:
> Though it does seem to beg a question:  I think Gary's current stuff
> works on 2.4, but driverfs won't.

Yes, and I think /sbin/hotplug will start changing a lot for 2.5, once
it starts to interact with driverfs.  I've been ignoring the ability for
things to work the same on 2.4, as driverfs isn't going to be
backported.

Hm, once this support gets added to the kernel, it might be time to fork
the script into two versions.

greg k-h



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Did you try devlabel

[Greg KH]

On Fri, Sep 13, 2002 at 03:52:24PM -0500, Gary_Lerhaupt@Dell.com wrote:
> So, in the meantime for us 2.4 folks, would it not be best to add the
> patches as I have them and then work it differently for the 2.5
> implementation?

That's David's call, not mine :)

thanks,

greg (pass the buck) k-h


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Did you try devlabel

[David Brownell]

Greg KH wrote:
> On Fri, Sep 13, 2002 at 03:52:24PM -0500, Gary_Lerhaupt@Dell.com wrote:
> 
>>So, in the meantime for us 2.4 folks, would it not be best to add the
>>patches as I have them and then work it differently for the 2.5
>>implementation?
> 
> 
> That's David's call, not mine :)
> 
> thanks,
> 
> greg (pass the buck) k-h

Gee thanks Greg... ;)


The functionality is needed, and will be needed even more in the
future.  So I'm keen on having it in some form.

The hard question is how, and my preferred answer would be to
focus all user mode tools/training/docs on what'll be the 2.5
solution ("disk" hotplug), with the 2.4 based solution mostly
a "workalike" or even backport.  Certainly "evolve together"
so the end-user (and sysadmin) experience isn't of two rather
divergent solutions, but just one (that likely works better on
2.5 systems but behaves also on 2.4).

Sounds to me like a 2.5ish start isn't that far away, so
a short delay seems reasonable to me.  So far as I can tell,
"devlabel" is in that interesting stage where it's not got
that many users (yet) and so it's easy to change based
on experience/feedback ... and we really ought to seek that
feedback and use it to improve both 2.4 and 2.5 based systems.

So I'll install devlabel and run it myself for a while.  And
I encourage other folk to do so, and submit feedback to this
list over the next month or so.  At which point I think it'll
be more practical to decide in detail what the next steps are.

Gary, can you work with that approach?  And in any case,
could you provide a short email describing how devlabel
would work on different kinds of Linux systems?  I have
in mind a range, including desktop, small server, larger
servers, and so on.  Aren't there other volume management
tools a "devlabel" would need to play with?

- Dave







-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: Did you try devlabel

[Gary_Lerhaupt]

Yes, this approach is reasonable.  The differences between implementing
devlabel for 2.4 and 2.5 should be negligible.  I simply need to add some
code to check driverfs for the UUID before I go using the methods that I
currently do for 2.4.  Since I suspect working with driverfs will only
necessitate reading a file off in some directory somewhere, making this
change should be *easy*.  As far as hotplug's direction for 2.5, its really
just a matter of where to put the devlabel restart command.

In my mind, I see devlabel as an e2label replacement (good feedback
permitting) in which all linux boxes use it in the same manner.   Some
convention needs to be determined for naming symlinks but once an agreed
upon standard is set, start using the symlinks completely within fstab.  As
my original post states, though, I may need to add some code to comment out
references in fstab in the event that the symlink does not exist (which I
think is the better alternative to having your system fail to boot because
of this).

I actually intend on seeing how all this works with LVM which I have not
tried yet.  I am sure there are other management tools to consider but as
all we're really working with here are symlinks, any good management tool
should be able to handle it.  Its all just a matter of running
/sbin/devlabel restart just before you kick off the manager to ensure that
all your symlinks point to the right place.

Gary

-----Original Message-----
From: David Brownell [mailto:david-b@pacbell.net] 
Sent: Sunday, September 15, 2002 6:52 PM
To: Greg KH; Gary_Lerhaupt@exchange.dell.com
Cc: Linux-hotplug-devel@lists.sourceforge.net
Subject: Re: Did you try devlabel

The hard question is how, and my preferred answer would be to focus all user
mode tools/training/docs on what'll be the 2.5 solution ("disk" hotplug),
with the 2.4 based solution mostly a "workalike" or even backport.
Certainly "evolve together" so the end-user (and sysadmin) experience isn't
of two rather divergent solutions, but just one (that likely works better on
2.5 systems but behaves also on 2.4).

Sounds to me like a 2.5ish start isn't that far away, so
a short delay seems reasonable to me.  So far as I can tell, "devlabel" is
in that interesting stage where it's not got that many users (yet) and so
it's easy to change based on experience/feedback ... and we really ought to
seek that feedback and use it to improve both 2.4 and 2.5 based systems.

So I'll install devlabel and run it myself for a while.  And
I encourage other folk to do so, and submit feedback to this list over the
next month or so.  At which point I think it'll be more practical to decide
in detail what the next steps are.

Gary, can you work with that approach?  And in any case,
could you provide a short email describing how devlabel
would work on different kinds of Linux systems?  I have
in mind a range, including desktop, small server, larger servers, and so on.
Aren't there other volume management tools a "devlabel" would need to play
with?

- Dave








-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel