Re: LANANA: To Pending Device Number Registrants

[Heinz J. Mauelshagen]

On Thu, May 17, 2001 at 02:35:55AM -0400, Albert D. Cahalan wrote:
> Heinz J. Mauelshag writes:
> 
> > LVM does a similar thing storing UUIDs in its private metadata
> > area on every device used by it.
> >
> > Problem is: neither MD nor LVM define a standard in Linux
> > which *needs* to be used on every device!
> >
> > It is just up to the user to configure devices with them or not.
> >
> > BTW: in case we had a Linux standard it wouldn't solve the
> > "different OS" situation mentioned in this thread either.
> >
> >
> > Generally speaking:
> > 
> > It is not the problem to reserve some space to store a uuid or
> > something at such and such location on a device.
> >
> > The problem is the lack of a standard which eventually
> > could be implemented in all OSes at some point in time.
> 
> The PC partition table has such an ID. The LILO change log
> mentions it. I think it's 6 random bytes, with some restriction
> about being non-zero.

This is just a type identifier showing the parition type and just
valid on the PC.

Won't help it.

-- 

Regards,
Heinz-- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Heinz J. Mauelshagen]

On Thu, May 17, 2001 at 02:35:55AM -0400, Albert D. Cahalan wrote:
 Heinz J. Mauelshag writes:
 
  LVM does a similar thing storing UUIDs in its private metadata
  area on every device used by it.
 
  Problem is: neither MD nor LVM define a standard in Linux
  which *needs* to be used on every device!
 
  It is just up to the user to configure devices with them or not.
 
  BTW: in case we had a Linux standard it wouldn't solve the
  different OS situation mentioned in this thread either.
 
 
  Generally speaking:
  
  It is not the problem to reserve some space to store a uuid or
  something at such and such location on a device.
 
  The problem is the lack of a standard which eventually
  could be implemented in all OSes at some point in time.
 
 The PC partition table has such an ID. The LILO change log
 mentions it. I think it's 6 random bytes, with some restriction
 about being non-zero.

This is just a type identifier showing the parition type and just
valid on the PC.

Won't help it.

-- 

Regards,
Heinz-- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux LVM: external CVS access

[Heinz J. Mauelshagen]

As announced 3 weeks ago, we have set up external CVS write access now.

We hereby kindly invite major contributors like Andreas Dilger to join in :-)


In order to set an account up, please send your address information
(including postal, e-mail, phone and fax contacts) to me.

We reserve the right to decide about who is gained write access.

The decision will be based on just the following criteria:

 - submitter contributes regularly

 - submitter contributes major enhancements and/or bug fixes


In case you are accepted, you'll get all
access information to the server in return.

Please add a PGP key in order to encrypt the account password for you.


Thank you for supporting Linux LVM.

-- 

Regards,
Heinz-- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Heinz J. Mauelshagen]

On Wed, May 16, 2001 at 02:09:32PM +0200, Thomas Kotzian wrote:
> From: "Helge Hafting" <[EMAIL PROTECTED]>
> > Partition id's seems more interesting than disk id's - we normally
> > mount partitions not whole disks.
> >
> > RAID do this well - the raid autodetect partition stores an ID in the
> > last block,
> > the remaining N-1 blocks are available for a fs.
> >
> > This could be extended to non-raid use - i.e. use the "raid autodetect"
> > partition type for non-raid as well.  The autodetect routine could
> > then create /dev/partitions/home, /dev/partitions/usr or
> > /dev/partitions/name_of_my_choice
> > for autodetect partitions not participating in a RAID.
> 
> Raid can do this easily because they install the raid on fresh partitions so
> they can easily "steal" the last sector, and the filesystem goes in the
> "shrinked" raid-device. Normal partitions that already have a filesystem on
> them (maybe another OS formatted them) occupy space including the last
> sector - no place left on these partitions to baptize them. - how should
> that work with existing fs'es???

Right.
LVM does a similar thing storing UUIDs in its private metadata area
on every device used by it.

Problem is: neither MD nor LVM define a standard in Linux which *needs* to be
used on every device!

It is just up to the user to configure devices with them or not.

BTW: in case we had a Linux standard it wouldn't solve the
"different OS" situation mentioned in this thread either.


Generally speaking:

It is not the problem to reserve some space to store a uuid or something
at such and such location on a device.

The problem is the lack of a standard which eventually
could be implemented in all OSes at some point in time.

OS dependent data migration tools presumed, we could have
that standard in place on (all) real devices a little later than that ;-)

And what about a standard to access the stored identifying
data and to avoid that it doesn't get overwritten by accident?

> 
> > This is better than volume labels, as it will work for all fs'es
> > (including those who don't support mount-by-ID) and also raw
> > partitions with no fs.
> 
> Thomas Kotzian
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LVM 1.0 release decision

[Heinz J. Mauelshagen]

On Fri, May 11, 2001 at 03:32:46PM +0100, Alan Cox wrote:
> > This leads to the dilemma, that trying to avoid further differences between
> > our LVM releases and the stock kernel code would force us into postponing
> > the pending LVM 1.0 release accordingly which OTOH is incovenient for the LVM
> > user base.
> > 
> > In regard to this situation we'ld like to know about your oppinion on
> > the following request:
> > is it acceptable to release 1.0 soon *before* all patches to reach the 1.0 code
> 
> Please fix the binary incompatibility in the on disk format between the current
> code and your new release _before_ you do that.

?

The new code *can* automagically read and deal with 0.8 created VGDAs.
What are you refering too in detail here?


> The last patches I was sent
> would have screwed every 64bit LVM user.

Patrick is investigating here.

> 
> A new format is fine but import old ones properly. And if you do a new format
> stop using kdev_t on disk - it will change size soon

We don't need it any longer in the PV struct.

In the LV struct we can change it easily, because we just need the minor
number which will nicely fit into the 32 bit we have.

> 
> Alan

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-lvm] LVM 1.0 release decision

[Heinz J. Mauelshagen]

On Sun, May 13, 2001 at 08:48:19PM -0300, Rik van Riel wrote:
> On Fri, 11 May 2001, Steven Lembark wrote:
> 
> > for my part running the system i'd rather have the "production"
> > LVM and kernel releases in sync and not have to worry about it.
> > if i need a beta/inter-version release then i'll deal with the
> > extra issues.
> 
> Agreed.  If the in-kernel LVM cannot be trusted, I really
> don't see why Sistina would ever want to associate its name
> with something broken?

Rik, that's not an issue at all and sorry, it doesn't help either!

With the help of community contributors we *do* provide the most recent
code with as few bugs as possible at www.sistina.com/lvm as we always did.

Everybody could and can get it from there and established LVM users continue
to do it this way.

OTOH we need a lot of time now to get smaller patches into vanilla.

Therefore we kindly asked for community oppinions to help the situation.


Unless a bigger LVM patch to vanilla is accepted, we need to spend a lot of work
on providing those smaller chunks of patches which distracts us a lot from
other work.

Don't tell me that this is all our fault; 
this wouldn't *help* to fasten the process either!

A little trust to accept a bigger patch *and* to sort pending issues
out with the help of the community afterwards is a valid approach IMO to
get faster to the point of an updated vanilla LVM driver than with the
tiny patches approach.

Linus, Alan et al.: maybe you could think about it again and
accept one larger LVM patch. Thanks.

> 
> I think it would be better for everyone (users, Sistina's
> corporate image and Linux) to get something stable into the
> kernel before sending out the press release ;)
> 
> (after all, a version number change is just a one-liner patch
> away ;))
> 
> regards,
> 
> Rik
> --
> Virtual memory is like a game you can't win;
> However, without VM there's truly nothing to lose...
> 
> http://www.surriel.com/   http://distro.conectiva.com/
> 
> Send all your spam to [EMAIL PROTECTED] (spam digging piggy)
> 
> ___
> linux-lvm mailing list
> [EMAIL PROTECTED]
> http://lists.sistina.com/mailman/listinfo/linux-lvm

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-lvm] LVM 1.0 release decision

[Heinz J. Mauelshagen]

On Sun, May 13, 2001 at 08:48:19PM -0300, Rik van Riel wrote:
 On Fri, 11 May 2001, Steven Lembark wrote:
 
  for my part running the system i'd rather have the production
  LVM and kernel releases in sync and not have to worry about it.
  if i need a beta/inter-version release then i'll deal with the
  extra issues.
 
 Agreed.  If the in-kernel LVM cannot be trusted, I really
 don't see why Sistina would ever want to associate its name
 with something broken?

Rik, that's not an issue at all and sorry, it doesn't help either!

With the help of community contributors we *do* provide the most recent
code with as few bugs as possible at www.sistina.com/lvm as we always did.

Everybody could and can get it from there and established LVM users continue
to do it this way.

OTOH we need a lot of time now to get smaller patches into vanilla.

Therefore we kindly asked for community oppinions to help the situation.


Unless a bigger LVM patch to vanilla is accepted, we need to spend a lot of work
on providing those smaller chunks of patches which distracts us a lot from
other work.

Don't tell me that this is all our fault; 
this wouldn't *help* to fasten the process either!

A little trust to accept a bigger patch *and* to sort pending issues
out with the help of the community afterwards is a valid approach IMO to
get faster to the point of an updated vanilla LVM driver than with the
tiny patches approach.

Linus, Alan et al.: maybe you could think about it again and
accept one larger LVM patch. Thanks.

 
 I think it would be better for everyone (users, Sistina's
 corporate image and Linux) to get something stable into the
 kernel before sending out the press release ;)
 
 (after all, a version number change is just a one-liner patch
 away ;))
 
 regards,
 
 Rik
 --
 Virtual memory is like a game you can't win;
 However, without VM there's truly nothing to lose...
 
 http://www.surriel.com/   http://distro.conectiva.com/
 
 Send all your spam to [EMAIL PROTECTED] (spam digging piggy)
 
 ___
 linux-lvm mailing list
 [EMAIL PROTECTED]
 http://lists.sistina.com/mailman/listinfo/linux-lvm

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LVM 1.0 release decision

[Heinz J. Mauelshagen]

On Fri, May 11, 2001 at 03:32:46PM +0100, Alan Cox wrote:
  This leads to the dilemma, that trying to avoid further differences between
  our LVM releases and the stock kernel code would force us into postponing
  the pending LVM 1.0 release accordingly which OTOH is incovenient for the LVM
  user base.
  
  In regard to this situation we'ld like to know about your oppinion on
  the following request:
  is it acceptable to release 1.0 soon *before* all patches to reach the 1.0 code
 
 Please fix the binary incompatibility in the on disk format between the current
 code and your new release _before_ you do that.

?

The new code *can* automagically read and deal with 0.8 created VGDAs.
What are you refering too in detail here?


 The last patches I was sent
 would have screwed every 64bit LVM user.

Patrick is investigating here.

 
 A new format is fine but import old ones properly. And if you do a new format
 stop using kdev_t on disk - it will change size soon

We don't need it any longer in the PV struct.

In the LV struct we can change it easily, because we just need the minor
number which will nicely fit into the 32 bit we have.

 
 Alan

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Heinz J. Mauelshagen]

On Wed, May 16, 2001 at 02:09:32PM +0200, Thomas Kotzian wrote:
 From: Helge Hafting [EMAIL PROTECTED]
  Partition id's seems more interesting than disk id's - we normally
  mount partitions not whole disks.
 
  RAID do this well - the raid autodetect partition stores an ID in the
  last block,
  the remaining N-1 blocks are available for a fs.
 
  This could be extended to non-raid use - i.e. use the raid autodetect
  partition type for non-raid as well.  The autodetect routine could
  then create /dev/partitions/home, /dev/partitions/usr or
  /dev/partitions/name_of_my_choice
  for autodetect partitions not participating in a RAID.
 
 Raid can do this easily because they install the raid on fresh partitions so
 they can easily steal the last sector, and the filesystem goes in the
 shrinked raid-device. Normal partitions that already have a filesystem on
 them (maybe another OS formatted them) occupy space including the last
 sector - no place left on these partitions to baptize them. - how should
 that work with existing fs'es???

Right.
LVM does a similar thing storing UUIDs in its private metadata area
on every device used by it.

Problem is: neither MD nor LVM define a standard in Linux which *needs* to be
used on every device!

It is just up to the user to configure devices with them or not.

BTW: in case we had a Linux standard it wouldn't solve the
different OS situation mentioned in this thread either.


Generally speaking:

It is not the problem to reserve some space to store a uuid or something
at such and such location on a device.

The problem is the lack of a standard which eventually
could be implemented in all OSes at some point in time.

OS dependent data migration tools presumed, we could have
that standard in place on (all) real devices a little later than that ;-)

And what about a standard to access the stored identifying
data and to avoid that it doesn't get overwritten by accident?

 
  This is better than volume labels, as it will work for all fs'es
  (including those who don't support mount-by-ID) and also raw
  partitions with no fs.
 
 Thomas Kotzian
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux LVM: external CVS access

[Heinz J. Mauelshagen]

As announced 3 weeks ago, we have set up external CVS write access now.

We hereby kindly invite major contributors like Andreas Dilger to join in :-)


In order to set an account up, please send your address information
(including postal, e-mail, phone and fax contacts) to me.

We reserve the right to decide about who is gained write access.

The decision will be based on just the following criteria:

 - submitter contributes regularly

 - submitter contributes major enhancements and/or bug fixes


In case you are accepted, you'll get all
access information to the server in return.

Please add a PGP key in order to encrypt the account password for you.


Thank you for supporting Linux LVM.

-- 

Regards,
Heinz-- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

LVM 1.0 release decision

[Heinz J. Mauelshagen]

As most of you probably know, we've got criticism a couple of weeks ago about
our Linux kernel patch policy causing the LVM vanilla kernel code to differ
from the one we release directly.

In order to avoid this difference we provide smaller patches more often now.
We have started already with a subset of about 50 necessary patches.

Even though we get kind support from Alan Cox to get those QAed and integrated,
the pure amount of patches will take at least a couple of weeks to make it in.

This leads to the dilemma, that trying to avoid further differences between
our LVM releases and the stock kernel code would force us into postponing
the pending LVM 1.0 release accordingly which OTOH is incovenient for the LVM
user base.

In regard to this situation we'ld like to know about your oppinion on
the following request:
is it acceptable to release 1.0 soon *before* all patches to reach the 1.0 code
status are in vanilla (presumed that we provide them with our release as we
always did before)?

We'll gather your answers for some days and will send the conclusion
to the lists.

Thanks for your support!

-- 

Regards,
Heinz-- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

LVM 1.0 release decision

[Heinz J. Mauelshagen]

As most of you probably know, we've got criticism a couple of weeks ago about
our Linux kernel patch policy causing the LVM vanilla kernel code to differ
from the one we release directly.

In order to avoid this difference we provide smaller patches more often now.
We have started already with a subset of about 50 necessary patches.

Even though we get kind support from Alan Cox to get those QAed and integrated,
the pure amount of patches will take at least a couple of weeks to make it in.

This leads to the dilemma, that trying to avoid further differences between
our LVM releases and the stock kernel code would force us into postponing
the pending LVM 1.0 release accordingly which OTOH is incovenient for the LVM
user base.

In regard to this situation we'ld like to know about your oppinion on
the following request:
is it acceptable to release 1.0 soon *before* all patches to reach the 1.0 code
status are in vanilla (presumed that we provide them with our release as we
always did before)?

We'll gather your answers for some days and will send the conclusion
to the lists.

Thanks for your support!

-- 

Regards,
Heinz-- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Your message to linux-lvm awaits moderator approval

[Heinz J. Mauelshagen]

As atetd multiple times now...

There never has been censorship.


On Thu, Apr 19, 2001 at 02:44:40PM -0700, Chip Salzenberg wrote:
> Rik van Riel writes:
> >[...] Andreas' patches got dropped over and over again and comments
> >on the LVM code got refused by the moderators at Sistina ...

If there's inital trouble with the changed mailer setup,
please beat us, but let us stop this thread of "assumptions".

Thanks a lot.

> 
> "The Net interprets censorship as damage and routes around it."
>   -- John Gilmore
> 
> -- 
> Chip Salzenberg  - a.k.a. - <[EMAIL PROTECTED]>
>  "We have no fuel on board, plus or minus 8 kilograms."  -- NEAR tech
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Your message to linux-lvm awaits moderator approval

[Heinz J. Mauelshagen]

As atetd multiple times now...

There never has been censorship.


On Thu, Apr 19, 2001 at 02:44:40PM -0700, Chip Salzenberg wrote:
 Rik van Riel writes:
 [...] Andreas' patches got dropped over and over again and comments
 on the LVM code got refused by the moderators at Sistina ...

If there's inital trouble with the changed mailer setup,
please beat us, but let us stop this thread of assumptions.

Thanks a lot.

 
 The Net interprets censorship as damage and routes around it.
   -- John Gilmore
 
 -- 
 Chip Salzenberg  - a.k.a. - [EMAIL PROTECTED]
  We have no fuel on board, plus or minus 8 kilograms.  -- NEAR tech
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [repost] Announce: Linux-OpenLVM mailing list

[Heinz J. Mauelshagen]

Sorry, sorry.

The lists are open.
Please tell us if mailman still bothers.

On Thu, Apr 19, 2001 at 03:46:53PM -0400, Martin K. Petersen wrote:
> > "Jens" == Jens Axboe <[EMAIL PROTECTED]> writes:
> 
> Jens> First one gets a mail saying that the mail sent is queued for
> Jens> moderator approval, since I'm not on the list. Then later a
> Jens> second mail arrives, saying the mail has been rejected by the
> Jens> moderator.
> 
> Yep.  Same here.  Latest and greatest...
> 
> ---8<---
> From: [EMAIL PROTECTED]
> Subject: Your message to linux-lvm awaits moderator approval
> To: [EMAIL PROTECTED]
> Date: Tue, 10 Apr 2001 22:02:40 +0200
> 
> Your mail to 'linux-lvm' with the subject
> 
> Re: [linux-lvm] *** ANNOUNCEMENT *** LVM 0.9.1 Beta 7 available at
> www.sistina.com
> 
> Is being held until the list moderator can review it for approval.
> ---8<---
> 
> Now, I held my breath until the following day...
> 
> ---8<---
> From: [EMAIL PROTECTED]
> Subject: Request to mailing list linux-lvm rejected
> To: [EMAIL PROTECTED]
> Date: Wed, 11 Apr 2001 17:32:36 +0200
> 
> Your request to the linux-lvm mailing list
> 
> Posting of your message titled "Re: [linux-lvm] *** ANNOUNCEMENT
> *** LVM 0.9.1 Beta 7 available at www.sistina.com"
> 
> has been rejected by the list moderator.  The moderator gave the
> following reason for rejecting your request:
> 
> "Non-members are not allowed to post messages to this list."
> ---8<---
> 
> Since there is such a long delay between the two mails, it's obvious
> that there is human intervention involved.  And when an on-topic mail
> is rejected by the moderator, well... go figure.
> 
> And this isn't the first time this has happened to me and several
> others.  By far...
> 
> -- 
> Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
> [EMAIL PROTECTED], http://www.linuxcare.com/
> SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [repost] Announce: Linux-OpenLVM mailing list

[Heinz J. Mauelshagen]

On Thu, Apr 19, 2001 at 03:35:43PM -0300, Rik van Riel wrote:
> On Thu, 19 Apr 2001, AJ Lewis wrote:
> 
> > It is unfortunate that this could not have been resolved in a more mature
> > manner.  Saying "I don't like the way somebody is doing something.  I won't
> > bother to talk to them about it, I'll just flame them and try to undermine
> > their work." is not acceptable.  It would have been nice if you'd actually
> > tried to work this out instead of handling it this way.
> 
> We tried, but the last time we had something to say about your
> code the message wasn't allowed on your list.

As mentioned in other mails multiple times:
The reject answer contained information about how to become a subscriber.
Our list admin just hated spam and now he has pain in the neck ;-)))

The lists at sistina.com are completely open now anyway :)

> 
> Now that the code is in the kernel, we are of the opinion that
> it is no longer acceptable to censor messages when they are too
> critical about the LVM source code.

This is completely misleading!

There has *never* been censoring in place!

It was just rejects for mail from non subscribers who actually could subscribe
in a seconds effort.

So please let us stop claiming wrong things here.
Thanks!


> This beast is in the kernel,
> now we'd better be allowed to talk about the source code and
> maintain the thing.

Yes, yes, yes!!!

Thanks for all your future appreciated patch and advice input in advance.

> 
> regards,
> 
> Rik
> --
> Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
> 
> Virtual memory is like a game you can't win;
> However, without VM there's truly nothing to lose...
> 
>   http://www.surriel.com/
> http://www.conectiva.com/ http://distro.conectiva.com/
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [repost] Announce: Linux-OpenLVM mailing list

[Heinz J. Mauelshagen]

On Thu, Apr 19, 2001 at 08:48:19PM +0200, Jens Axboe wrote:
> On Thu, Apr 19 2001, AJ Lewis wrote:
> > It is unfortunate that this could not have been resolved in a more mature
> > manner.  Saying "I don't like the way somebody is doing something.  I won't
> > bother to talk to them about it, I'll just flame them and try to undermine
> > their work." is not acceptable.  It would have been nice if you'd actually
> > tried to work this out instead of handling it this way.
> 
> LVM concerns us all now that it is not just an addon, but actually a
> part of the kernel.

As I stated before: there's many more people with lots of expertise *now*
and we appreciate that!

> Rejecting mails and reports from users and
> developers who just might be able to lend you a hand fixing bugs, is not
> just counter productive it's downright rude!

As our (former) list maintainer Ben Lutgens stated:
The rejetc answer contained information how to subscribe to the list which
is a seconds deal ;-)

Anyway: all LVM related lists at sistina.com are now completely open!

People already send hints to spam filters; thank you guys!

> 
> Besides, I didn't think the posting was flame material at all. If
> nothing else, it's a wake up call.

We take it like this and we take it serious that you got annoyed, no matter
what the actual reason is.

I think the facts that the sistina.com lists are open to everybody
now *and* that we will release policies to allow write access to our
CVS repository for major contributors *and* that we'll have a set of (small)
patches in the next couple of days to get vanilla updated will help a lot.

Thanks for the wake up call ;-) and all your support!

> 
> -- 
> Jens Axboe
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [repost] Announce: Linux-OpenLVM mailing list

[Heinz J. Mauelshagen]

On Thu, Apr 19, 2001 at 08:48:19PM +0200, Jens Axboe wrote:
 On Thu, Apr 19 2001, AJ Lewis wrote:
  It is unfortunate that this could not have been resolved in a more mature
  manner.  Saying I don't like the way somebody is doing something.  I won't
  bother to talk to them about it, I'll just flame them and try to undermine
  their work. is not acceptable.  It would have been nice if you'd actually
  tried to work this out instead of handling it this way.
 
 LVM concerns us all now that it is not just an addon, but actually a
 part of the kernel.

As I stated before: there's many more people with lots of expertise *now*
and we appreciate that!

 Rejecting mails and reports from users and
 developers who just might be able to lend you a hand fixing bugs, is not
 just counter productive it's downright rude!

As our (former) list maintainer Ben Lutgens stated:
The rejetc answer contained information how to subscribe to the list which
is a seconds deal ;-)

Anyway: all LVM related lists at sistina.com are now completely open!

People already send hints to spam filters; thank you guys!

 
 Besides, I didn't think the posting was flame material at all. If
 nothing else, it's a wake up call.

We take it like this and we take it serious that you got annoyed, no matter
what the actual reason is.

I think the facts that the sistina.com lists are open to everybody
now *and* that we will release policies to allow write access to our
CVS repository for major contributors *and* that we'll have a set of (small)
patches in the next couple of days to get vanilla updated will help a lot.

Thanks for the wake up call ;-) and all your support!

 
 -- 
 Jens Axboe
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [repost] Announce: Linux-OpenLVM mailing list

[Heinz J. Mauelshagen]

Sorry, sorry.

The lists are open.
Please tell us if mailman still bothers.

On Thu, Apr 19, 2001 at 03:46:53PM -0400, Martin K. Petersen wrote:
  Jens == Jens Axboe [EMAIL PROTECTED] writes:
 
 Jens First one gets a mail saying that the mail sent is queued for
 Jens moderator approval, since I'm not on the list. Then later a
 Jens second mail arrives, saying the mail has been rejected by the
 Jens moderator.
 
 Yep.  Same here.  Latest and greatest...
 
 ---8---
 From: [EMAIL PROTECTED]
 Subject: Your message to linux-lvm awaits moderator approval
 To: [EMAIL PROTECTED]
 Date: Tue, 10 Apr 2001 22:02:40 +0200
 
 Your mail to 'linux-lvm' with the subject
 
 Re: [linux-lvm] *** ANNOUNCEMENT *** LVM 0.9.1 Beta 7 available at
 www.sistina.com
 
 Is being held until the list moderator can review it for approval.
 ---8---
 
 Now, I held my breath until the following day...
 
 ---8---
 From: [EMAIL PROTECTED]
 Subject: Request to mailing list linux-lvm rejected
 To: [EMAIL PROTECTED]
 Date: Wed, 11 Apr 2001 17:32:36 +0200
 
 Your request to the linux-lvm mailing list
 
 Posting of your message titled Re: [linux-lvm] *** ANNOUNCEMENT
 *** LVM 0.9.1 Beta 7 available at www.sistina.com
 
 has been rejected by the list moderator.  The moderator gave the
 following reason for rejecting your request:
 
 Non-members are not allowed to post messages to this list.
 ---8---
 
 Since there is such a long delay between the two mails, it's obvious
 that there is human intervention involved.  And when an on-topic mail
 is rejected by the moderator, well... go figure.
 
 And this isn't the first time this has happened to me and several
 others.  By far...
 
 -- 
 Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
 [EMAIL PROTECTED], http://www.linuxcare.com/
 SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [repost] Announce: Linux-OpenLVM mailing list

[Heinz J. Mauelshagen]

On Fri, Apr 20, 2001 at 08:25:15PM +0200, Jens Axboe wrote:
> On Fri, Apr 20 2001, Alan Cox wrote:
> > > We will announce when they are available ASAP and would appreciate if
> > > people like Alan Cox, Andrea Arcangeli and Andreas Dilger
> > > could check them *before* we start submitting them to Linus.
> > 
> > I'll be glad to help look over them.
> 
> Same here, the important thing is that we actually get this patch flow
> going. And hopefully in the future as well :)

Thanks and yep.
We learned that leasson now. Hopefully ;-)

> 
> -- 
> Jens Axboe

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [repost] Announce: Linux-OpenLVM mailing list

[Heinz J. Mauelshagen]

On Fri, Apr 20, 2001 at 07:04:21PM +0100, Alan Cox wrote:
> > We will announce when they are available ASAP and would appreciate if
> > people like Alan Cox, Andrea Arcangeli and Andreas Dilger
> > could check them *before* we start submitting them to Linus.
> 
> I'll be glad to help look over them.

Thanks Alan :-)

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [repost] Announce: Linux-OpenLVM mailing list

[Heinz J. Mauelshagen]

On Fri, Apr 20, 2001 at 07:04:21PM +0100, Alan Cox wrote:
  We will announce when they are available ASAP and would appreciate if
  people like Alan Cox, Andrea Arcangeli and Andreas Dilger
  could check them *before* we start submitting them to Linus.
 
 I'll be glad to help look over them.

Thanks Alan :-)

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [repost] Announce: Linux-OpenLVM mailing list

[Heinz J. Mauelshagen]

On Fri, Apr 20, 2001 at 08:25:15PM +0200, Jens Axboe wrote:
 On Fri, Apr 20 2001, Alan Cox wrote:
   We will announce when they are available ASAP and would appreciate if
   people like Alan Cox, Andrea Arcangeli and Andreas Dilger
   could check them *before* we start submitting them to Linus.
  
  I'll be glad to help look over them.
 
 Same here, the important thing is that we actually get this patch flow
 going. And hopefully in the future as well :)

Thanks and yep.
We learned that leasson now. Hopefully ;-)

 
 -- 
 Jens Axboe

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [repost] Announce: Linux-OpenLVM mailing list

[Heinz J. Mauelshagen]

Having just a couple of days of vacation I got informed today that
a number of people got pissed off and decided to open a new Linux LVM mailing
list <[EMAIL PROTECTED]>.

Facts people complained about included:

 1. people got dropped from the list

 2. messages bouncing

 3. lack of (small) LVM patches to the Linux kernel

 4. submitted patches being ignored


WRT points 1 and 2:
---
our Linux LVM mailing list <[EMAIL PROTECTED]> is now completely open
in order to avoid such kind of problems in the future.

We apologize for any kind of trouble this caused in the past!

We kindly ask everybody to stay at <[EMAIL PROTECTED]> or to join it
in order to avoid a mailing list split.

Thanks a lot!


WRT point 3:

we will regard the Linus kernel as *the* repository for LVM driver changes
rather than our public CVS repository from now on!

In order to ease this migration we are working to create a bunch of small
patches to submit them to the comunity.

We will announce when they are available ASAP and would appreciate if
people like Alan Cox, Andrea Arcangeli and Andreas Dilger
could check them *before* we start submitting them to Linus.

Thanks a lot in advance for your support.


WRT point 4:

a lot of patches send in by the comunity have been included
in the actual LVM source.
We appreciate all your valuable related work!

Nevertheless about 30 patches which would have changed too much have been
postponed for LVM 1.1 *because* we are in a feature freeze since a couple
of weeks heading to a production stable LVM 1.0.

The submitters have been informed about this fact.

We will make these postponed patches accessable to everybody and will
discuss the status of future patches in the public on the list from now on
in order to avoid any further lack of information here.

None of the patches which showed up on the lvm mailing lists
have been discarded without notice!


General statement:
--
Linux LVM is a Sistina GPL project and there's no danger at all
that we want to change its GPL nature!

We apologize for any inconveniences and kindly ask everybody to continue to
help us making a better Linux LVM.

-- 

Regards,
Heinz-- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [repost] Announce: Linux-OpenLVM mailing list

[Heinz J. Mauelshagen]

Having just a couple of days of vacation I got informed today that
a number of people got pissed off and decided to open a new Linux LVM mailing
list [EMAIL PROTECTED].

Facts people complained about included:

 1. people got dropped from the list

 2. messages bouncing

 3. lack of (small) LVM patches to the Linux kernel

 4. submitted patches being ignored


WRT points 1 and 2:
---
our Linux LVM mailing list [EMAIL PROTECTED] is now completely open
in order to avoid such kind of problems in the future.

We apologize for any kind of trouble this caused in the past!

We kindly ask everybody to stay at [EMAIL PROTECTED] or to join it
in order to avoid a mailing list split.

Thanks a lot!


WRT point 3:

we will regard the Linus kernel as *the* repository for LVM driver changes
rather than our public CVS repository from now on!

In order to ease this migration we are working to create a bunch of small
patches to submit them to the comunity.

We will announce when they are available ASAP and would appreciate if
people like Alan Cox, Andrea Arcangeli and Andreas Dilger
could check them *before* we start submitting them to Linus.

Thanks a lot in advance for your support.


WRT point 4:

a lot of patches send in by the comunity have been included
in the actual LVM source.
We appreciate all your valuable related work!

Nevertheless about 30 patches which would have changed too much have been
postponed for LVM 1.1 *because* we are in a feature freeze since a couple
of weeks heading to a production stable LVM 1.0.

The submitters have been informed about this fact.

We will make these postponed patches accessable to everybody and will
discuss the status of future patches in the public on the list from now on
in order to avoid any further lack of information here.

None of the patches which showed up on the lvm mailing lists
have been discarded without notice!


General statement:
--
Linux LVM is a Sistina GPL project and there's no danger at all
that we want to change its GPL nature!

We apologize for any inconveniences and kindly ask everybody to continue to
help us making a better Linux LVM.

-- 

Regards,
Heinz-- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: block device snapshot capability

[Heinz J. Mauelshagen]

On Wed, Apr 11, 2001 at 11:40:36PM +0200, Christoph Hellwig wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> 
> > Hello all,
> >
> > Is anyone aware of ongoing development to provide the capability 
> > to take a snapshot of a block device?
> 
> It's part of Linux-LVM since version 0.8 and thus part of Linux 2.4.

You need to get the recent LVM 0.9.1 Beta 7 software *and* to patch your
kernel as well, because that'll fix some snapshot related flaws.

> 
>   Christoph
> 
> -- 
> Of course it doesn't work. We've performed a software upgrade.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: block device snapshot capability

[Heinz J. Mauelshagen]

On Wed, Apr 11, 2001 at 11:40:36PM +0200, Christoph Hellwig wrote:
 In article [EMAIL PROTECTED] you wrote:
 
  Hello all,
 
  Is anyone aware of ongoing development to provide the capability 
  to take a snapshot of a block device?
 
 It's part of Linux-LVM since version 0.8 and thus part of Linux 2.4.

You need to get the recent LVM 0.9.1 Beta 7 software *and* to patch your
kernel as well, because that'll fix some snapshot related flaws.

 
   Christoph
 
 -- 
 Of course it doesn't work. We've performed a software upgrade.
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

*** ANNOUNCEMENT *** LVM 0.9.1 Beta 7 available at www.sistina.com

[Heinz J. Mauelshagen]

Hi all,

a tarball of the Linux Logical Volume Manager 0.9.1 Beta 7 is available now at

   

for download (Follow the "LVM 0.9.1-Beta7" link).

This release fixes several bugs.
See the CHANGELOG file contained in the tarball for further information.


Please help us to stabilize for LVM 1.0 ASAP and provide your test results,
bug fixes and advice.


--- Request For Tests ---

Beside others LVM 0.9.1 Beta 7 fixes several pvmove bugs.
We appreciate test feedback in this area on Linus 2.2 and 2.4.

Please try to pvmove logical volumes under load!


Feed back related information to <[EMAIL PROTECTED]>.

Thanks a lot for your support of LVM!

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

*** ANNOUNCEMENT *** LVM 0.9.1 Beta 7 available at www.sistina.com

[Heinz J. Mauelshagen]

Hi all,

a tarball of the Linux Logical Volume Manager 0.9.1 Beta 7 is available now at

   http://www.sistina.com/

for download (Follow the "LVM 0.9.1-Beta7" link).

This release fixes several bugs.
See the CHANGELOG file contained in the tarball for further information.


Please help us to stabilize for LVM 1.0 ASAP and provide your test results,
bug fixes and advice.


--- Request For Tests ---

Beside others LVM 0.9.1 Beta 7 fixes several pvmove bugs.
We appreciate test feedback in this area on Linus 2.2 and 2.4.

Please try to pvmove logical volumes under load!


Feed back related information to [EMAIL PROTECTED].

Thanks a lot for your support of LVM!

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: /dev/loop0 over lvm... leading to d-state :-(

[Heinz J. Mauelshagen]

On Thu, Apr 05, 2001 at 05:54:30PM +0200, Jens Axboe wrote:
> On Thu, Apr 05 2001, Heinz J. Mauelshagen wrote:
> > > Where? Calling buffer_IO_error would be ok, but there are no such calls
> > > in 2.4.3. I just stated elsewhere that submit_bh should probably be
> > > clearing the dirty bit, not ll_rw_block, in which case the b_end_io
> > > is fine. But buffer_IO_error is probably more clear. I trust you'll
> > > take care of that part then.
> > 
> > Sorry, didn't mention that you need to patch the driver with the recent
> > LVM software in order to get it.
> 
> Ah ok, so the b_dev/b_blocknr is all then. Good.
> 
> > I've send the patch a while ago to Linus to get it into 2.4.3
> > but he obviously didn't include it (likely because he thought it was too
> > large ;-)
> 
> Maybe you're hanging on to fixes and submitting huge chunks of them?

We want to change that, sorry :)

> 
> > He didn't comment back to me at all though :-(
> > Maybe this will help.
> 
> Two things that usually help -- submit small and often, then resubmit,
> resubmit, resubmit until he takes it or complains loudly :-)

I know, I know, I know ;-)

> 
> -- 
> Jens Axboe
> 

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: /dev/loop0 over lvm... leading to d-state :-(

[Heinz J. Mauelshagen]

On Thu, Apr 05, 2001 at 05:37:31PM +0200, Jens Axboe wrote:
> On Thu, Apr 05 2001, Heinz J. Mauelshagen wrote:
> > > Irks, another one. lvm_make_request_fn also needs to call b_end_io
> > > if a map fails.
> > 
> > This is wrong.
> > 
> > In case of an io error we do already call buffer_IO_error() on 2.4 in
> > lvm_map().
> 
> Where? Calling buffer_IO_error would be ok, but there are no such calls
> in 2.4.3. I just stated elsewhere that submit_bh should probably be
> clearing the dirty bit, not ll_rw_block, in which case the b_end_io
> is fine. But buffer_IO_error is probably more clear. I trust you'll
> take care of that part then.

Sorry, didn't mention that you need to patch the driver with the recent
LVM software in order to get it.

I've send the patch a while ago to Linus to get it into 2.4.3
but he obviously didn't include it (likely because he thought it was too
large ;-)

He didn't comment back to me at all though :-(
Maybe this will help.

Linus?

> 
> -- 
> Jens Axboe
> 

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: /dev/loop0 over lvm... leading to d-state :-(

[Heinz J. Mauelshagen]

Jens,

thanks for the b_dev hint you provided.

On Thu, Apr 05, 2001 at 04:49:42PM +0200, Jens Axboe wrote:
> On Thu, Apr 05 2001, Jens Axboe wrote:
> > To the LVM folks: you can't use b_dev or b_blocknr inside your
> > make_request_fn, it destroys stacking drivers such as loop. And
> > is just plain wrong in the general case too.
> 
> Irks, another one. lvm_make_request_fn also needs to call b_end_io
> if a map fails.

This is wrong.

In case of an io error we do already call buffer_IO_error() on 2.4 in lvm_map().

In 2.2 ll_rw_block() does change the state of the buffer and calls
b_end_io() for us at the end of the function:

  sorry:
for (i = 0; i < nr; i++) {
if (bh[i]) {
clear_bit(BH_Dirty, [i]->b_state);
clear_bit(BH_Uptodate, [i]->b_state);
bh[i]->b_end_io(bh[i], 0);
}
}


> Updated patch attached, I'll collate further
> patches if I find more :-)

Please do that. Thanks again.

Regards,
Heinz-- The LVM Guy --

>
> 
> -- 
> Jens Axboe
> 

> --- /opt/kernel/linux-2.4.3/drivers/md/lvm.c  Mon Jan 29 01:11:20 2001
> +++ drivers/md/lvm.c  Thu Apr  5 16:48:52 2001
> @@ -148,6 +148,9 @@
>   * procfs is always supported now. (JT)
>   *12/01/2001 - avoided flushing logical volume in case of shrinking
>   * because of unecessary overhead in case of heavy updates
> + *05/04/2001 - lvm_map bugs: don't use b_blocknr/b_dev in lvm_map, it
> + *  destroys stacking devices. call b_end_io on failed maps.
> + *  (Jens Axboe)
>   *
>   */
>  
> @@ -1480,14 +1483,14 @@
>   */
>  static int lvm_map(struct buffer_head *bh, int rw)
>  {
> - int minor = MINOR(bh->b_dev);
> + int minor = MINOR(bh->b_rdev);
>   int ret = 0;
>   ulong index;
>   ulong pe_start;
>   ulong size = bh->b_size >> 9;
> - ulong rsector_tmp = bh->b_blocknr * size;
> + ulong rsector_tmp = bh->b_rsector;
>   ulong rsector_sav;
> - kdev_t rdev_tmp = bh->b_dev;
> + kdev_t rdev_tmp = bh->b_rdev;
>   kdev_t rdev_sav;
>   vg_t *vg_this = vg[VG_BLK(minor)];
>   lv_t *lv = vg_this->lv[LV_BLK(minor)];
> @@ -1676,8 +1679,12 @@
>   */
>  static int lvm_make_request_fn(request_queue_t *q,
>  int rw,
> -struct buffer_head *bh) {
> - return (lvm_map(bh, rw) < 0) ? 0 : 1;
> +struct buffer_head *bh)
> +{
> + int ret = lvm_map(bh, rw);
> + if (ret)
> + bh->b_end_io(bh, test_bit(BH_Uptodate, >b_state));
> + return ret;
>  }
>  
>  

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: /dev/loop0 over lvm... leading to d-state :-(

[Heinz J. Mauelshagen]

Jens,

thanks for the b_dev hint you provided.

On Thu, Apr 05, 2001 at 04:49:42PM +0200, Jens Axboe wrote:
 On Thu, Apr 05 2001, Jens Axboe wrote:
  To the LVM folks: you can't use b_dev or b_blocknr inside your
  make_request_fn, it destroys stacking drivers such as loop. And
  is just plain wrong in the general case too.
 
 Irks, another one. lvm_make_request_fn also needs to call b_end_io
 if a map fails.

This is wrong.

In case of an io error we do already call buffer_IO_error() on 2.4 in lvm_map().

In 2.2 ll_rw_block() does change the state of the buffer and calls
b_end_io() for us at the end of the function:

  sorry:
for (i = 0; i  nr; i++) {
if (bh[i]) {
clear_bit(BH_Dirty, bh[i]-b_state);
clear_bit(BH_Uptodate, bh[i]-b_state);
bh[i]-b_end_io(bh[i], 0);
}
}


 Updated patch attached, I'll collate further
 patches if I find more :-)

Please do that. Thanks again.

Regards,
Heinz-- The LVM Guy --


 
 -- 
 Jens Axboe
 

 --- /opt/kernel/linux-2.4.3/drivers/md/lvm.c  Mon Jan 29 01:11:20 2001
 +++ drivers/md/lvm.c  Thu Apr  5 16:48:52 2001
 @@ -148,6 +148,9 @@
   * procfs is always supported now. (JT)
   *12/01/2001 - avoided flushing logical volume in case of shrinking
   * because of unecessary overhead in case of heavy updates
 + *05/04/2001 - lvm_map bugs: don't use b_blocknr/b_dev in lvm_map, it
 + *  destroys stacking devices. call b_end_io on failed maps.
 + *  (Jens Axboe)
   *
   */
  
 @@ -1480,14 +1483,14 @@
   */
  static int lvm_map(struct buffer_head *bh, int rw)
  {
 - int minor = MINOR(bh-b_dev);
 + int minor = MINOR(bh-b_rdev);
   int ret = 0;
   ulong index;
   ulong pe_start;
   ulong size = bh-b_size  9;
 - ulong rsector_tmp = bh-b_blocknr * size;
 + ulong rsector_tmp = bh-b_rsector;
   ulong rsector_sav;
 - kdev_t rdev_tmp = bh-b_dev;
 + kdev_t rdev_tmp = bh-b_rdev;
   kdev_t rdev_sav;
   vg_t *vg_this = vg[VG_BLK(minor)];
   lv_t *lv = vg_this-lv[LV_BLK(minor)];
 @@ -1676,8 +1679,12 @@
   */
  static int lvm_make_request_fn(request_queue_t *q,
  int rw,
 -struct buffer_head *bh) {
 - return (lvm_map(bh, rw)  0) ? 0 : 1;
 +struct buffer_head *bh)
 +{
 + int ret = lvm_map(bh, rw);
 + if (ret)
 + bh-b_end_io(bh, test_bit(BH_Uptodate, bh-b_state));
 + return ret;
  }
  
  

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: /dev/loop0 over lvm... leading to d-state :-(

[Heinz J. Mauelshagen]

On Thu, Apr 05, 2001 at 05:37:31PM +0200, Jens Axboe wrote:
 On Thu, Apr 05 2001, Heinz J. Mauelshagen wrote:
   Irks, another one. lvm_make_request_fn also needs to call b_end_io
   if a map fails.
  
  This is wrong.
  
  In case of an io error we do already call buffer_IO_error() on 2.4 in
  lvm_map().
 
 Where? Calling buffer_IO_error would be ok, but there are no such calls
 in 2.4.3. I just stated elsewhere that submit_bh should probably be
 clearing the dirty bit, not ll_rw_block, in which case the b_end_io
 is fine. But buffer_IO_error is probably more clear. I trust you'll
 take care of that part then.

Sorry, didn't mention that you need to patch the driver with the recent
LVM software in order to get it.

I've send the patch a while ago to Linus to get it into 2.4.3
but he obviously didn't include it (likely because he thought it was too
large ;-)

He didn't comment back to me at all though :-(
Maybe this will help.

Linus?

 
 -- 
 Jens Axboe
 

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: /dev/loop0 over lvm... leading to d-state :-(

[Heinz J. Mauelshagen]

On Thu, Apr 05, 2001 at 05:54:30PM +0200, Jens Axboe wrote:
 On Thu, Apr 05 2001, Heinz J. Mauelshagen wrote:
   Where? Calling buffer_IO_error would be ok, but there are no such calls
   in 2.4.3. I just stated elsewhere that submit_bh should probably be
   clearing the dirty bit, not ll_rw_block, in which case the b_end_io
   is fine. But buffer_IO_error is probably more clear. I trust you'll
   take care of that part then.
  
  Sorry, didn't mention that you need to patch the driver with the recent
  LVM software in order to get it.
 
 Ah ok, so the b_dev/b_blocknr is all then. Good.
 
  I've send the patch a while ago to Linus to get it into 2.4.3
  but he obviously didn't include it (likely because he thought it was too
  large ;-)
 
 Maybe you're hanging on to fixes and submitting huge chunks of them?

We want to change that, sorry :)

 
  He didn't comment back to me at all though :-(
  Maybe this will help.
 
 Two things that usually help -- submit small and often, then resubmit,
 resubmit, resubmit until he takes it or complains loudly :-)

I know, I know, I know ;-)

 
 -- 
 Jens Axboe
 

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

*** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Heinz J. Mauelshagen]

Hi all,

a tarball of the Linux Logical Volume Manager 0.9.1 beta1 is available now at

   

for download (Follow the "LVM download page" link).


This release fixes several bugs including the vgextend(8) related oops.
See the CHANGELOG file contained in the tarball for further information.

We'ld appreciate a couple of days for test feedback before pushing a 2.4.0
patch to Linus.

Please test and feed back related information to <[EMAIL PROTECTED]>.

Thanks a lot for your support of LVM.

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

*** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Heinz J. Mauelshagen]

Hi all,

a tarball of the Linux Logical Volume Manager 0.9.1 beta1 is available now at

   http://www.sistina.com/

for download (Follow the "LVM download page" link).


This release fixes several bugs including the vgextend(8) related oops.
See the CHANGELOG file contained in the tarball for further information.

We'ld appreciate a couple of days for test feedback before pushing a 2.4.0
patch to Linus.

Please test and feed back related information to [EMAIL PROTECTED].

Thanks a lot for your support of LVM.

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: *** ANNOUNCEMENT *** LVM 0.8.1 and LVM 0.9 available at www.sistina.com

[Heinz J. Mauelshagen]

On Thu, Nov 23, 2000 at 02:36:04AM +, Pavel Machek wrote:
> Hi!
> 
> Perhaps yo should consider lowering number of stars in the subject.

;-)

An annoucement filter is reliying on them, sorry.

> 
> > Linux Logical Volume Manager 0.8.1 (this is 0.8final plus patches)
> > and 0.9 are available for download at www.sistina.com.
> 
> > Please see further information below, test it and help us
> > to make an even better LVM for Linux :-)
> 
> Question i'd like to ask: what features are already present in 2.4.0-test11?

None beside basic devfs support.
Linus needs to consider the patch for integration.

> 
> -- 
> Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
> details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

-- 

Regards,
Heinz  -- The LVM guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: RFC: Modularize /proc/partitons (was Re: /proc/partitions for LVM)

[Heinz J. Mauelshagen]

Looks good to me.

Regards,
Heinz  -- The LVM guy --

On Thu, Nov 23, 2000 at 02:52:39PM -0500, Brian Kress wrote:
> "Heinz J. Mauelshagen" wrote:
> > 
> > On Wed, Nov 22, 2000 at 04:27:51PM -0500, Brian Kress wrote:
> > > "Heinz J. Mauelshagen" wrote:
> > > >
> > > > On Wed, Nov 22, 2000 at 04:05:39PM -0500, Brian Kress wrote:
> > > > >   Question about /proc/partitions and LVM.  LVM devices in
> > > > > /proc/partitions currently show up as lvma, lvmb, etc, depending on
> > > > > their device number.  This breaks things like mount by filesystem
> > > > > name.  Back when LVM existed as a patch, I believe there was some
> > > > > support in fs/partitions/check.c for showing the proper name for
> > > > > the device (something like /).
> > > >
> > > > Yes.
> > > > It actually was /.
> > > >
> > > > Linus didn't accept it though.
> > > >
> > > > The code is still available in case he changes his mind.
> > >
> > >   Yes, I can see that now looking through lvm.c.  (LVM_HD_NAME)
> > > I'm guessing why he didn't take it is the minor hack of adding a
> > > function pointer to genhd.c as a special case just for LVM.
> > >   A general solution to this problem would be nice.  The
> > > big switch statement in disk_name in fs/paritions/check.c is kind
> > > of ugly as it has generic code have to know things about specific
> > > drivers.
> > 
> > Yep.
> > 
> > >   How's this for an idea to generalize this.  Put a function
> > > pointer in the gendisk structure for a specific function to call
> > > for disk_name for disks for that gendisk.
> > 
> > Sounds resonable to me.
> > 
> > > That way, LVM gets its
> > > /, IDE gets its two disks per major (special cased
> > > right now), all the other special cases get what they need and future
> > > drivers can call their devices whatever they like without touching
> > > this file.  Makes the whole thing more modular.  Make a NULL for
> > > this function default to the old a, b, etc.
> > >   What to people think about this?  If this sounds reasonable
> > > I can come up with a patch.
> > 
> > Very good. I'ld appreciate it.
> > 
> 
> 
> OK, here's the patch.  It has three sets of changes:
> 
> 1)  Add a function pointer to struct gendisk called hd_name.
> 
> 2)  Make disk_name in fs/partitions/check.c use that function
> pointer if its non-null.
> 
> 3)  Change the following drivers to use this method. (adding the
> driver specific method and removing the old code in check.c)
> 
> drivers/md/lvm.c
> drivers/md/md.c
> drivers/ide/ide-probe.c
> drivers/scsi/sd.c
> drivers/block/cpqarray.c
> drivers/block/cciss.c
> drivers/block/DAC960.c
> 
> 
>   Let me know what you think.  Think there's any chance we
> can get this in the main kernel tree?

Linus can answer that one ;-)

> 
> 
> Brian Kress
> [EMAIL PROTECTED]
> diff -u --recursive linux-2.4.0-test11/drivers/block/DAC960.c 
>linux-2.4.0-test11-ppfix/drivers/block/DAC960.c
> --- linux-2.4.0-test11/drivers/block/DAC960.c Mon Nov 20 15:17:25 2000
> +++ linux-2.4.0-test11-ppfix/drivers/block/DAC960.c   Thu Nov 23 14:29:37 2000
> @@ -1885,6 +1885,21 @@
>  }
>  
>  
> +char *DAC960_disk_name(struct gendisk *hd, int minor, char *buf)
> +
> +{
> + int ctlr = hd->major - DAC960_MAJOR;
> + int disk = minor >> hd->minor_shift;
> + int part = minor & ((1 << hd->minor_shift) - 1);
> +
> + if (part)
> + sprintf(buf, "%s/c%dd%dp%d", hd->major_name, ctlr, disk, part);
> + else
> + sprintf(buf, "%s/c%dd%d", hd->major_name, ctlr, disk);
> + return buf;
> +}
> +
> +
>  /*
>DAC960_RegisterBlockDevice registers the Block Device structures
>associated with Controller.
> @@ -1945,6 +1960,7 @@
>Controller->GenericDiskInfo.nr_real = Controller->LogicalDriveCount;
>Controller->GenericDiskInfo.next = NULL;
>Controller->GenericDiskInfo.fops = _BlockDeviceOperations;
> +  Controller->GenericDiskInfo.hd_name = DAC960_disk_name;
>/*
>  Install the Generic Disk Information structure at the end of the list.
>*/
> diff -u --recursive linux-2.4.0-test11/drivers/block/cciss.c 
>linux-2.4.0-test11-ppfix/drivers/block/cciss.c
> --- linux-2.4.0-test11/drivers/block/cciss.c  Mon Nov 20 15:17:25 2000
> +++ linux-2.4.0-test11-ppfix/drive

*** ANNOUNCEMENT *** LVM 0.8.1 and LVM 0.9 available at www.sistina.com

[Heinz J. Mauelshagen]

Due to technical problems this might not have made it through...
Sorry in advance if you get it twice.


Hi all,

Linux Logical Volume Manager 0.8.1 (this is 0.8final plus patches)
and 0.9 are available for download at www.sistina.com.

Please see further information below, test it and help us
to make an even better LVM for Linux :-)


Regards,
Heinz  -- The LVM guy --




The Logical Volume Manager (LVM) is a subsystem for online disk storage
management which has become a de-facto standard for storage management
under Linux.

LVM 0.8.1 update to 0.8final:
-
Supported on:
   - Linux 2.2.17
   - Linux 2.4.0-test10 (and previous 2.4.0 test kernels)

New features:
   - Enhance pvmove(8) to operate on single physical volumes
   - Added support for multiple ext2 resize commands via e2fsadm(8)
   - Changed device specials to belong to group "disk"
 to accomodate backup software
   - Initial support for DEVFS

Bug Fixes:
 - LV on disk metadata offset faults
 - Housekeeping for the metadata backup history file
 - lvdisplay(8) and pvdisplay(8) option -c and -v handling


LVM 0.9:

Supported on:
   - Linux 2.4.0-test10 (and previous 2.4.0 test kernels)

New Features:
   - Persistent snapshots for logical volumes
   - Resizable snapshot logical volumes
   - API to request the usage rate of a snapshot logical volume
   - Integration with VFS to consistently mount ReiserFS filesystems
 on snapshots (VFS patch necessary)
   - Physical Volume and Volume Group UUID support
   - lv*(8) commands now use the Default Volume Group specifed in environment
 variable LVM_VG_NAME
   - A /proc/lvm/ directory hierarchy for use in parsing VGDA information
   - Initial support for DEVFS

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
www.sistina.com   64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: RFC: Modularize /proc/partitons (was Re: /proc/partitions for LVM)

[Heinz J. Mauelshagen]

Looks good to me.

Regards,
Heinz  -- The LVM guy --

On Thu, Nov 23, 2000 at 02:52:39PM -0500, Brian Kress wrote:
 "Heinz J. Mauelshagen" wrote:
  
  On Wed, Nov 22, 2000 at 04:27:51PM -0500, Brian Kress wrote:
   "Heinz J. Mauelshagen" wrote:
   
On Wed, Nov 22, 2000 at 04:05:39PM -0500, Brian Kress wrote:
   Question about /proc/partitions and LVM.  LVM devices in
 /proc/partitions currently show up as lvma, lvmb, etc, depending on
 their device number.  This breaks things like mount by filesystem
 name.  Back when LVM existed as a patch, I believe there was some
 support in fs/partitions/check.c for showing the proper name for
 the device (something like vgname/lvname).
   
Yes.
It actually was vgname/lvname.
   
Linus didn't accept it though.
   
The code is still available in case he changes his mind.
  
 Yes, I can see that now looking through lvm.c.  (LVM_HD_NAME)
   I'm guessing why he didn't take it is the minor hack of adding a
   function pointer to genhd.c as a special case just for LVM.
 A general solution to this problem would be nice.  The
   big switch statement in disk_name in fs/paritions/check.c is kind
   of ugly as it has generic code have to know things about specific
   drivers.
  
  Yep.
  
 How's this for an idea to generalize this.  Put a function
   pointer in the gendisk structure for a specific function to call
   for disk_name for disks for that gendisk.
  
  Sounds resonable to me.
  
   That way, LVM gets its
   vgname/lvname, IDE gets its two disks per major (special cased
   right now), all the other special cases get what they need and future
   drivers can call their devices whatever they like without touching
   this file.  Makes the whole thing more modular.  Make a NULL for
   this function default to the old namea, nameb, etc.
 What to people think about this?  If this sounds reasonable
   I can come up with a patch.
  
  Very good. I'ld appreciate it.
  
 
 
 OK, here's the patch.  It has three sets of changes:
 
 1)  Add a function pointer to struct gendisk called hd_name.
 
 2)  Make disk_name in fs/partitions/check.c use that function
 pointer if its non-null.
 
 3)  Change the following drivers to use this method. (adding the
 driver specific method and removing the old code in check.c)
 
 drivers/md/lvm.c
 drivers/md/md.c
 drivers/ide/ide-probe.c
 drivers/scsi/sd.c
 drivers/block/cpqarray.c
 drivers/block/cciss.c
 drivers/block/DAC960.c
 
 
   Let me know what you think.  Think there's any chance we
 can get this in the main kernel tree?

Linus can answer that one ;-)

 
 
 Brian Kress
 [EMAIL PROTECTED]
 diff -u --recursive linux-2.4.0-test11/drivers/block/DAC960.c 
linux-2.4.0-test11-ppfix/drivers/block/DAC960.c
 --- linux-2.4.0-test11/drivers/block/DAC960.c Mon Nov 20 15:17:25 2000
 +++ linux-2.4.0-test11-ppfix/drivers/block/DAC960.c   Thu Nov 23 14:29:37 2000
 @@ -1885,6 +1885,21 @@
  }
  
  
 +char *DAC960_disk_name(struct gendisk *hd, int minor, char *buf)
 +
 +{
 + int ctlr = hd-major - DAC960_MAJOR;
 + int disk = minor  hd-minor_shift;
 + int part = minor  ((1  hd-minor_shift) - 1);
 +
 + if (part)
 + sprintf(buf, "%s/c%dd%dp%d", hd-major_name, ctlr, disk, part);
 + else
 + sprintf(buf, "%s/c%dd%d", hd-major_name, ctlr, disk);
 + return buf;
 +}
 +
 +
  /*
DAC960_RegisterBlockDevice registers the Block Device structures
associated with Controller.
 @@ -1945,6 +1960,7 @@
Controller-GenericDiskInfo.nr_real = Controller-LogicalDriveCount;
Controller-GenericDiskInfo.next = NULL;
Controller-GenericDiskInfo.fops = DAC960_BlockDeviceOperations;
 +  Controller-GenericDiskInfo.hd_name = DAC960_disk_name;
/*
  Install the Generic Disk Information structure at the end of the list.
*/
 diff -u --recursive linux-2.4.0-test11/drivers/block/cciss.c 
linux-2.4.0-test11-ppfix/drivers/block/cciss.c
 --- linux-2.4.0-test11/drivers/block/cciss.c  Mon Nov 20 15:17:25 2000
 +++ linux-2.4.0-test11-ppfix/drivers/block/cciss.cThu Nov 23 14:22:55 2000
 @@ -1749,6 +1749,20 @@
   kfree(size_buff);
  }
  
 +char *cciss_disk_name(struct gendisk *hd, int minor, char *buf)
 +
 +{
 + int ctlr = hd-major - COMPAQ_CISS_MAJOR;
 + int disk = minor  hd-minor_shift;
 + int part = minor  ((1  hd-minor_shift) - 1);
 +
 + if (part)
 + sprintf(buf, "%s/c%dd%dp%d", hd-major_name, ctlr, disk, part);
 + else
 + sprintf(buf, "%s/c%dd%d", hd-major_name, ctlr, disk);
 + return buf;
 +}
 +
  /*
   *  This is it.  Find all the controllers and register them.  I really hate
   *  stealing all these major device numbers.
 @@ -1851,6 +1865,7 @@
   hba[i]-gendisk.part = hba[i]-hd;
   hba[i]-gendisk.sizes = hba[i]-sizes;
   hba[i]-gendisk.nr_real = hba[i]-num_l

Re: *** ANNOUNCEMENT *** LVM 0.8.1 and LVM 0.9 available at www.sistina.com

[Heinz J. Mauelshagen]

On Thu, Nov 23, 2000 at 02:36:04AM +, Pavel Machek wrote:
 Hi!
 
 Perhaps yo should consider lowering number of stars in the subject.

;-)

An annoucement filter is reliying on them, sorry.

 
  Linux Logical Volume Manager 0.8.1 (this is 0.8final plus patches)
  and 0.9 are available for download at www.sistina.com.
 
  Please see further information below, test it and help us
  to make an even better LVM for Linux :-)
 
 Question i'd like to ask: what features are already present in 2.4.0-test11?

None beside basic devfs support.
Linus needs to consider the patch for integration.

 
 -- 
 Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
 details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

-- 

Regards,
Heinz  -- The LVM guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

*** ANNOUNCEMENT *** LVM 0.8.1 and LVM 0.9 available at www.sistina.com

[Heinz J. Mauelshagen]

Due to technical problems this might not have made it through...
Sorry in advance if you get it twice.


Hi all,

Linux Logical Volume Manager 0.8.1 (this is 0.8final plus patches)
and 0.9 are available for download at www.sistina.com.

Please see further information below, test it and help us
to make an even better LVM for Linux :-)


Regards,
Heinz  -- The LVM guy --




The Logical Volume Manager (LVM) is a subsystem for online disk storage
management which has become a de-facto standard for storage management
under Linux.

LVM 0.8.1 update to 0.8final:
-
Supported on:
   - Linux 2.2.17
   - Linux 2.4.0-test10 (and previous 2.4.0 test kernels)

New features:
   - Enhance pvmove(8) to operate on single physical volumes
   - Added support for multiple ext2 resize commands via e2fsadm(8)
   - Changed device specials to belong to group "disk"
 to accomodate backup software
   - Initial support for DEVFS

Bug Fixes:
 - LV on disk metadata offset faults
 - Housekeeping for the metadata backup history file
 - lvdisplay(8) and pvdisplay(8) option -c and -v handling


LVM 0.9:

Supported on:
   - Linux 2.4.0-test10 (and previous 2.4.0 test kernels)

New Features:
   - Persistent snapshots for logical volumes
   - Resizable snapshot logical volumes
   - API to request the usage rate of a snapshot logical volume
   - Integration with VFS to consistently mount ReiserFS filesystems
 on snapshots (VFS patch necessary)
   - Physical Volume and Volume Group UUID support
   - lv*(8) commands now use the Default Volume Group specifed in environment
 variable LVM_VG_NAME
   - A /proc/lvm/ directory hierarchy for use in parsing VGDA information
   - Initial support for DEVFS

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
www.sistina.com   64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

*** ANNOUNCEMENT *** LVM 0.8.1 and LVM 0.9 available at www.sistina.com

[Heinz J. Mauelshagen]

Hi all,

Linux Logical Volume Manager 0.8.1 (this is 0.8final plus patches)
and 0.9 are available for download at www.sistina.com.

Please see further information below, test it and help us
to make an even better LVM for Linux :-)


Regards,
Heinz  -- The LVM guy --




The Logical Volume Manager (LVM) is a subsystem for online disk storage
management which has become a de-facto standard for storage management
under Linux.

LVM 0.8.1 update to 0.8final:
-
Supported on:
   - Linux 2.2.17
   - Linux 2.4.0-test10 (and previous 2.4.0 test kernels)

New features:
   - Enhance pvmove(8) to operate on single physical volumes
   - Added support for multiple ext2 resize commands via e2fsadm(8)
   - Changed device specials to belong to group "disk"
 to accomodate backup software
   - Initial support for DEVFS

Bug Fixes:
 - LV on disk metadata offset faults
 - Housekeeping for the metadata backup history file
 - lvdisplay(8) and pvdisplay(8) option -c and -v handling


LVM 0.9:

Supported on:
   - Linux 2.4.0-test10 (and previous 2.4.0 test kernels)

New Features:
   - Persistent snapshots for logical volumes
   - Resizable snapshot logical volumes
   - API to request the usage rate of a snapshot logical volume
   - Integration with VFS to consistently mount ReiserFS filesystems
 on snapshots (VFS patch necessary)
   - Physical Volume and Volume Group UUID support
   - lv*(8) commands now use the Default Volume Group specifed in environment
 variable LVM_VG_NAME
   - A /proc/lvm/ directory hierarchy for use in parsing VGDA information
   - Initial support for DEVFS

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: RFC: Modularize /proc/partitons (was Re: /proc/partitions for LVM)

[Heinz J. Mauelshagen]

On Wed, Nov 22, 2000 at 04:27:51PM -0500, Brian Kress wrote:
> "Heinz J. Mauelshagen" wrote:
> > 
> > On Wed, Nov 22, 2000 at 04:05:39PM -0500, Brian Kress wrote:
> > >   Question about /proc/partitions and LVM.  LVM devices in
> > > /proc/partitions currently show up as lvma, lvmb, etc, depending on
> > > their device number.  This breaks things like mount by filesystem
> > > name.  Back when LVM existed as a patch, I believe there was some
> > > support in fs/partitions/check.c for showing the proper name for
> > > the device (something like /).
> > 
> > Yes.
> > It actually was /.
> > 
> > Linus didn't accept it though.
> > 
> > The code is still available in case he changes his mind.
> 
>   Yes, I can see that now looking through lvm.c.  (LVM_HD_NAME)
> I'm guessing why he didn't take it is the minor hack of adding a
> function pointer to genhd.c as a special case just for LVM.  
>   A general solution to this problem would be nice.  The
> big switch statement in disk_name in fs/paritions/check.c is kind
> of ugly as it has generic code have to know things about specific
> drivers.  

Yep.

>   How's this for an idea to generalize this.  Put a function
> pointer in the gendisk structure for a specific function to call
> for disk_name for disks for that gendisk.

Sounds resonable to me.

> That way, LVM gets its
> /, IDE gets its two disks per major (special cased
> right now), all the other special cases get what they need and future
> drivers can call their devices whatever they like without touching
> this file.  Makes the whole thing more modular.  Make a NULL for 
> this function default to the old a, b, etc.
>   What to people think about this?  If this sounds reasonable
> I can come up with a patch.

Very good. I'ld appreciate it.

> 
> 
> Brian Kress
> [EMAIL PROTECTED]
> 
> 
> 
> 
> 
> 
> 
> 
> > 
> > >   Are their any plans for something like this to be added
> > > or is their a reason it was taken out?
> > >
> > >
> > >   BTW, 2.4.0-test11 is the first "perfect" kernel for me.  It
> > > finally has everything I use working correctly.  (well, with a
> > > small raid5 patch, anyway).
> > >
> > >
> > > Brian Kress
> > > [EMAIL PROTECTED]
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to [EMAIL PROTECTED]
> > > Please read the FAQ at http://www.tux.org/lkml/
> > 
> > --
> > 
> > Regards,
> > Heinz  -- The LVM guy --
> > 
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > 
> > Heinz Mauelshagen Sistina Software Inc.
> > Senior Consultant/Developer   Bartningstr. 12
> >   64289 Darmstadt
> >   Germany
> > [EMAIL PROTECTED]   +49 6151 7103 86
> >FAX 7103 96
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-- 

Regards,
Heinz  -- The LVM guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: /proc/partitions for LVM

[Heinz J. Mauelshagen]

On Wed, Nov 22, 2000 at 04:05:39PM -0500, Brian Kress wrote:
>   Question about /proc/partitions and LVM.  LVM devices in 
> /proc/partitions currently show up as lvma, lvmb, etc, depending on
> their device number.  This breaks things like mount by filesystem
> name.  Back when LVM existed as a patch, I believe there was some
> support in fs/partitions/check.c for showing the proper name for
> the device (something like /).  

Yes.
It actually was /.

Linus didn't accept it though.

The code is still available in case he changes his mind.

>   Are their any plans for something like this to be added
> or is their a reason it was taken out?
> 
> 
>   BTW, 2.4.0-test11 is the first "perfect" kernel for me.  It
> finally has everything I use working correctly.  (well, with a 
> small raid5 patch, anyway).
> 
> 
> Brian Kress
> [EMAIL PROTECTED]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-- 

Regards,
Heinz  -- The LVM guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: /proc/partitions for LVM

[Heinz J. Mauelshagen]

On Wed, Nov 22, 2000 at 04:05:39PM -0500, Brian Kress wrote:
   Question about /proc/partitions and LVM.  LVM devices in 
 /proc/partitions currently show up as lvma, lvmb, etc, depending on
 their device number.  This breaks things like mount by filesystem
 name.  Back when LVM existed as a patch, I believe there was some
 support in fs/partitions/check.c for showing the proper name for
 the device (something like vgname/lvname).  

Yes.
It actually was vgname/lvname.

Linus didn't accept it though.

The code is still available in case he changes his mind.

   Are their any plans for something like this to be added
 or is their a reason it was taken out?
 
 
   BTW, 2.4.0-test11 is the first "perfect" kernel for me.  It
 finally has everything I use working correctly.  (well, with a 
 small raid5 patch, anyway).
 
 
 Brian Kress
 [EMAIL PROTECTED]
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 Please read the FAQ at http://www.tux.org/lkml/

-- 

Regards,
Heinz  -- The LVM guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: RFC: Modularize /proc/partitons (was Re: /proc/partitions for LVM)

[Heinz J. Mauelshagen]

On Wed, Nov 22, 2000 at 04:27:51PM -0500, Brian Kress wrote:
 "Heinz J. Mauelshagen" wrote:
  
  On Wed, Nov 22, 2000 at 04:05:39PM -0500, Brian Kress wrote:
 Question about /proc/partitions and LVM.  LVM devices in
   /proc/partitions currently show up as lvma, lvmb, etc, depending on
   their device number.  This breaks things like mount by filesystem
   name.  Back when LVM existed as a patch, I believe there was some
   support in fs/partitions/check.c for showing the proper name for
   the device (something like vgname/lvname).
  
  Yes.
  It actually was vgname/lvname.
  
  Linus didn't accept it though.
  
  The code is still available in case he changes his mind.
 
   Yes, I can see that now looking through lvm.c.  (LVM_HD_NAME)
 I'm guessing why he didn't take it is the minor hack of adding a
 function pointer to genhd.c as a special case just for LVM.  
   A general solution to this problem would be nice.  The
 big switch statement in disk_name in fs/paritions/check.c is kind
 of ugly as it has generic code have to know things about specific
 drivers.  

Yep.

   How's this for an idea to generalize this.  Put a function
 pointer in the gendisk structure for a specific function to call
 for disk_name for disks for that gendisk.

Sounds resonable to me.

 That way, LVM gets its
 vgname/lvname, IDE gets its two disks per major (special cased
 right now), all the other special cases get what they need and future
 drivers can call their devices whatever they like without touching
 this file.  Makes the whole thing more modular.  Make a NULL for 
 this function default to the old namea, nameb, etc.
   What to people think about this?  If this sounds reasonable
 I can come up with a patch.

Very good. I'ld appreciate it.

 
 
 Brian Kress
 [EMAIL PROTECTED]
 
 
 
 
 
 
 
 
  
 Are their any plans for something like this to be added
   or is their a reason it was taken out?
  
  
 BTW, 2.4.0-test11 is the first "perfect" kernel for me.  It
   finally has everything I use working correctly.  (well, with a
   small raid5 patch, anyway).
  
  
   Brian Kress
   [EMAIL PROTECTED]
   -
   To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
   the body of a message to [EMAIL PROTECTED]
   Please read the FAQ at http://www.tux.org/lkml/
  
  --
  
  Regards,
  Heinz  -- The LVM guy --
  
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  
  Heinz Mauelshagen Sistina Software Inc.
  Senior Consultant/Developer   Bartningstr. 12
64289 Darmstadt
Germany
  [EMAIL PROTECTED]   +49 6151 7103 86
 FAX 7103 96
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-- 

Regards,
Heinz  -- The LVM guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

*** ANNOUNCEMENT *** LVM 0.8.1 and LVM 0.9 available at www.sistina.com

[Heinz J. Mauelshagen]

Hi all,

Linux Logical Volume Manager 0.8.1 (this is 0.8final plus patches)
and 0.9 are available for download at www.sistina.com.

Please see further information below, test it and help us
to make an even better LVM for Linux :-)


Regards,
Heinz  -- The LVM guy --




The Logical Volume Manager (LVM) is a subsystem for online disk storage
management which has become a de-facto standard for storage management
under Linux.

LVM 0.8.1 update to 0.8final:
-
Supported on:
   - Linux 2.2.17
   - Linux 2.4.0-test10 (and previous 2.4.0 test kernels)

New features:
   - Enhance pvmove(8) to operate on single physical volumes
   - Added support for multiple ext2 resize commands via e2fsadm(8)
   - Changed device specials to belong to group "disk"
 to accomodate backup software
   - Initial support for DEVFS

Bug Fixes:
 - LV on disk metadata offset faults
 - Housekeeping for the metadata backup history file
 - lvdisplay(8) and pvdisplay(8) option -c and -v handling


LVM 0.9:

Supported on:
   - Linux 2.4.0-test10 (and previous 2.4.0 test kernels)

New Features:
   - Persistent snapshots for logical volumes
   - Resizable snapshot logical volumes
   - API to request the usage rate of a snapshot logical volume
   - Integration with VFS to consistently mount ReiserFS filesystems
 on snapshots (VFS patch necessary)
   - Physical Volume and Volume Group UUID support
   - lv*(8) commands now use the Default Volume Group specifed in environment
 variable LVM_VG_NAME
   - A /proc/lvm/ directory hierarchy for use in parsing VGDA information
   - Initial support for DEVFS

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: LVM snapshotting broken?

[Heinz J. Mauelshagen]

On Fri, Oct 27, 2000 at 11:55:03AM -0200, Rik van Riel wrote:
> On Fri, 27 Oct 2000, Andrea Arcangeli wrote:
> > On Fri, Oct 27, 2000 at 11:32:06AM -0200, Rik van Riel wrote:
> > > Have you checked if the CONTENT of the snapshot is indeed
> > > the right LV and not the other one?
> > 
> > laser:~ # mke2fs /dev/vg1/lv1 &>/dev/null
> > laser:~ # mount /dev/vg1/lv1 /mnt
> > laser:~ # >/mnt/ciao
> > laser:~ # ls /mnt
> > .  ..  ciao  lost+found
> > laser:~ # umount /mnt
> > laser:~ # lvcreate -s -n lv1-snap /dev/vg1/lv1 -L 400M
> > lvcreate -- INFO: using default snapshot chunk size of 64 KB
> > lvcreate -- doing automatic backup of "vg1"
> > lvcreate -- logical volume "/dev/vg1/lv1-snap" successfully created
> > 
> > laser:~ # mount /dev/vg1/lv1 /mnt
> > laser:~ # rm /mnt/ciao
> > laser:~ # umount /mnt
> > laser:~ # mount /dev/vg1/lv1-snap /mnt
> > mount: block device /dev/vg1/lv1-snap is write-protected, mounting read-only
> > laser:~ # ls /mnt/
> > .  ..  ciao  lost+found
> > laser:~ # 
> 
> OK, good. I guess that means that the lvmutils (even the
> patched version in the RPM) are heavily broken ...

As i mentioned before: i wasn't able to reproduce your problem on any of
my systems. It work just fine with 0.8final and in 0.9 as weel.

Did anybody else beside Rik face a problem with snapshots _not_ referring
to the original logical volume they where created for?

> 
> Andrea, could you send me the patches you use to make your
> LVM utilities work? Then we'll be able to put together at
> least one working LVM utilities version ;)
> 
> Heinz, how about releasing a 0.8.1 version of the utilities
> so that there is something WORKING out there? Not having
> working LVM utilities available is an utter disgrace when
> all the code to make it work is just available...

I don't have any complaints so far about similar snapshot malfunctions
you mentioned, Rik.
That said it is overemphasis to say, that the LVM utilities
are not working.
IMHO Andreas Dilger's LVM 0.8 backport to kernel 2.2 should be o.k. for
most of the cases.

I'ld like to have 0.9 to do the integtration of the available patches
which will be released in november.

> 
> regards,
> 
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
>-- Miguel de Icaza, UKUUG 2000
> 
> http://www.conectiva.com/ http://www.surriel.com/

-- 

Regards,
Heinz  -- The LVM guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: LVM snapshotting broken?

[Heinz J. Mauelshagen]

Hi Rik,

I can't reproduce it on my box.

Could you provide a "lvcreate -d" output of what you did to help
me to dig into that one.

Did somebody else out there face the same 0.8final snapshot weirdness?


On Thu, Oct 26, 2000 at 04:36:37PM -0200, Rik van Riel wrote:
> Hi Heinz,
> 
> it looks like the LVM snapshotting in 2.4 doesn't allow you
> to create snapshots from anything else than the _first_ LV
> in the VG...
> 
> I have run both the following command lines (after lvremoving
> snap1, of course) and both of them give as a result that the
> LV /dev/test_vg/swap ends up being the snapshotted filesystem ;(
> 
> # lvcreate -s -L100 -nsnap1 /dev/test_vg/test
> # lvcreate -s -L100 -nsnap1 /dev/test_vg/swap
> 
> # cat /proc/lvm
> LVM driver version 0.8final  (15/02/2000)
> 
>   
> 
> LVs: [AWDL  ] swap122880 /30   1x open
>  [AWDL  ] test204800 /50   1x open
>  [ARDL  ] snap1   122880 /30   close
> 
> It looks like somewhere in either the utilities or the
> kernel, the argument of which LV to snapshot gets mangled...
> Oh, I'm using version 0.8final of the LVM utities.
> 
> regards,
> 
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
>-- Miguel de Icaza, UKUUG 2000
> 
> http://www.conectiva.com/ http://www.surriel.com/

-- 

Regards,
Heinz  -- The LVM guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Multiple access to drives

[Heinz J. Mauelshagen]

With 2.4.0-test8 i am able to access one and the same scsi disk
by /dev/sdb _and_ /dev/sdd at the same time.

Wondering if it is a bug or a feature ;-{)
-- 

Regards,
Heinz  -- The LVM guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Multiple access to drives

[Heinz J. Mauelshagen]

With 2.4.0-test8 i am able to access one and the same scsi disk
by /dev/sdb _and_ /dev/sdd at the same time.

Wondering if it is a bug or a feature ;-{)
-- 

Regards,
Heinz  -- The LVM guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

*** Announcement *** 2nd Annual Linux Storage Management Workshop

[Heinz J. Mauelshagen]

Hi,

Please consider attending the 2nd Annual Linux Storage
Management Workshop in Miami, Florida, to be held from
Oct. 15th-19th at the University of Miami.  More information
about the conference can be found at 

http://www.globalfilesystem.org/Pages/Miami2000.html

Speakers include:
Stephen Tweedie, Red Hat (ext2fs and ext3fs) 
Hans Reiser, Namesys (ReiserFS) 
Peter Braam, Turbolinux (Intermezzo) 
Heinz Mauelshagen, Sistina Software (LVM) 
Ken Preslan, Sistina Software (GFS) 
Rik van Riel, Connectiva (VM system) 
Ted Ts'o, VA Linux (ext2fs and friends) 
Alan Robertson, Suse (Heartbeat) 
John Jackson, Purdue University (Amanda) 
Steve Best, IBM (IBM's Journaled File System) 
Ben Rafanello, IBM (IBM's LVM) 
Rick Wheeler, EMC (EMC & Linux) 
Chris Feist, StorageTek (Secure File System) 
Steve Lord, SGI (SGI's XFS) 
Jeremy Allison, VA Linux (Samba) 
Gawain Lavers, Big Storage (Linux DMAPI) 
Steve Pate, Veritas (Veritas' VxFS & VxVM on Linux) 
Dave Higgen, VA Linux (Linux NFS V3) 
Matthew O'Keefe, Sistina (Linux Storage Clusters) 
and others... 

If you plan on attending, please make your reservations as soon as
possible, as hotel space in Miami is limited.  More details
on reservations and registration can be found at the web page.

Hope to see you there,
Regards,
Matt and Heinz


The Workshop Organizers 

Matthew O'Keefe  Heinz Mauelshagen 
Sistina Software, Inc.   Sistina Software, Inc. 
[EMAIL PROTECTED]   [EMAIL PROTECTED] 
http://www.sistina.com   http://www.sistina.com 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]

*** Announcement *** 2nd Annual Linux Storage Management Workshop

[Heinz J. Mauelshagen]

Hi,

Please consider attending the 2nd Annual Linux Storage
Management Workshop in Miami, Florida, to be held from
Oct. 15th-19th at the University of Miami.  More information
about the conference can be found at 

http://www.globalfilesystem.org/Pages/Miami2000.html

Speakers include:
Stephen Tweedie, Red Hat (ext2fs and ext3fs) 
Hans Reiser, Namesys (ReiserFS) 
Peter Braam, Turbolinux (Intermezzo) 
Heinz Mauelshagen, Sistina Software (LVM) 
Ken Preslan, Sistina Software (GFS) 
Rik van Riel, Connectiva (VM system) 
Ted Ts'o, VA Linux (ext2fs and friends) 
Alan Robertson, Suse (Heartbeat) 
John Jackson, Purdue University (Amanda) 
Steve Best, IBM (IBM's Journaled File System) 
Ben Rafanello, IBM (IBM's LVM) 
Rick Wheeler, EMC (EMC  Linux) 
Chris Feist, StorageTek (Secure File System) 
Steve Lord, SGI (SGI's XFS) 
Jeremy Allison, VA Linux (Samba) 
Gawain Lavers, Big Storage (Linux DMAPI) 
Steve Pate, Veritas (Veritas' VxFS  VxVM on Linux) 
Dave Higgen, VA Linux (Linux NFS V3) 
Matthew O'Keefe, Sistina (Linux Storage Clusters) 
and others... 

If you plan on attending, please make your reservations as soon as
possible, as hotel space in Miami is limited.  More details
on reservations and registration can be found at the web page.

Hope to see you there,
Regards,
Matt and Heinz


The Workshop Organizers 

Matthew O'Keefe  Heinz Mauelshagen 
Sistina Software, Inc.   Sistina Software, Inc. 
[EMAIL PROTECTED]   [EMAIL PROTECTED] 
http://www.sistina.com   http://www.sistina.com 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]

Re: [PATCH] devfs support for LVM

[Heinz J. Mauelshagen]

On Wed, Sep 06, 2000 at 04:02:15PM +0200, Christoph Hellwig wrote:
> On Wed, Sep 06, 2000 at 03:48:53PM +0000, Heinz J. Mauelshagen wrote:
> > > I can add a patch that does full-blown devfs
> > > checking to the tools, but this needs a lot of work.
> > 
> > Actually changing the tools to recognize devfs seems fairly simple.
> > I am already working on it.
> >
> > _But_ the LVM Metadata on disk has the old names stored which causes the
> > need to have an old naming sceme to new naming sceme admin change tool
> > for handling this.
> 
> That's the most difficult thing I was thinking about.
> My idea was to simply ignore the actual name of the pv and
> use it as UUID instead.

I already did that in the actual 0.9 LVM source.
Every PV has its own UUID now and a list of all the UUIDs of all PVs of
the VG in case it belongs to one.

> 
> I'll post the proposal to linux-lvm soon.
> 
> 
>   Christoph
> 
> -- 
> Always remember that you are unique.  Just like everyone else.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-- 

Regards,
Heinz  -- The LVM guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] devfs support for LVM

[Heinz J. Mauelshagen]

On Wed, Sep 06, 2000 at 04:02:15PM +0200, Christoph Hellwig wrote:
 On Wed, Sep 06, 2000 at 03:48:53PM +, Heinz J. Mauelshagen wrote:
   I can add a patch that does full-blown devfs
   checking to the tools, but this needs a lot of work.
  
  Actually changing the tools to recognize devfs seems fairly simple.
  I am already working on it.
 
  _But_ the LVM Metadata on disk has the old names stored which causes the
  need to have an old naming sceme to new naming sceme admin change tool
  for handling this.
 
 That's the most difficult thing I was thinking about.
 My idea was to simply ignore the actual name of the pv and
 use it as UUID instead.

I already did that in the actual 0.9 LVM source.
Every PV has its own UUID now and a list of all the UUIDs of all PVs of
the VG in case it belongs to one.

 
 I'll post the proposal to linux-lvm soon.
 
 
   Christoph
 
 -- 
 Always remember that you are unique.  Just like everyone else.
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 Please read the FAQ at http://www.tux.org/lkml/

-- 

Regards,
Heinz  -- The LVM guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/