Re: [Evms-devel] Re: EVMS Submission for 2.5

Re: [Evms-devel] Re: EVMS Submission for 2.5

[Steve Pratt]

Christoph Hellwig wrote:

>> subdirectories were created: drivers/evms/ for the main source code,
>> and include/linux/evms/ for the header files.

>What's the reason to not have the headers under drivers/evms.

None, really. Why does md put it's headers in include/linux/raid ???
We can put them wherever.

> And why don'T you just use drivers-md like all other volume management
drivers?

Because it is getting crowded.  Why does every filesystem create it's own
directory in fs?  Maybe drivers/vm/md drivers/vm/dm drivers/vm/evms would
be better.  Again, we can put it wherever, this just seems like a logical
place.

Steve

Re: [Evms-devel] Re: EVMS Submission for 2.5

[Christoph Hellwig]

On Thu, Oct 03, 2002 at 11:09:37AM -0500, Steve Pratt wrote:
> None, really. Why does md put it's headers in include/linux/raid ???
> We can put them wherever.

MD is legacy code from the time where people still liked kernel headers
to /usr/include/linux

> Because it is getting crowded.  Why does every filesystem create it's own
> directory in fs?

Well, evms is not a single driver but a higher layer with lots of subdrivers.
E.g. once you start to use the MD code without copying it around it's in
drivers/md anyway and LVM! thæt is there currently will go away.

Re: [Evms-devel] Re: EVMS Submission for 2.5

[Greg KH]

On Fri, Oct 04, 2002 at 10:07:24AM +0200, Oliver Neukum wrote:
> On Friday 04 October 2002 00:56, Greg KH wrote:
> > On Thu, Oct 03, 2002 at 11:02:36PM +0200, Oliver Neukum wrote:
> > > Perhaps this is a misunderstanding.
> > > You need to report changes of the actual physical medium of eg. a zip
> > > drive. How you want to do this from a class driver, I fail to see.
> >
> > When a "medium" goes away from the system, it is unregistered somehow,
> > right?  So, in the disk class, that device would disappear, and cause
> > the /sbin/hotplug event.
> 
> Well, sadly this is not the case. You can put a medium into a drive and
> pull it out without the kernel ever noticing. Unless of course you try to use
> the thing. But even in this case there's no hotplug event.
> Yet user space and evms have to learn about it in the long term.
> Changing a medium can mean that a new type of medium is inserted.
> A modern zip drive goes from 100M(ro) to 250M(rw) and even 750M(rw)
> We need to know and report.

I agree we need to know this.  And if the kernel figures it out
(somehow) then userspace should also be told about this, through
/sbin/hotplug.  That's all I'm saying.


thanks,

greg k-h

Re: [Evms-devel] Re: EVMS Submission for 2.5

[Kai Henningsen]

corryk@us.ibm.com (Kevin Corry)  wrote on 04.10.02 in <02100408071900.02266@boiler>:

> On Friday 04 October 2002 08:06, Alan Cox wrote:

> > IMHO the Lindent script is broken. It should also specify a line length
> > of something like 256 so it doesnt go mashing lines.
>
> Well, currently the Lindent script specifies a line length of 80 characters.
> Should this be changed?
>
> indent -kr -i8 -ts8 -sob -l80 -ss -bs -psl "$@"
>                          ^^^^
>
> The CodingStyle document doesn't seem to specifically mention line length,
> but does imply in a couple of places that code should fit nicely on a
> 80-column, 24/25-line terminal.

I'd say that keeping the lines at 80 max is a real requirement, but  
Lindent is a bad way to implement it, as it just isn't intelligent enough  
to find good breaks in overly long lines.

MfG Kai

Re: [Evms-devel] Re: EVMS Submission for 2.5

[Kevin Corry]

On Friday 04 October 2002 08:06, Alan Cox wrote:
> On Fri, 2002-10-04 at 01:39, Kevin Corry wrote:
> > Yep, you guessed it. I'm no big fan of Lindent. In my opinion, it makes
> > some really bad choices about how to break long lines (among other
> > things), as you've kindly pointed out. But, I had to start somewhere and
> > wanted to get something out before I left for the day. Obviously the AIX
> > plugin will need some additional attention at some point.
>
> IMHO the Lindent script is broken. It should also specify a line length
> of something like 256 so it doesnt go mashing lines.

Well, currently the Lindent script specifies a line length of 80 characters. 
Should this be changed?

indent -kr -i8 -ts8 -sob -l80 -ss -bs -psl "$@"
                         ^^^^

The CodingStyle document doesn't seem to specifically mention line length, 
but does imply in a couple of places that code should fit nicely on a 
80-column, 24/25-line terminal.

-- 
Kevin Corry
corryk@us.ibm.com
http://evms.sourceforge.net/

Re: [Evms-devel] Re: EVMS Submission for 2.5

[Oliver Neukum]

On Friday 04 October 2002 00:56, Greg KH wrote:
> On Thu, Oct 03, 2002 at 11:02:36PM +0200, Oliver Neukum wrote:
> > Perhaps this is a misunderstanding.
> > You need to report changes of the actual physical medium of eg. a zip
> > drive. How you want to do this from a class driver, I fail to see.
>
> When a "medium" goes away from the system, it is unregistered somehow,
> right?  So, in the disk class, that device would disappear, and cause
> the /sbin/hotplug event.

Well, sadly this is not the case. You can put a medium into a drive and
pull it out without the kernel ever noticing. Unless of course you try to use
the thing. But even in this case there's no hotplug event.
Yet user space and evms have to learn about it in the long term.
Changing a medium can mean that a new type of medium is inserted.
A modern zip drive goes from 100M(ro) to 250M(rw) and even 750M(rw)
We need to know and report.

> This is assuming that we can detect media changes, which is a whole
> different topic that I don't want to get involved with :)

Your wishes you are entiteled to ;-) Unfortunately this is not a viable 
position speaking long term.

> > Beside that you need of course to report things like iscsi which have
> > volumes, but not really devices.
>
> But iscsi registers these "volumes" with the scsi layer, right?  If so,
> everything is fine (take a look at the driverfs scsi tree right now,
> it's a bit messy, but you get the idea.).  If iscsi doesn't register
> these volumes with the scsi layer, how does the scsi layer know to talk
> to them?

I'll look at the source.

> In other words, if the kernel knows about a type of device, which I'm
> pretty sure it has to in order to talk to it, that device will generate
> /sbin/hotplug events when it shows up and is removed.
>
> As for implementation details, if you see a type of device right now
> that does not generate these kinds of events, please let me know.

Device management is all right, but volume management operates at the
medium level, or rather in between. What do you do if somebody adds drives
to a SCSI-RAID converter.
Evms currently polls on demand. I see no way to do it differently with
the present infrastructure.

	Regards
		Oliver

Re: [Evms-devel] Re: EVMS Submission for 2.5

[Alexander Viro]

On Thu, 3 Oct 2002, Greg KH wrote:

> On Thu, Oct 03, 2002 at 11:02:36PM +0200, Oliver Neukum wrote:
> > Perhaps this is a misunderstanding.
> > You need to report changes of the actual physical medium of eg. a zip drive.
> > How you want to do this from a class driver, I fail to see.
> 
> When a "medium" goes away from the system, it is unregistered somehow,
> right?  So, in the disk class, that device would disappear, and cause
> the /sbin/hotplug event.
> 
> This is assuming that we can detect media changes, which is a whole
> different topic that I don't want to get involved with :)

Our mechanism is retroactive.  We can (kinda-sorta) tell "did the
media change happen since the last time we'd asked".  That's it.
And even that is less than accurate - many drivers decide to be on
the safe side and _always_ answer "yes, it did".

And yes, it sucks.

Re: [Evms-devel] Re: EVMS Submission for 2.5

[Greg KH]

On Thu, Oct 03, 2002 at 11:02:36PM +0200, Oliver Neukum wrote:
> Perhaps this is a misunderstanding.
> You need to report changes of the actual physical medium of eg. a zip drive.
> How you want to do this from a class driver, I fail to see.

When a "medium" goes away from the system, it is unregistered somehow,
right?  So, in the disk class, that device would disappear, and cause
the /sbin/hotplug event.

This is assuming that we can detect media changes, which is a whole
different topic that I don't want to get involved with :)

> Beside that you need of course to report things like iscsi which have
> volumes, but not really devices.

But iscsi registers these "volumes" with the scsi layer, right?  If so,
everything is fine (take a look at the driverfs scsi tree right now,
it's a bit messy, but you get the idea.).  If iscsi doesn't register
these volumes with the scsi layer, how does the scsi layer know to talk
to them?

In other words, if the kernel knows about a type of device, which I'm
pretty sure it has to in order to talk to it, that device will generate
/sbin/hotplug events when it shows up and is removed.

As for implementation details, if you see a type of device right now
that does not generate these kinds of events, please let me know.

thanks,

greg k-h

Re: [Evms-devel] Re: EVMS Submission for 2.5

[Greg KH]

On Thu, Oct 03, 2002 at 09:52:12PM +0200, Oliver Neukum wrote:
> 
> device != medium
> There's a need to report that as well.

I completely agree.  That's why I'm working on adding class support to
/sbin/hotplug which will enable all "mediums" that are added or removed
within the kernel to notify userspace of this event.

thanks,

greg k-h

Re: [Evms-devel] Re: EVMS Submission for 2.5

[Oliver Neukum]

On Thursday 03 October 2002 23:37, Greg KH wrote:
> On Thu, Oct 03, 2002 at 09:52:12PM +0200, Oliver Neukum wrote:
> > device != medium
> > There's a need to report that as well.
>
> I completely agree.  That's why I'm working on adding class support to
> /sbin/hotplug which will enable all "mediums" that are added or removed
> within the kernel to notify userspace of this event.

Ehm, how ?
Perhaps this is a misunderstanding.
You need to report changes of the actual physical medium of eg. a zip drive.
How you want to do this from a class driver, I fail to see.

Beside that you need of course to report things like iscsi which have volumes,
but not really devices.

	Regards
		Oliver

Re: [Evms-devel] Re: EVMS Submission for 2.5

[Oliver Neukum]

> All devices that have a "struct device" (which should be about
> everything these days, if not, please let me know), cause a
> /sbin/hotplug event to happen.  This event says what type of device was
> added or removed, and includes the location of the device in the
> driverfs tree so that userspace can then determine what it wants to do
> with this device.

device != medium
There's a need to report that as well. The current hotplugging model
needs some more types of events before it is ready for all types of
applications.
In fact a change of medium can radically alter features of a device,
eg. from ro to rw.

	Regards
		Oliver

Re: [Evms-devel] Re: EVMS Submission for 2.5

[Mike Tran]

Christoph Hellwig wrote:

> On Thu, Oct 03, 2002 at 10:03:41AM -0500, Shawn wrote:
> > On 10/03, Christoph Hellwig said something like:
> > > On Wed, Oct 02, 2002 at 04:33:20PM -0500, Kevin Corry wrote:
> > > > EVMS provides a new, stand-alone subsystem to the kernel
> > >
> > > i.e. it duplictes existing block layer/volume managment functionality..
> >
> > Ok, LVM1 is non-existant if that's what you're referring to. Really,
> > this replaces LVM1, but your statement WRT md still has merit. As for
> > md duplication, it has been stated already that a preferred approach
> > might be to send only core functionality bits for now, leaving that
> > out till that question can be addressed.
>
> I speak of all drivers/md/* and fs/partitions/*.
>

I have sent Neil Brown an email asking for his thoughts on a possible code
merge.
Neil is on vacation until 10/7.

I would say that the EMVS MD code & original MD code are very similar.
The most significant difference is the MD array discovery and setup code.
EVMS MD does in-kernel discovery, whereas Linux MD has both in-kernel
discovery (via fs/partitions/check.c) and user space initiated discovery
(IOCTL).

Mike Tran

Re: [Evms-devel] Re: EVMS Submission for 2.5

[Christoph Hellwig]

> (debian kernel images are always unpatched mainline)

The diff is pretty huge for 'unpatched'.

Re: [Evms-devel] Re: EVMS Submission for 2.5

[Michael Clark]

On 10/03/02 22:32, Christoph Hellwig wrote:

>>version of EVMS was released. EVMS has been accepted into the
>>Debian (Woody and Sid versions)
> 
> 
> Can't find evms in my stock woody or sid kernel images.. (neither in the
> sarge ones, btw..)

Ships as a kernel patch deb as per most other debian kernel stuff that
isn't in mainline (debian kernel images are always unpatched mainline)

This is on my sid machine

$ apt-cache pkgnames | grep evms
evms-ncurses
libevms0
libevms1
evms-cli
evms-gui
kernel-patch-evms
libevms-dev
evms-lvmutils
evms

This is on one of my woody machines

$ apt-cache pkgnames | grep evms
evms-ncurses
libevms0
libevms1
evms-cli
evms-gui
kernel-patch-evms
libevms-dev
evms-lvmutils
evms

~mc