Re: [Evms-announce] [ANNOUNCE] EVMS Release 1.0.1

Re: [Evms-announce] [ANNOUNCE] EVMS Release 1.0.1

[Andrew Clausen]

On Wed, May 08, 2002 at 10:18:10AM -0500, Kevin Corry wrote:
> The EVMS team is announcing the next full release of the Enterprise Volume 
> Management System. Package 1.0.1 is now available for download at the project 
> web site:
> http://www.sf.net/projects/evms
> Version 1.0.1 is primarily minor bug fixes for the previous version (1.0.0), 
> as noted below.
> 
> This release again contains an extra package for experimental File System 
> Interface Module (FSIM) support. Along with the libparted-based FSIM, there 
> is also a new JFS FSIM. The parted FSIM requires parted version 1.6.x, and 
> the JFS FSIM requires version 1.0.9 or later of the JFS utilities.

It would be nice if the jfs fsim linked against libjfs, rather than
exec()ing mkfs & friends.

(mkfs should be a frontend of libjfs)

Notice you have no error handling, etc. now?   Also, the "total system"
seems more complicated now.  (For example: how are you going to
interface the resizer, so you can find out the min/max sizes, etc?)

Also, while I'm at it: you didn't like my idea for interfacing
the parted exception system with evms properly?  I even wrote the code
for you (without testing it)... I didn't see a reply to my mail...
you(s) didn't like it?

BTW: what do you think of how libparted interfaces with libreiserfs?
There has been a lot of work, and it has all been merged properly now.
I think EVMS should do something similar.  Have a look in
libparted/fs_reiserfs.

Andrew

Re: [Evms-announce] [ANNOUNCE] EVMS Release 1.0.1

[Steve Pratt]

Andrew Clausen:
>It would be nice if the jfs fsim linked against libjfs, rather than
>exec()ing mkfs & friends.

>(mkfs should be a frontend of libjfs)

As Christoph points out in a later note, libjfs really isn't the complete
utilities.

>Notice you have no error handling, etc. now?

Do you mean message handling or error reporting.  Forking JFS mkfs gives me
just as many return codes as libparted (pass/fail) and other than possibly
some messages, this is all EVMS requires.

>Also, the "total system" seems more complicated now.  (For example: how
are you going >to interface the resizer, so you can find out the min/max
sizes, etc?)

I agree that not everything fits well into fork/exec and it was not my
first choice, but it lets the fsim work with existing JFS utilities.  When
JFS implements expand (soon) they will have to deal with this.

>Also, while I'm at it: you didn't like my idea for interfacing
>the parted exception system with evms properly?  I even wrote the code
>for you (without testing it)... I didn't see a reply to my mail...
>you(s) didn't like it?

Not that we didn't like it, just have way to many things to do.

>BTW: what do you think of how libparted interfaces with libreiserfs?
>There has been a lot of work, and it has all been merged properly now.
>I think EVMS should do something similar.  Have a look in
>libparted/fs_reiserfs.

I saw mention that you had done this.  Do you actually allow options to be
passed to the reiserfs utils, or is it still limited to defaults.  Last
time I looked the APIs in libparted didn't provide for this.  Without this
support the whole thing is rather uninteresting to us.

Steve

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net
_______________________________________________
Evms-announce mailing list
Evms-announce@lists.sourceforge.net
To subscribe/unsubscribe, please visit:
https://lists.sourceforge.net/lists/listinfo/evms-announce

Re: [Evms-announce] [ANNOUNCE] EVMS Release 1.0.1

[Andrew Clausen]

On Thu, May 09, 2002 at 09:37:56AM -0500, Steve Pratt wrote:
> >Notice you have no error handling, etc. now?
> 
> Do you mean message handling or error reporting.  Forking JFS mkfs gives me
> just as many return codes as libparted (pass/fail)

Parted gives you a lot more than pass/fail.  (Have you read doc/API?
There's a section of PedException)

> and other than possibly
> some messages, this is all EVMS requires.

Why?  EVMS's messaging system allows interactive error handling.
Why not use it?

> >Also, while I'm at it: you didn't like my idea for interfacing
> >the parted exception system with evms properly?  I even wrote the code
> >for you (without testing it)... I didn't see a reply to my mail...
> >you(s) didn't like it?
> 
> Not that we didn't like it, just have way to many things to do.

Ah, ok.

> >BTW: what do you think of how libparted interfaces with libreiserfs?
> >There has been a lot of work, and it has all been merged properly now.
> >I think EVMS should do something similar.  Have a look in
> >libparted/fs_reiserfs.
> 
> I saw mention that you had done this.  Do you actually allow options to be
> passed to the reiserfs utils, or is it still limited to defaults.

Still just defaults... I plan to do an evms-like parameters interface
soonish.  Anyway, implementing it shouldn't present any special problems.
It is orthogonal to the way libparted and libreiserfs interface themselves.

> Last
> time I looked the APIs in libparted didn't provide for this.  Without this
> support the whole thing is rather uninteresting to us.

Well, libparted is quite limited and immature, I agree.  But it has
ideas that EVMS doesn't have (and vice versa), so it's useful
("interesting") for us to be looking at each other's code.

I think the way libparted and libreiserfs work together should be
interesting to you... it only enables full reiserfs support when
libreiserfs is installed.  I don't think it's the Final Solution TM...
I think we have a problem of how to handle multiple implementions
of the same thing.  (Which can be useful: for example, reconstructive
vs incremental file system resizers, etc.)  Anyway, I'd like you to
tell me how crap the current libparted <-> libreiserfs thing is,
so I can make it better ;)

Andrew