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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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: '[email protected]'
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · On Thu, Sep 12, 2002 at 01:46:24PM -0500, [email protected] 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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:[email protected]]
Sent: Thursday, September 12, 2002 5:15 PM
To: [email protected]
Cc: [email protected]
Subject: Re: Did you try devlabel
Quoted 2 lines · On Thu, Sep 12, 2002 at 01:46:24PM -0500, [email protected] 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · On Thu, Sep 12, 2002 at 06:21:11PM -0500, [email protected] 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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:[email protected]]
Sent: Thursday, September 12, 2002 6:27 PM
To: [email protected]
Cc: [email protected]
Subject: Re: Did you try devlabel
Quoted 3 lines · On Thu, Sep 12, 2002 at 06:21:11PM -0500, [email protected] 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · On Thu, Sep 12, 2002 at 06:38:59PM -0500, [email protected] 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?
Quoted 2 lines
Hotplug wise, I think it is also valuable especially if you hotplug various storage types.
Ok, I'll trust you on this one :)
Quoted 3 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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:[email protected]]
Sent: Friday, September 13, 2002 12:50 AM
To: [email protected]
Cc: [email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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.
Quoted 4 lines · [email protected] 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:
Quoted 9 lines
if [ -x
/sbin/devlabel]; then
devlabel restart
fiIf 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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:[email protected]]
Sent: Friday, September 13, 2002 2:19 PM
To: [email protected]
Cc: [email protected]; [email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · 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).
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines · Greg KH
Quoted 5 lines · 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).Yes,
/sbin/hotplugevents 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · David Brownell
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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:[email protected]]
Sent: Friday, September 13, 2002 3:39 PM
To: David Brownell
Cc: [email protected];
[email protected]
Subject: Re: Did you try devlabel
Quoted 2 lines · David Brownell
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · On Fri, Sep 13, 2002 at 03:52:24PM -0500, [email protected] 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines · Greg KH
Quoted 3 lines · On Fri, Sep 13, 2002 at 03:52:24PM -0500, [email protected] 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?
Quoted 5 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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:[email protected]]
Sent: Sunday, September 15, 2002 6:52 PM
To: Greg KH; [email protected]
Cc: [email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel