[ANNOUNCE] EVMS Release 1.0.1

[ANNOUNCE] EVMS Release 1.0.1

[Kevin Corry]

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.


Highlights for version 1.0.1:

v1.0.1 - 5/8/02
- Bug fixes from 1.0.0
  - RAID-5 size bug - math overflow bug in the engine when creating a RAID-5
    with objects greater than 4 GB.
  - RAID-1 engine discover - calculate size of a discovered region by getting
    the appropriate superblock field, instead of looking at the size of the
    consumed object.
  - Volume rename bug - was not releasing old name from the engine's name
    registry.
  - BBR engine - always keep BBR tables up-to-date on disk for inactive
    BBR objects.
  - Drivelinking kernel - added size checks to I/O request path.
  - Kernel compile - fixed compile errors for 2.4.9 and earlier kernels.
  - Engine fault handler - fixed compile errors on alpha, mips, and sparc.
  - Engine - get rid of unnecessary messages when reverting a compatibility
    volume.
  - Command line - corrected query for plugin extended-info.
  - S/390 segment manager - engine seg-fault when displaying plugin details.
- Simplified engine build options
  - Removed --with-evmslib_dir and --with-evmsheaders_dir, and replaced with
    built in options --libdir and --includedir


Kevin Corry
corryk@us.ibm.com
Enterprise Volume Management System
http://evms.sourceforge.net/

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