EVMS Reiser FSIM

EVMS Reiser FSIM

[Steve Pratt]

Thanks for all the help answering questions about the reiser utilities.  I
have released the  ReiserFS FSIM into the EVMS CVS tree to be included in
our upcoming 1.1 release.   Check it out if you get a chance and feel free
to give me comments.  Also let me know if you think more options are
required on mkfs and fsck.  I only did the basics and avoided non-standard
journals since the kernel file system code is not readily available yet.
When it is, I can go back and add that support.

Steve

EVMS Development - http://www.sf.net/projects/evms
Linux Technology Center - IBM Corporation
(512) 838-9763  EMAIL: SLPratt@US.IBM.COM

Re: EVMS Reiser FSIM

[Yury Umanets]

Steve Pratt wrote:

>Thanks for all the help answering questions about the reiser utilities.  I
>have released the  ReiserFS FSIM into the EVMS CVS tree to be included in
>our upcoming 1.1 release.   Check it out if you get a chance and feel free
>to give me comments.  Also let me know if you think more options are
>required on mkfs and fsck.  I only did the basics and avoided non-standard
>journals since the kernel file system code is not readily available yet.
>When it is, I can go back and add that support.
>  
>
I thing you have released an incorrect reiserfs FSIM in theory. On my 
own you should add extra parameters
support into GNU Parted (quite simple task). And then you might be using 
it as central component of FSIM
for *ALL* filesystems. Not just for reiserfs.

Or you might be using some library (from reiserfsprogs package or from 
progsreiserfs package).

The way you have selected, might be used by an propriatary software, 
that wanted to use GPL project, not other GPL project.

BTW, I have almost done smart resizing (from partition start) in 
libreiserfs. But you can't using the libraries of third pesons, so you 
will haven't smart resizing and other features in your FSIM :))

Yet another issue. One man almost done JFS support for GNU Parted. Are 
you going to add it to EVMS too? I think yes. And probably you will do 
it in maner like ReiserFS (forking and piping).

Yury Umanets

Re: EVMS Reiser FSIM

[Steve Pratt]

Yury Umanets:
>Steve Pratt wrote:

>>Thanks for all the help answering questions about the reiser utilities.
I
>>have released the  ReiserFS FSIM into the EVMS CVS tree to be included in
>>our upcoming 1.1 release.   Check it out if you get a chance and feel
free
>>to give me comments.  Also let me know if you think more options are
>>required on mkfs and fsck.  I only did the basics and avoided
non-standard
>>journals since the kernel file system code is not readily available yet.
>>When it is, I can go back and add that support.
>>
>>
>I thing you have released an incorrect reiserfs FSIM in theory. On my
>own you should add extra parameters
>support into GNU Parted (quite simple task). And then you might be using
>it as central component of FSIM
>for *ALL* filesystems. Not just for reiserfs.

Actually I started with Parted months ago.  I released an FSIM based on the
parted ext2 and fat support (before the libreiser was added).  The problem
is that Parted is simply both inadequate and in my mind unstable.

Inadequate because it offers NO parameter passing to the file system code.
How would you ever specify and external journal location or a journal size,
Parted does not have the API support for this and I don't know when it
will.

Unstable because each of the file system utilities may or may not be a
re-implementation of the utilities written by the file system developers.
I know this to be true for the ext2 code in Parted, which has segfaulted on
me more than once while performing an expand.  I want to use the code
approved by the owners of the file system.

>Or you might be using some library (from reiserfsprogs package or from
>progsreiserfs package).

As I have stated previously, if the ReiserFS utilities package start
shipping this as part of their standard tool set, then I would consider
using it.  In fact if the file system community would come up with a
standard library interface I would be even happier.  Also, last I heard
from Andrew, this library did not contain fsck code (but maybe that has
changed).

>The way you have selected, might be used by an proprietary software,
>that wanted to use GPL project, not other GPL project.

What is your point?  This is a true statement, but was not the reason for
implementing the code this way.

>BTW, I have almost done smart resizing (from partition start) in
>libreiserfs. But you can't using the libraries of third pesons, so you
>will haven't smart resizing and other features in your FSIM :))

Do you mean moving the start of the partition?  Not really interested.  But
I am confused about your comment of not being able to use libraries of
third persons.  EVMS is GPL and could link to any GPL code it wants.  If
the libreiserfs is the *right* set of code to use, than I will use it.

>Yet another issue. One man almost done JFS support for GNU Parted. Are
>you going to add it to EVMS too? I think yes. And probably you will do
>it in maner like ReiserFS (forking and piping).

Already done.  And I have the added benefit of picking up fixes in
utilities whenever the file system developers make them.  Is this person
monitoring the JFS CVS tree to ensure that he does not miss an important
fix that might go into JFS?  Does he have the external journal support in
the library yet?  Oh wait, there is no way to pass parameters to filesystem
code in Parted, so he can't have support for it.


Thanks, for the input, but I had already considered all of these options
and decided that they were not in the best interest of the EVMS project.

Steve

Re: EVMS Reiser FSIM

[Oleg Drokin]

Hello!

On Wed, May 29, 2002 at 08:46:23AM -0500, Steve Pratt wrote:

> Thanks for all the help answering questions about the reiser utilities.  I
> have released the  ReiserFS FSIM into the EVMS CVS tree to be included in
> our upcoming 1.1 release.   Check it out if you get a chance and feel free
> to give me comments.  Also let me know if you think more options are

I am sorry, but how can I check out?
You have not provided a link to download, and latest released version
is 1.0.1 from May 7th does not contain this code, I am sure.

Bye,
    Oleg

Re: EVMS Reiser FSIM

[Adrian Phillips]

>>>>> "Oleg" == Oleg Drokin <green@namesys.com> writes:

    Oleg> I am sorry, but how can I check out?  You have not provided
    Oleg> a link to download, and latest released version is 1.0.1
    Oleg> from May 7th does not contain this code, I am sure.

http://www.google.com/search?q=evms&num=100

Its a standard sf project,

Sincerely,

Adrian Phillips

-- 
Your mouse has moved.
Windows NT must be restarted for the change to take effect.
Reboot now?  [OK]

Re: EVMS Reiser FSIM

[Oleg Drokin]

Hello!

On Thu, May 30, 2002 at 07:32:58AM +0200, Adrian Phillips wrote:
>     Oleg> I am sorry, but how can I check out?  You have not provided
>     Oleg> a link to download, and latest released version is 1.0.1
>     Oleg> from May 7th does not contain this code, I am sure.
> http://www.google.com/search?q=evms&num=100
> Its a standard sf project,

Yes, I know this.
I just want to confirm that the only way to look at it right now is to get
latest CVS version out of their cvs repository.

Bye,
    Oleg

Re: EVMS Reiser FSIM

[Yury Umanets]

Steve Pratt wrote:

>Yury Umanets:
>  
>
>>Steve Pratt wrote:
>>    
>>
>
>  
>
>>>Thanks for all the help answering questions about the reiser utilities.
>>>      
>>>
>I
>  
>
>>>have released the  ReiserFS FSIM into the EVMS CVS tree to be included in
>>>our upcoming 1.1 release.   Check it out if you get a chance and feel
>>>      
>>>
>free
>  
>
>>>to give me comments.  Also let me know if you think more options are
>>>required on mkfs and fsck.  I only did the basics and avoided
>>>      
>>>
>non-standard
>  
>
>>>journals since the kernel file system code is not readily available yet.
>>>When it is, I can go back and add that support.
>>>
>>>
>>>      
>>>
>>I thing you have released an incorrect reiserfs FSIM in theory. On my
>>own you should add extra parameters
>>support into GNU Parted (quite simple task). And then you might be using
>>it as central component of FSIM
>>for *ALL* filesystems. Not just for reiserfs.
>>    
>>
>
>Actually I started with Parted months ago.  I released an FSIM based on the
>parted ext2 and fat support (before the libreiser was added).  The problem
>is that Parted is simply both inadequate and in my mind unstable.
>
It is interesting. Did you use an stable version?

>Inadequate because it offers NO parameter passing to the file system code.
>How would you ever specify and external journal location or a journal size,
>Parted does not have the API support for this and I don't know when it
>will.
>
As I said, adding of needed changes is not very difficult.

>Unstable because each of the file system utilities may or may not be a
>re-implementation of the utilities written by the file system developers.
>I know this to be true for the ext2 code in Parted, which has segfaulted on
>me more than once while performing an expand.  I want to use the code
>approved by the owners of the file system.
>

>>Or you might be using some library (from reiserfsprogs package or from
>>progsreiserfs package).
>>    
>>
>As I have stated previously, if the ReiserFS utilities package start
>shipping this as part of their standard tool set, then I would consider
>using it.  In fact if the file system community would come up with a
>standard library interface I would be even happier.  Also, last I heard
>from Andrew, this library did not contain fsck code (but maybe that has
>changed).
>  
>
It is true. I'm working on it.

>>The way you have selected, might be used by an proprietary software,
>>that wanted to use GPL project, not other GPL project.
>>    
>>
>
>What is your point?  This is a true statement, but was not the reason for
>implementing the code this way.
>
>  
>
>>BTW, I have almost done smart resizing (from partition start) in
>>libreiserfs. But you can't using the libraries of third pesons, so you
>>will haven't smart resizing and other features in your FSIM :))
>>    
>>
>
>Do you mean moving the start of the partition?  
>
Yes, it is more difficult than resize FS from its end.

>Not really interested.  But
>I am confused about your comment of not being able to use libraries of
>third persons.
>
I just remembred your words few weeks ago.

>  EVMS is GPL and could link to any GPL code it wants.  If
>the libreiserfs is the *right* set of code to use, than I will use it.
>
>  
>
>>Yet another issue. One man almost done JFS support for GNU Parted. Are
>>you going to add it to EVMS too? I think yes. And probably you will do
>>it in maner like ReiserFS (forking and piping).
>>    
>>
>
>Already done.  And I have the added benefit of picking up fixes in
>utilities whenever the file system developers make them.  Is this person
>monitoring the JFS CVS tree to ensure that he does not miss an important
>fix that might go into JFS?  Does he have the external journal support in
>the library yet?  Oh wait, there is no way to pass parameters to filesystem
>code in Parted, so he can't have support for it.
>
>
>Thanks, for the input, 
>
You are welcome :)

>but I had already considered all of these options
>and decided that they were not in the best interest of the EVMS project.
>
>Steve
>

Re: EVMS Reiser FSIM

[Andrew Clausen]

On Wed, May 29, 2002 at 11:28:38AM -0500, Steve Pratt wrote:
> Inadequate because it offers NO parameter passing to the file system code.
> How would you ever specify and external journal location or a journal size,
> Parted does not have the API support for this and I don't know when it
> will.

Agreed.  You could have sent a patch, though.

> Unstable because each of the file system utilities may or may not be a
> re-implementation of the utilities written by the file system developers.

s/may or may not/may not/ ?

Anyway, I agree this is a problem.

> I know this to be true for the ext2 code in Parted, which has segfaulted on
> me more than once while performing an expand.

I don't recall you sending me a bug report.

> I want to use the code approved by the owners of the file system.

Me too.  Just the ext2 maintainer doesn't like this approach, so
I'm going to need to push a bit harder (and I don't have time now)

> As I have stated previously, if the ReiserFS utilities package start
> shipping this as part of their standard tool set, then I would consider
> using it.  In fact if the file system community would come up with a
> standard library interface I would be even happier.

Me too.  I suspect that's very difficult, though.

> >BTW, I have almost done smart resizing (from partition start) in
> >libreiserfs. But you can't using the libraries of third pesons, so you
> >will haven't smart resizing and other features in your FSIM :))
> 
> Do you mean moving the start of the partition?  Not really interested.  But
> I am confused about your comment of not being able to use libraries of
> third persons.  EVMS is GPL and could link to any GPL code it wants.  If
> the libreiserfs is the *right* set of code to use, than I will use it.

I believe his point was: it would be possible to write non-GPL FSIMs.
(The GPL is probably unenforcable for "plugins")

> >Yet another issue. One man almost done JFS support for GNU Parted. Are
> >you going to add it to EVMS too? I think yes. And probably you will do
> >it in maner like ReiserFS (forking and piping).
> 
> Already done.  And I have the added benefit of picking up fixes in
> utilities whenever the file system developers make them.

The obvious long-term solution is to get jfs people to make a decent
library.  fork/pipe is Wrong.

> Is this person
> monitoring the JFS CVS tree to ensure that he does not miss an important
> fix that might go into JFS?  Does he have the external journal support in
> the library yet?  Oh wait, there is no way to pass parameters to filesystem
> code in Parted, so he can't have support for it.

I have encouraged him to try to create a libjfs (that would be maintained
by the jfs community).  I don't know what he's doing with this.

In any case, I'm not advocating (and haven't for several years) that
libparted should implement file system functionality.

I personally think libparted should be split into:

	(1) a low-level "device" system library.  This should include
	identification facilities and error handling IMHO.
	(2) a file system library
	(3) a partition library

And a (meta) LVM library could be added.

I doubt I'll have time to see all of this through, but I'm certainly
encouraging people who are working on parted FS support to structure
their code to make (2) easier.  BTW: I don't care who writes each
of these components, as long as they are in a highly modular/reusable form.
However, EVMS's infrastructure is very coupled together... for example,
implementations are tied to a particular module structure, there is
one libevms that contains all the infrastructure, and the userland
is coupled to evms's linux implementation.  So far, EVMS isn't
the solution... although perhaps it shouldn't be... perhaps it should
just use the solution.  Before such a solution exists, I think the EVMS
approach is reasonable... but I would be happy if EVMS people strived
for a more modular architecture.

Just to repeat: I think libparted is just as bad, but you seem
to have the resources to solve the above problems... why don't you?

Cheers,
Andrew

Re: EVMS Reiser FSIM

[Hans Reiser]

Andrew Clausen wrote:

>On Wed, May 29, 2002 at 11:28:38AM -0500, Steve Pratt wrote:
>  
>
>>I want to use the code approved by the owners of the file system.
>>    
>>
>
>Me too.  Just the ext2 maintainer doesn't like this approach, so
>I'm going to need to push a bit harder (and I don't have time now)
>
I can imagine why he doesn't want to depend on the ext2 guys to find 
time for reading his code, and you should not assume he is without good 
reasons on this.   I have watched people try to get code into ext2.....

Hans

Re: EVMS Reiser FSIM

[Steve Pratt]

Oleg Drokin wrote:
>Hello!

>On Thu, May 30, 2002 at 07:32:58AM +0200, Adrian Phillips wrote:
>>     Oleg> I am sorry, but how can I check out?  You have not provided
>>     Oleg> a link to download, and latest released version is 1.0.1
>>     Oleg> from May 7th does not contain this code, I am sure.
>> http://www.google.com/search?q=evms&num=100
>> Its a standard sf project,

>Yes, I know this.
>I just want to confirm that the only way to look at it right now is to get
>latest CVS version out of their cvs repository.

At the moment CVS is the only place this is available.  I wanted to give
you guys a heads up that it was coming.  We should be doing a version 1.1
package in the next couple of weeks and the ReiserFS FSIM will be included
in that.

Project location is http://evms.sf.net

Steve

Re: EVMS Reiser FSIM

[Steve Pratt]

Andrew Clausen wrote:
>On Wed, May 29, 2002 at 11:28:38AM -0500, Steve Pratt wrote:
>> Inadequate because it offers NO parameter passing to the file system
code.
>> How would you ever specify and external journal location or a journal
size,
>> Parted does not have the API support for this and I don't know when it
>> will.

>Agreed.  You could have sent a patch, though.

Changing the APIs seems a little extreme for a patch, Plus there is that
time thing. :-)

>> Unstable because each of the file system utilities may or may not be a
>> re-implementation of the utilities written by the file system
developers.

>s/may or may not/may not/ ?

>Anyway, I agree this is a problem.

Agreement is good.

>> I know this to be true for the ext2 code in Parted, which has segfaulted
on
>> me more than once while performing an expand.

>I don't recall you sending me a bug report.

Yes, my bad.  Was in the middle of other things when it happened and don't
have a that configuration any more.

>> I want to use the code approved by the owners of the file system.

>Me too.  Just the ext2 maintainer doesn't like this approach, so
>I'm going to need to push a bit harder (and I don't have time now)

That is the major benefit of current EVMS implementation, I don't need the
FS developers to actually do anything.

>> As I have stated previously, if the ReiserFS utilities package start
>> shipping this as part of their standard tool set, then I would consider
>> using it.  In fact if the file system community would come up with a
>> standard library interface I would be even happier.

>Me too.  I suspect that's very difficult, though.

Well, we can always hope.

>> >BTW, I have almost done smart resizing (from partition start) in
>> >libreiserfs. But you can't using the libraries of third pesons, so you
>> >will haven't smart resizing and other features in your FSIM :))
>>
>> Do you mean moving the start of the partition?  Not really interested.
But
>> I am confused about your comment of not being able to use libraries of
>> third persons.  EVMS is GPL and could link to any GPL code it wants.  If
>> the libreiserfs is the *right* set of code to use, than I will use it.

>I believe his point was: it would be possible to write non-GPL FSIMs.
>(The GPL is probably unenforceable for "plugins")

Yes, this would allow a FSIM plugin(GPL or not) to invoke non-GPL
utilities.

>> >Yet another issue. One man almost done JFS support for GNU Parted. Are
>> >you going to add it to EVMS too? I think yes. And probably you will do
>> >it in manner like ReiserFS (forking and piping).
>>
>> Already done.  And I have the added benefit of picking up fixes in
>> utilities whenever the file system developers make them.

>The obvious long-term solution is to get jfs people to make a decent
>library.  fork/pipe is Wrong.

I agree that libraries have advantages.  When available, we can always
changes the FSIMs.  I could probably make all the necessary the changes in
a couple of days.


>> Is this person
>> monitoring the JFS CVS tree to ensure that he does not miss an important
>> fix that might go into JFS?  Does he have the external journal support
in
>> the library yet?  Oh wait, there is no way to pass parameters to
filesystem
>> code in Parted, so he can't have support for it.

>I have encouraged him to try to create a libjfs (that would be maintained
>by the jfs community).  I don't know what he's doing with this.

Again, when it is available.....

>In any case, I'm not advocating (and haven't for several years) that
>libparted should implement file system functionality.

Agree.

>I personally think libparted should be split into:

 >(1) a low-level "device" system library.  This should include
 >identification facilities and error handling IMHO.
 >(2) a file system library
 >(3) a partition library

>And a (meta) LVM library could be added.

>I doubt I'll have time to see all of this through, but I'm certainly
>encouraging people who are working on parted FS support to structure
>their code to make (2) easier.  BTW: I don't care who writes each
>of these components, as long as they are in a highly modular/reusable
form.
>However, EVMS's infrastructure is very coupled together... for example,
>implementations are tied to a particular module structure, there is
>one libevms that contains all the infrastructure, and the userland
>is coupled to evms's linux implementation.  So far, EVMS isn't
>the solution... although perhaps it shouldn't be... perhaps it should
>just use the solution.  Before such a solution exists, I think the EVMS
>approach is reasonable... but I would be happy if EVMS people strived
>for a more modular architecture.

>Just to repeat: I think libparted is just as bad, but you seem
>to have the resources to solve the above problems... why don't you?

To have multiple components and libraries interact safely and correctly
there must be a structure for each to adhere to. As you point out, one did
not exist in Linux.  EVMS created one.  Is it perfect, absolutely not, but
I think it is pretty good.  For example we added a S/390 segment manager
and a GPT segment manager without having to change a single API or line of
common code.  Must be pretty modular if we can accomplish that.  2 weeks
ago the support for Resiser was just an entry in a todo list, now it is
done, not bad since I spent less than half my time on it.

We will continue to look for ways to improve EVMS, but I think the time has
passed for major architecture changes.

Steve

Re: EVMS Reiser FSIM

[Andrew Clausen]

On Thu, May 30, 2002 at 04:56:33PM +0400, Hans Reiser wrote:
> >On Wed, May 29, 2002 at 11:28:38AM -0500, Steve Pratt wrote:
> >>I want to use the code approved by the owners of the file system.
> >
> >Me too.  Just the ext2 maintainer doesn't like this approach, so
> >I'm going to need to push a bit harder (and I don't have time now)
>
> I can imagine why he doesn't want to depend on the ext2 guys to find 
> time for reading his code, and you should not assume he is without good 
> reasons on this.

Oh absolutely, and I agree 100%.  (That was what I was saying!)

> I have watched people try to get code into ext2.....

Yeah, Ted is rather conservative.  But, it's good, because it forces
you to be minimalist :)

Andrew

Re: EVMS Reiser FSIM

[Oleg Drokin]

Hello!

On Thu, May 30, 2002 at 12:14:03PM -0500, Steve Pratt wrote:

> >Yes, I know this.
> >I just want to confirm that the only way to look at it right now is to get
> >latest CVS version out of their cvs repository.
> At the moment CVS is the only place this is available.  I wanted to give
> you guys a heads up that it was coming.  We should be doing a version 1.1
> package in the next couple of weeks and the ReiserFS FSIM will be included
> in that.

Ok, I had a look into the CVS and I have few comments.

First is that mkfs output might exceed 10k buffer you have assigned to it,
and if messages that mkfs print would exceed 10k+pipe buffer size,
then mkfs process would block and you'd never get it to return
(and I do not see you have any way to exit on timeout or send a signal
 to hung process on timeout).

Then I believe Hans asked you to display credits not only for reiserfsck, but
also for mkreiserfs. (and other reiserfs utilities if you run them).

Also just a note, you can return your own errors as negative exit codes
and pass utilities exit codes as it is.
So if the exit code of child process is bigger than 128, you can substract
this value from 255 and decide what error was caused that tool was not run.
Also you'd avoid a clash between EPERM vs FSCK_CORRECTED this way.

Ah, and please change recommended version of reiserfsprogs to 3.x.1b,
because 3.x.1a is not recommended in fact and have some known problems.

Thank you.

Bye,
    Oleg

Re: EVMS Reiser FSIM

[Andrew Clausen]

On Thu, May 30, 2002 at 02:02:06PM -0500, Steve Pratt wrote:
> >Me too.  Just the ext2 maintainer doesn't like this approach, so
> >I'm going to need to push a bit harder (and I don't have time now)
> 
> That is the major benefit of current EVMS implementation, I don't need the
> FS developers to actually do anything.

Well, I prefer to leave a system broken than to patch over it.
Leaving it broken encourages someone to fix it properly.  (And also,
saves me time from doing work that won't be used long-term)

I doubt a philosophy like that would go down to well in IBM, but
I think it's one reason for GNU/Linux's success.  (It is a good
philosophy if you don't have many resources... but IBM has different
problems... like solving real-world problems to get $$$ ;)

> >I believe his point was: it would be possible to write non-GPL FSIMs.
> >(The GPL is probably unenforceable for "plugins")
> 
> Yes, this would allow a FSIM plugin(GPL or not) to invoke non-GPL
> utilities.

Yura and rms weren't too excited about this possibility.  I'm not
either, but I think the system architecture is more important than
the licence in this case (the practical difference the licence thing
would make is sooo small...)

> >The obvious long-term solution is to get jfs people to make a decent
> >library.  fork/pipe is Wrong.
> 
> I agree that libraries have advantages.  When available, we can always
> changes the FSIMs.  I could probably make all the necessary the changes in
> a couple of days.

Right.

> To have multiple components and libraries interact safely and correctly
> there must be a structure for each to adhere to. As you point out, one did
> not exist in Linux.  EVMS created one.  Is it perfect, absolutely not, but
> I think it is pretty good.

Well, it would be nice if it was more componentized, with less
cross-dependencies, etc.  More minimalist.

> For example we added a S/390 segment manager
> and a GPT segment manager without having to change a single API or line of
> common code.  Must be pretty modular if we can accomplish that.

No, it just means your abstraction for seg managers is, actually, abstract.
(libparted has the same properties... except perhaps for flags)
I think it's good that you have those properties, but you lack some others:
(1) portability
(2) you didn't reuse linux-lvm code... which is a result of (1), right?
(The engine wants to talk to the EVMS engine, not the linux-lvm kernel
implementation.  This enforces lots of coupling, making reuse of linux-lvm
too hard)
(3) it seems complicated.  Lots of ideas that look similar aren't
actually grouped together to share code.  (FSIMs and plugins share
a lot, for example)

> 2 weeks
> ago the support for Resiser was just an entry in a todo list, now it is
> done, not bad since I spent less than half my time on it.

I'm sure you could use libreiserfs in the same amount of time,
and make something that integrates with EVMS much better ;)

> We will continue to look for ways to improve EVMS, but I think the time has
> passed for major architecture changes.

Well, I think the above are major changes, and useful to make.
That said, 'major' doesn't mean time-consuming.  It just means
lots of change.  (But, in my experience, just lots of cut&paste)

I think it's adventurous to claim that any piece of software has
"passed the time for major architecture changes".  Name one project
that declared that 5 years ago, and hasn't made such changes.
Bonus points if they were the first to implement that class of
system.  (EVMS is basically in that boat!)

Andrew

Re: EVMS Reiser FSIM

[Steve Pratt]

Oleg Drokin wrote:

>On Thu, May 30, 2002 at 12:14:03PM -0500, Steve Pratt wrote:

>Ok, I had a look into the CVS and I have few comments.

>First is that mkfs output might exceed 10k buffer you have assigned to it,
>and if messages that mkfs print would exceed 10k+pipe buffer size,
>then mkfs process would block and you'd never get it to return

Actually, I wasn't doing any read until after the completion of mkfs, so
all it had to do is exceed the pipe buffer.  Good catch.

>(and I do not see you have any way to exit on timeout or send a signal
>to hung process on timeout).

Correct, I have no way to calculate a timeout.  This would be true even if
we move to library calls.  I just have to hope reiserfs utilities never
hang. :-)

>Then I believe Hans asked you to display credits not only for reiserfsck,
but
>also for mkreiserfs. (and other reiserfs utilities if you run them).

Yes.  I'll look at adding something, but I don't want another pop-up on
mkfs. We have had some complaints about too many as it is. I'll see if I
can add something to the options panel.  Is there some specific information
you want displayed besides the version?

>Also just a note, you can return your own errors as negative exit codes
>and pass utilities exit codes as it is.
>So if the exit code of child process is bigger than 128, you can substract
>this value from 255 and decide what error was caused that tool was not
run.
>Also you'd avoid a clash between EPERM vs FSCK_CORRECTED this way.

Will look into this.

>Ah, and please change recommended version of reiserfsprogs to 3.x.1b,
>because 3.x.1a is not recommended in fact and have some known problems.

Done.

Thanks, Steve

Re: EVMS Reiser FSIM

[Oleg Drokin]

Hello!

On Fri, May 31, 2002 at 12:03:18PM -0500, Steve Pratt wrote:

> >(and I do not see you have any way to exit on timeout or send a signal
> >to hung process on timeout).
> Correct, I have no way to calculate a timeout.  This would be true even if
> we move to library calls.  I just have to hope reiserfs utilities never
> hang. :-)

Timeouts are easy. you might even use alarm()+catch SIGALARM.

> >Then I believe Hans asked you to display credits not only for reiserfsck,
> but
> >also for mkreiserfs. (and other reiserfs utilities if you run them).
> Yes.  I'll look at adding something, but I don't want another pop-up on
> mkfs. We have had some complaints about too many as it is. I'll see if I
> can add something to the options panel.  Is there some specific information
> you want displayed besides the version?

I believe Hans want Credits to be displayed.
You can discuss with him whenever he'll be satisfied by some other means

Bye,
    Oleg

Re: EVMS Reiser FSIM

[Steve Pratt]

Andrew Clausen wrote:

>On Thu, May 30, 2002 at 02:02:06PM -0500, Steve Pratt wrote:
>> >Me too.  Just the ext2 maintainer doesn't like this approach, so
>> >I'm going to need to push a bit harder (and I don't have time now)
>>
>> That is the major benefit of current EVMS implementation, I don't need
the
>> FS developers to actually do anything.

>Well, I prefer to leave a system broken than to patch over it.
>Leaving it broken encourages someone to fix it properly.  (And also,
>saves me time from doing work that won't be used long-term)

>I doubt a philosophy like that would go down to well in IBM, but
>I think it's one reason for GNU/Linux's success.  (It is a good
>philosophy if you don't have many resources... but IBM has different
>problems... like solving real-world problems to get $$$ ;)

Correct.

>> >I believe his point was: it would be possible to write non-GPL FSIMs.
>> >(The GPL is probably unenforceable for "plugins")
>>
>> Yes, this would allow a FSIM plugin(GPL or not) to invoke non-GPL
>> utilities.

>Yura and rms weren't too excited about this possibility.  I'm not
>either, but I think the system architecture is more important than
>the licence in this case (the practical difference the licence thing
>would make is sooo small...)

I agree that system architecture should be the driving force.  That said,
how I or anyone else codes a particular FSIM does not mean that someone
else can't write one differently (read still using fork/exec) and get
around the GPL.

>> >The obvious long-term solution is to get jfs people to make a decent
>> >library.  fork/pipe is Wrong.
>>
>> I agree that libraries have advantages.  When available, we can always
>> changes the FSIMs.  I could probably make all the necessary the changes
in
>> a couple of days.

>Right.

>> To have multiple components and libraries interact safely and correctly
>> there must be a structure for each to adhere to. As you point out, one
did
>> not exist in Linux.  EVMS created one.  Is it perfect, absolutely not,
but
>> I think it is pretty good.

>Well, it would be nice if it was more componentized, with less
>cross-dependencies, etc.  More minimalist.

Ideally yes, I just don't think that it is possible (reasonable).

>> For example we added a S/390 segment manager
>> and a GPT segment manager without having to change a single API or line
of
>> common code.  Must be pretty modular if we can accomplish that.

>No, it just means your abstraction for seg managers is, actually,
abstract.
>(libparted has the same properties... except perhaps for flags)
>I think it's good that you have those properties, but you lack some
others:
>(1) portability
>(2) you didn't reuse linux-lvm code... which is a result of (1), right?
>(The engine wants to talk to the EVMS engine, not the linux-lvm kernel
>implementation.  This enforces lots of coupling, making reuse of linux-lvm
>too hard)
>(3) it seems complicated.  Lots of ideas that look similar aren't
>actually grouped together to share code.  (FSIMs and plugins share
>a lot, for example)

1.portable to what?

2. No, not a result of 1.  A result of we didn't like the code. (and
apparently neither did the LVM guys since they re-wrote it as well in
LVM2).  We did re-use the bulk of MD so it is not that we couldn't have.

Coupling is not always a bad thing.  It allows us to offer greater
functionality to the user.  fisk, lvm and MD all have the ability to
destroy each others data without knowing it because that are not coupled.
In EVMS we can prevent these types of interaction problems.

3. Yes, it is complicated, that is why no one has attempted this before.

As for sharing of code, you obviously haven't looked at any of it.  Just
because an FSIM and a Segment manager have a entry point with a similar
name, doesn't mean they do the same thing.  I challenge you to go into an
FSIM and find code that is duplicated in any non-FSIM plugin.  FSIMs do
filesystems, other plugins do volumes, not the same thing.  Why does parted
have ped_device_open and ped_file_system_open? Why not 1 API, they both do
open, must be duplication of code.


><> 2 weeks
>> ago the support for Resiser was just an entry in a todo list, now it is
>> done, not bad since I spent less than half my time on it.

>I'm sure you could use libreiserfs in the same amount of time,
>and make something that integrates with EVMS much better ;)

True.

>> We will continue to look for ways to improve EVMS, but I think the time
has
>> passed for major architecture changes.

>Well, I think the above are major changes, and useful to make.
>That said, 'major' doesn't mean time-consuming.  It just means
>lots of change.  (But, in my experience, just lots of cut&paste)

Other than having FSIMs use libraries, I'm not sure what changes you are
refering to.

>I think it's adventurous to claim that any piece of software has
>"passed the time for major architecture changes".  Name one project
>that declared that 5 years ago, and hasn't made such changes.
>Bonus points if they were the first to implement that class of
>system.  (EVMS is basically in that boat!)

Point taken.  Time will tell.

Steve

Re: EVMS Reiser FSIM

[Andrew Clausen]

On Fri, May 31, 2002 at 12:40:19PM -0500, Steve Pratt wrote:
> I agree that system architecture should be the driving force.  That said,
> how I or anyone else codes a particular FSIM does not mean that someone
> else can't write one differently (read still using fork/exec) and get
> around the GPL.

FSF legal advice disagrees.  I imagine there would be courts that
rule both ways.

> 1.portable to what?

Vanilla Linux for a start!  Or Hurd, Windows, whatever...

> 2. No, not a result of 1.  A result of we didn't like the code. (and
> apparently neither did the LVM guys since they re-wrote it as well in
> LVM2).

Fair enough, but if LVM2 was coming, why not use that?

> We did re-use the bulk of MD so it is not that we couldn't have.

Ah, cool :)  However, you forked the code in the process.  Don't
you want the MD community to maintain it?

> Coupling is not always a bad thing.  It allows us to offer greater
> functionality to the user.  fisk, lvm and MD all have the ability to
> destroy each others data without knowing it because that are not coupled.
> In EVMS we can prevent these types of interaction problems.

Agreed.  But you want to make coupling as weak as possible... and I
think it's possible to have very weak coupling.

> 3. Yes, it is complicated, that is why no one has attempted this before.

Well, libparted is a "first-attempt".  (Also, what you were doing
in OS/2).

> As for sharing of code, you obviously haven't looked at any of it.  Just
> because an FSIM and a Segment manager have a entry point with a similar
> name, doesn't mean they do the same thing.  I challenge you to go into an
> FSIM and find code that is duplicated in any non-FSIM plugin.  FSIMs do
> filesystems, other plugins do volumes, not the same thing.  Why does parted
> have ped_device_open and ped_file_system_open? Why not 1 API, they both do
> open, must be duplication of code.

ped_device_open() and ped_file_system_open() are different.
One is opening a volume, the other opening a user of volume(s).
However, I think ped_disk_open() (disk means "partition table") and
ped_file_system_open() should be 1 API function.  ped_consumer_open(), or
something.

BTW: you wouldn't expect code-inside-an-FSIM to be duplicated in
a non-FSIM plugin.  I'm talking about FSIM-infrastructure and plugin
infrastructure code, and high-level code that calls that.  (Eg: UIs)

I get a headache looking at it, because you do things like:

int evms_can_shrink(object_handle_t thing) {
	...
	translate_handle(thing, &object, &type);
	...
	switch (type) {
		case DISK:
		case SEGMENT:
		case REGION:
		case EVMS_OBJECT:
			...

		case VOLUME:
			...

		default:
			...
	}
}

Like, you are sharing a single entry point with lots of different
types of objects... like, why is a volume different to a segment,
but a segment is the same as a disk?  Why is there a switch at all?
Why do you need translate_handle()?

> >Well, I think the above are major changes, and useful to make.
> >That said, 'major' doesn't mean time-consuming.  It just means
> >lots of change.  (But, in my experience, just lots of cut&paste)
> 
> Other than having FSIMs use libraries, I'm not sure what changes you are
> refering to.

See above.  (And in several other emails)

Cheers,
Andrew

Re: EVMS Reiser FSIM

[Oleg Drokin]

Hello!

On Fri, May 31, 2002 at 12:03:18PM -0500, Steve Pratt wrote:

I've spent some time today trying to get current EVMS version to run and see
what is it (live) but failed miserably.
2.4.18 kernel files for 2.4.18 cannot be compiled at all and are horribly
broken in some ways.
2.5.11 kernel files can be compiled with 2.5.11, but then evmsgui complained
that while kernel's ioctl is version 11, evms gui is expecting ioctl version 10.

Any advices on how can outside man look into current state of things on evms
without waiting for new release for several weeks?

Thank you.

Bye,
    Oleg

Re: EVMS Reiser FSIM

[Steve Pratt]

Oleg Drokin: wote:

>I've spent some time today trying to get current EVMS version to run and
see
>what is it (live) but failed miserably.
>2.4.18 kernel files for 2.4.18 cannot be compiled at all and are horribly
>broken in some ways.
>2.5.11 kernel files can be compiled with 2.5.11, but then evmsgui
complained
>that while kernel's ioctl is version 11, evms gui is expecting ioctl
version 10.

>Any advices on how can outside man look into current state of things on
evms
>without waiting for new release for several weeks?

Yes, until you mentioned this, I hadn't realized how much were in a state
of change.  The problem you are seeing (I think) is due to some changes
being made in 2.4.19 that affect our common kernel files (there aren't
many, but enough).  Here is what you need to do:

Apply the 2.4.18 common-files patch from either the 1.0.0 or 1.0.1 release
to your 2.4.18 kernel.  Then add the /usr/src/linux/drivers/evms directory
and the /usr/src/linux/include/linux/evms directory from the CVS files
(They are all new on a clean kernel).  Use the Engine as is from CVS.

2.5 is still in rough shape due to all the block layer changes and the
effects they have on EVMS.  I don't recommend using it just yet.


Let me know if you still have any problems.

Steve

Re: EVMS Reiser FSIM

[Oleg Drokin]

Hello!

On Mon, Jun 03, 2002 at 02:04:30PM -0500, Steve Pratt wrote:

> Apply the 2.4.18 common-files patch from either the 1.0.0 or 1.0.1 release
> to your 2.4.18 kernel.  Then add the /usr/src/linux/drivers/evms directory
> and the /usr/src/linux/include/linux/evms directory from the CVS files

I also copied all the other files that were in there (config.in for
menuconfig, genhd.c from drivers/block, do_mounts.c from init, etc),
was that unneeded?

That produces:
ksyms.c:319: `root_device_name' undeclared here (not in a function)
ksyms.c:319: initializer element is not constant
ksyms.c:319: (near initialization for `__ksymtab_root_device_name.value')

After I add a extern definition of that, there are other errors,
dut after some time and compile errors fixed still I get failed linkage because
fsync_inode_buffers (or something like that) is undeclared.

> Let me know if you still have any problems.

Ok, if you say I do only need to copy /usr/src/linux/drivers/evms and
/usr/src/linux/include/linux/evms contents, that won't provide me with
menu selection for EVMS, so con you please give me full list of files/subdirs
that I should copy off the cvs to clean 2.4.18 (or whatever else) tree.

Thank you.

Bye,
    Oleg

Re: EVMS Reiser FSIM

[Steve Pratt]

Oleg Drokin wrote:
>On Mon, Jun 03, 2002 at 02:04:30PM -0500, Steve Pratt wrote:

>> Apply the 2.4.18 common-files patch from either the 1.0.0 or 1.0.1
release
>> to your 2.4.18 kernel.  Then add the /usr/src/linux/drivers/evms
directory
>> and the /usr/src/linux/include/linux/evms directory from the CVS files

>I also copied all the other files that were in there (config.in for
>menuconfig, genhd.c from drivers/block, do_mounts.c from init, etc),
>was that unneeded?

No, this is the part that got you in trouble, do not copy these extra files
from CVS, they are in the evms-linux-2.4.18-common-files.patch (you did
apply this right?). get this file from the tarball for 1.0.0 or 1.0.1.


>That produces:
>ksyms.c:319: `root_device_name' undeclared here (not in a function)
>ksyms.c:319: initializer element is not constant
>ksyms.c:319: (near initialization for `__ksymtab_root_device_name.value')

>After I add a extern definition of that, there are other errors,
>dut after some time and compile errors fixed still I get failed linkage
because
>fsync_inode_buffers (or something like that) is undeclared.

>> Let me know if you still have any problems.

>Ok, if you say I do only need to copy /usr/src/linux/drivers/evms and
>/usr/src/linux/include/linux/evms contents, that won't provide me with
>menu selection for EVMS, so con you please give me full list of
files/subdirs
>that I should copy off the cvs to clean 2.4.18 (or whatever else) tree.

Yes, this should give you the menu selection because hte common-files patch
will fix up the config.in to enclude the one that will be copied when you
copy the drivers/evms directory.

Let me know if this still doesn't work.

Steve

Re: EVMS Reiser FSIM

[Steve Pratt]

Andrew Clausen wrote:
>On Fri, May 31, 2002 at 12:40:19PM -0500, Steve Pratt wrote:
>> I agree that system architecture should be the driving force.  That
said,
>> how I or anyone else codes a particular FSIM does not mean that someone
>> else can't write one differently (read still using fork/exec) and get
>> around the GPL.

>FSF legal advice disagrees.  I imagine there would be courts that
>rule both ways.

Ok,

>> 1.portable to what?

>Vanilla Linux for a start!  Or Hurd, Windows, whatever...

Vanilla Linux?  Is that some distro from Australia?  Seriously, what do you
think we are coded for?  EVMS compiles on 12 architectures and the patches
we release are for standard kernel.org kernels.  What is the problem?

>> 2. No, not a result of 1.  A result of we didn't like the code. (and
>> apparently neither did the LVM guys since they re-wrote it as well in
>> LVM2).

>Fair enough, but if LVM2 was coming, why not use that?

It wasn't.  LVM2 didn't even start until 6 months after we started coding.

>> We did re-use the bulk of MD so it is not that we couldn't have.

>Ah, cool :)  However, you forked the code in the process.  Don't
>you want the MD community to maintain it?

Yes, we would like that.  However, the current block device request queue
interface did not provide the level of interlock required by EVMS.  I know
you want less interlock, but that just isn't going to happen.

>> Coupling is not always a bad thing.  It allows us to offer greater
>> functionality to the user.  fisk, lvm and MD all have the ability to
>> destroy each others data without knowing it because that are not
coupled.
>> In EVMS we can prevent these types of interaction problems.

>Agreed.  But you want to make coupling as weak as possible... and I
>think it's possible to have very weak coupling.

I think we have done as little coupling as possible without losing
function.  Your milage may vary.

>> 3. Yes, it is complicated, that is why no one has attempted this before.

>Well, libparted is a "first-attempt".  (Also, what you were doing
>in OS/2).

Yes, libparted is definitely more advanced in this than anything else I
have seen in Linux, except EVMS :-).   OS/2 LVM was a learning experience,
enough said.

>> As for sharing of code, you obviously haven't looked at any of it.  Just
>> because an FSIM and a Segment manager have a entry point with a similar
>> name, doesn't mean they do the same thing.  I challenge you to go into
an
>> FSIM and find code that is duplicated in any non-FSIM plugin.  FSIMs do
>> filesystems, other plugins do volumes, not the same thing.  Why does
parted
>> have ped_device_open and ped_file_system_open? Why not 1 API, they both
do
>> open, must be duplication of code.

>ped_device_open() and ped_file_system_open() are different.
>One is opening a volume, the other opening a user of volume(s).
>However, I think ped_disk_open() (disk means "partition table") and
>ped_file_system_open() should be 1 API function.  ped_consumer_open(), or
>something.

>BTW: you wouldn't expect code-inside-an-FSIM to be duplicated in
>a non-FSIM plugin.  I'm talking about FSIM-infrastructure and plugin
>infrastructure code, and high-level code that calls that.  (Eg: UIs)

>I get a headache looking at it, because you do things like:

>int evms_can_shrink(object_handle_t thing) {
 >...
 >translate_handle(thing, &object, &type);
 >...
 >switch (type) {
  >case DISK:
  >case SEGMENT:
  >case REGION:
  >case EVMS_OBJECT:
   >...

  >case VOLUME:
   >...

  >default:
   >...
 >}
>}

>Like, you are sharing a single entry point with lots of different
>types of objects...

I though you were arguing that we should do more of this, make everything
single entrypoint to eliminate duplicate code?

>like, why is a volume different to a segment,
>but a segment is the same as a disk?

Because you can put a filesystem on a disk, so when you shrink a disk (bad
example, how about a segment) you don't have to shrink a filesystem,
because there isn't one, but when you shrink a Volume you might have to
shrink a file system and a segment.

>Why is there a switch at all?

Because volumes (with file systems) are a special case.

>Why do you need translate_handle()?

So we can abstract EVMS Engine internal data structure away from the UIs
over which we (EVMS team) may have no control since we provide an external
API set.  Unlike in libparted we never return internal data structure
pointers to external callers, since you never know what the dumb
programmers might do to your internal data.  Kind of like when I wrote the
FSIM to use libparted and tried to call ped_get_fs_limits (can't recall
exact API) and the API would limit the max fs size to the current size of
the device (which was not what I was looking for) so I modified the device
geometry to say the device was bigger, and this got me past all of the
internal checks.  Poor programming I know, but I was in a hurry and I fixed
it up before actually calling expand.

translate_handle simply get us back to the real internal data that was
protected from the external world, kind of like file descriptors.


>> >Well, I think the above are major changes, and useful to make.
>> >That said, 'major' doesn't mean time-consuming.  It just means
>> >lots of change.  (But, in my experience, just lots of cut&paste)
>>
>> Other than having FSIMs use libraries, I'm not sure what changes you are
>> referring to.

>See above.  (And in several other emails)

Ok.

Perhaps any continuation of this should move over to evms-devel and let the
Reiser guys get back to their file system work.


Steve

Re: EVMS Reiser FSIM

[Oleg Drokin]

Hello!

On Mon, Jun 03, 2002 at 04:03:32PM -0500, Steve Pratt wrote:
 
> Let me know if this still doesn't work.

Ok, now I am able to compile and boot the kernel, and evms gui starts up.

But now the problem is all the screens except plugin lists are empty.

Whenever I select some operation from the menu (create, convert or whatever),
I am represented with empty window that says "No items were found matching
the search criteria" (sometimes the window is persent instantly, sometimes
there is a windo with some items, but when I choose one of the items
and press "Next" button, the empty window appears).

I read the FAQ and since I run non-devfs enabled kernel, I run
evms_devnode_fixup. First time it failed:
# ./evms_devnode_fixup
evms_devnode_fixup -- updating the EVMS device node tree...
evms_devnode_fixup -- ERROR: return code from evms_update_evms_dev_tree() was -9.

Second time it succeed:
# ./evms_devnode_fixup
evms_devnode_fixup -- updating the EVMS device node tree...
evms_devnode_fixup -- Finished.

But still not a single entry in evsmgui tool.

# ./evms_gather_info
############################################################
                    Data from /proc/evms
############################################################


/proc/evms/info:
Enterprise Volume Management System: Info
EVMS info level: 5 (default).
EVMS kernel version: 1.1.0
EVMS IOCTL interface version: 10.0.0
EVMS Common Services version: 0.6.0


/proc/evms/volumes:
Enterprise Volume Management System: Volumes
major   minor          #blocks type   flags name



/proc/evms/plugins:
Enterprise Volume Management System: Plugins
 ---------Plugin----------      required services
 ----id----        version      version



############################################################
                  Data from the EVMS Engine
############################################################


./evms_gather_info: /usr/local/evms: is a directory


What should I do to get something to appear in the disks/slices/whatever
lists so I can play with it?

Thank you.

Bye,
    Oleg

Re: EVMS Reiser FSIM

[Steve Pratt]

Oleg Drokin wrote:
Hello!

>On Mon, Jun 03, 2002 at 04:03:32PM -0500, Steve Pratt wrote:

>> Let me know if this still doesn't work.

>Ok, now I am able to compile and boot the kernel, and evms gui starts up.

Progress.

>But now the problem is all the screens except plugin lists are empty.

Not good.

>Whenever I select some operation from the menu (create, convert or
whatever),
>I am represented with empty window that says "No items were found matching
>the search criteria" (sometimes the window is persent instantly, sometimes
>there is a windo with some items, but when I choose one of the items
>and press "Next" button, the empty window appears).

Yes, if there are no disks found, then there really isn't much to
configure.

>I read the FAQ and since I run non-devfs enabled kernel, I run
>evms_devnode_fixup. First time it failed:

This is actually done by the Engine every time you open the GUI or other
interface.

># ./evms_devnode_fixup
>evms_devnode_fixup -- updating the EVMS device node tree...
>evms_devnode_fixup -- ERROR: return code from evms_update_evms_dev_tree()
was -9.

Strange.

>Second time it succeed:
># ./evms_devnode_fixup
>evms_devnode_fixup -- updating the EVMS device node tree...
>evms_devnode_fixup -- Finished.

OK.

>But still not a single entry in evsmgui tool.

Yes, this won't have helped the problem.

># ./evms_gather_info

> info deleted.....

>What should I do to get something to appear in the disks/slices/whatever
>lists so I can play with it?

I need the kernel log and the Engine log (/var/log/evmsEngine.log) to be
sure what is going on, but my first guess would be that either you did not
select all of the right components in the kernel, or if you did that you
might have built them as modules and not loaded them. Specifically it looks
like the local device manager is missing.

We recommend compiling all EVMS runtime plug-in that you plan to use
directly into your kernel.  It avoid the hassle of dealing with init
ramdisks and lodaing modules at the right time.  If you are really set on
using modules, please read the 'Using EVMS with an Init-Ramdisk' section of
the HowTo.

As for which modules you should select, you must select the 'local device
manager'. On IA32 machine you almost always want the 'DOS partition
manager'  This is all you really need, although if you are just playing
around I would recommend building everything (except maybe AIX and OS/2 and
clustering).


Summary: please verify that at least 'local device manager' and 'DOS
partition manager' are built statically into the kernel, if not reconfigure
kernel and retry.  If they are, then send me the kernel and Engine logs and
I will see what is wrong.

Steve

Re: EVMS Reiser FSIM

[Oleg Drokin]

Hello!

On Tue, Jun 04, 2002 at 10:02:00AM -0500, Steve Pratt wrote:
 
> >What should I do to get something to appear in the disks/slices/whatever
> >lists so I can play with it?
> I need the kernel log and the Engine log (/var/log/evmsEngine.log) to be
> sure what is going on, but my first guess would be that either you did not
> select all of the right components in the kernel, or if you did that you
> might have built them as modules and not loaded them. Specifically it looks
> like the local device manager is missing.

Hm. Yes, I in fact had everything in modules.
But I have expected evms to load all the stuff its needed once evms main module
is loaded. 
It would be helpful if help entry on EVMS suggest evms might be loaded as
module, but then all of the other evms modules should be loaded by hand.

> We recommend compiling all EVMS runtime plug-in that you plan to use
> directly into your kernel.  It avoid the hassle of dealing with init
> ramdisks and lodaing modules at the right time.  If you are really set on

Since I am not planning to put my root on a EVMS volume yet, I think I can
go with modules setup, I only need to load all the modules, it seems.

> Summary: please verify that at least 'local device manager' and 'DOS
> partition manager' are built statically into the kernel, if not reconfigure
> kernel and retry.  If they are, then send me the kernel and Engine logs and
> I will see what is wrong.

Ok, thank you.  will try that.

Bye,
    Oleg

Re: EVMS Reiser FSIM

[Steve Pratt]

>Hm. Yes, I in fact had everything in modules.
>But I have expected evms to load all the stuff its needed once evms main
module
>is loaded.
>It would be helpful if help entry on EVMS suggest evms might be loaded as
>module, but then all of the other evms modules should be loaded by hand.

Yes, that would be nice. We are working on making this better.

>> We recommend compiling all EVMS runtime plug-in that you plan to use
>> directly into your kernel.  It avoid the hassle of dealing with init
>> ramdisks and lodaing modules at the right time.  If you are really set
on

>Since I am not planning to put my root on a EVMS volume yet, I think I can
>go with modules setup, I only need to load all the modules, it seems.

Ok, don't forget that after loading the modules that you will have to run
'evms_rediscover' to get everything picked up in the kernel.

>> Summary: please verify that at least 'local device manager' and 'DOS
>> partition manager' are built statically into the kernel, if not
reconfigure
>> kernel and retry.  If they are, then send me the kernel and Engine logs
and
>> I will see what is wrong.

>>Ok, thank you.  will try that.

I think you are almost there.  If you have any trouble after today, please
post to the evms-devel mailing list as I am leaving on a business trip in a
few hours and am not sure if/when I will have email access.

Steve