RE: [linux-lvm] FW: LVM on Linux

RE: [linux-lvm] FW: LVM on Linux

[Gonyou, Austin]

I think ELVM at the bottom is EVMS. I wish I knew where the original article
was, cause I'd like to know what 64bit frame he's talking about. Currently
I'm using LVM for striping, and plan to use it with Fibre. From what I
understand on this list, is that others are using it on fibre already. So,
if they are using a 2.4 kernel, with fibre, wouldn't that mean that they'd
need to employ 64-bit access(if they use a 64-bit controller+driver?)

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com 

> -----Original Message-----
> From: Gonyou, Austin [mailto:austin@coremetrics.com]
> Sent: Monday, July 16, 2001 3:36 PM
> To: 'linux-lvm@sistina.com'
> Subject: [linux-lvm] FW: LVM on Linux
> 
> 
> From the XFS list. 
> 
> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com 
> 
> > -----Original Message-----
> > From: Ric Tibbetts [mailto:ric@pipcws.ca.boeing.com]
> > Sent: Monday, July 16, 2001 3:09 PM
> > To: Linux XFS Mailing List; JFS Discussion List
> > Subject: LVM on Linux
> > 
> > 
> > For anyone considering using LVM on Linux. You might want to take a 
> > second to look at the following "short" article. It casts a 
> > questionalble light on the current state of the LVM code.
> > 
> > ================================================
> > 
> > 0 Jun - 5 Jul (8 posts) Archive Link: [RFC][PATCH] first cut 
> > 64 bit block
> > support
> >                   Summary by Zack Brown
> > 
> > Ben LaHaise posted a patch and announced, "Below is the first 
> > cut at making
> > the block size limit configurable to 64 bits on x86, as well 
> > as always 64
> > bits on 64 bit machines. The audit isn't complete yet, but a 
> > good chunk of
> > it is done." [..] "The following should be 64 bit clean now: 
> > nbd, loop,
> > raid0, raid1, raid5." He gave links to two homepages at
> > http://people.redhat.com/bcrl/lb/ and
> > http://www.kvack.org/~blah/lb/. He added, "Ugly bits: I had 
> > to add libgcc.a
> > to satisfy the need for 64 bit division. Yeah, it sucks, but 
> > RAID needs some
> > more massaging before I can remove the 64 bit division 
> > completely. This will
> > be fixed." Chris Wedgwood proposed some changes to libgcc.a 
> > to be less ugly,
> > and Ben replied, "I'm getting rid of the need for libgcc 
> > entirely. That's
> > what "This will be fixed" means. If you want to expedite the 
> > process, send a
> > patch. Until then, this is Good Enough for testing purposes."
> > 
> > Elsewhere, Ragnar Kjarstad was very happy about Ben's work, 
> > asking if LVM
> > was also 64-bit clean. Ben replied cryptically, "Errr, I'll 
> > refrain from
> > talking about LVM." Ragnar wanted some clarification, and Ben 
> > explained:
> > 
> > Fixing LVM is not on the radar of my priorities. The code is 
> > sorely in need
> > of a
> > rewrite and violates several of the basic planning tenents 
> > that any good
> > code in the block layer should follow. Namely, it should have 
> > 1) planned on
> > supporting 64 bit offsets, 2) never used multiplication, 
> > division or modulus
> > on block numbers, and 3) don't allocate memory structures 
> > that are indexed
> > by block numbers. LVM failed on all three of these -- and 
> > this si just what
> > I noticed in a quick 5 minute glance through the code. Sorry, 
> > but LVM is
> > obsolete by design. It will continue to work on 32 bit block 
> > devices, but if
> > you try to use it beyond that, it will fail. That said, we'll 
> > have to make
> > sure these failures are graceful and occur prior to the user 
> > having a chance
> > at loosing any data.
> > 
> > Now, thankfully there are alternatives like ELVM, which are 
> working on
> > getting the
> > details right from the lessons learned. Given that, I think 
> > we'll be in good
> > shape
> > during the 2.5 cycle.
> > 
> > End Of Thread (tm).
> > 
> > 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> 

Re: [linux-lvm] FW: LVM on Linux

[Ragnar Kjørstad]

On Mon, Jul 16, 2001 at 03:42:00PM -0500, Gonyou, Austin wrote:
> I think ELVM at the bottom is EVMS. I wish I knew where the original article
> was, cause I'd like to know what 64bit frame he's talking about. Currently
> I'm using LVM for striping, and plan to use it with Fibre. From what I
> understand on this list, is that others are using it on fibre already. So,
> if they are using a 2.4 kernel, with fibre, wouldn't that mean that they'd
> need to employ 64-bit access(if they use a 64-bit controller+driver?)

I'm not sure what you mean here.

The 32/64 bit question in this thread was the datatype used to store
sector-numbers; the effect of using 32bit is that it limits the
device-size to 1 (2) TB.

If you're talking about 64 bit PCI busses and such; this is totally
unrelated.

And yes, we'd like to use LVM on FibreChannel devices, and need 64 bit 
sector numbers :)


-- 
Ragnar Kjorstad
Big Storage

Re: [linux-lvm] FW: LVM on Linux

[Joe Thornber]

This one keeps resurfacing so I had a look at it.

I had a look at Ben LaHaise's patch, it seems to be ensuring that all
sector offsets are stored in a blkoff_t variable, which presumably is
an unsigned 64 bit integer.  The rest of the patch goes through some
of the block drivers (eg, loop) and ensures that no *, / or %
operations are performed on blkoff_t's.  Good stuff.

The email below mentions 3 problems with LVM:

1) planned on supporting 64 bit offsets

   o lvm_disk_data_t which describes the positions of the metadata
     sections uses 32bit sectors - however these will always be in the
     first Meg or so of the block device, so 32 bits is plenty

   o lv_block_exception_t, used for the in core representation and
     hence a part of the ioctl interface, holds 32 bit sectors.  This
     will have to be changed.  But the ioctl interface is going to change
     big time when we move to in kernel metadata io.

2) never used multiplication, division or modulus on block numbers

   It's true that we do this at the moment, I just had a quick go at getting
   rid of them, the no-stripe case is easy:

   int inline map_single(blkoff_t sector, vg_t *vg, lv_t *lv, 
		         blkoff_t *sector_map, kdev_t *dev_map)
   {
	pe_t *pe;
	uint32_t pe_shift = vg->pe_shift;
	uint32_t pe_mask = vg->pe_mask;

	index = rsector_org >> pe_shift;
	pe = lv->lv_current_pe + index;

	*sector_map = pe.pe + (rsector_org & pe_mask);
	*dev_map = pe.dev;
   }

   We just replace the / and % with shifts and masks.

   The striped version is harder:

   int inline map_multiple(blkoff_t sector, vg_t *vg, lv_t *lv,
			   blkoff_t *sector_map, kdev_t *dev_map)
   {
	uint32_t pe_shift = vg->pe_shift;
	uint32_t pe_mask = vg->pe_mask;
	uint32_t stripes = lv->stripes;
	uint32_t seg_size = vg->pe_size * stripes;
	uint32_t index, chunk;
	pe_t *pe;

	index = sector >> pe_shift;  /* safely drop to 32 bits */
        index -= index % stripes;    /* I'm sure there's a neater way */

	/*!!! 64 bit % */
	chunk = (sector % seg_size) >> chunk_shift;

	index += chunk % stripes;
	chunk = chunk / stripes;

	pe = lv->lv_current_pe + index;

	sector_map = pe.pe + (chunk << chunk_shift) + (sector & chunk_mask);
	dev_map = pe.dev;
   }

   Here there's one % that we can't get rid of (we could also do chunk = 
   sector - (pe_size * index)), for the simple fact that the number of
   stripes is not a power of 2, so we can't replace with shifts and masks.

   I just had a chat with one of the EVMS guys, EVMS *does* have this
   exact same problem.

   Should we restrict stripes sets to powers of 2 ?


3) don't allocate memory structures that are indexed by block numbers

   o We don't, I think he's confusing PE's with blocks.


- Joe


On Mon, Jul 16, 2001@03:42:00PM -0500, Gonyou, Austin wrote:
> I think ELVM at the bottom is EVMS. I wish I knew where the original article
> was, cause I'd like to know what 64bit frame he's talking about. Currently
> I'm using LVM for striping, and plan to use it with Fibre. From what I
> understand on this list, is that others are using it on fibre already. So,
> if they are using a 2.4 kernel, with fibre, wouldn't that mean that they'd
> need to employ 64-bit access(if they use a 64-bit controller+driver?)
> 
> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com 
> 
> > -----Original Message-----
> > From: Gonyou, Austin [mailto:austin@coremetrics.com]
> > Sent: Monday, July 16, 2001 3:36 PM
> > To: 'linux-lvm@sistina.com'
> > Subject: [linux-lvm] FW: LVM on Linux
> > 
> > 
> > From the XFS list. 
> > 
> > -- 
> > Austin Gonyou
> > Systems Architect, CCNA
> > Coremetrics, Inc.
> > Phone: 512-796-9023
> > email: austin@coremetrics.com 
> > 
> > > -----Original Message-----
> > > From: Ric Tibbetts [mailto:ric@pipcws.ca.boeing.com]
> > > Sent: Monday, July 16, 2001 3:09 PM
> > > To: Linux XFS Mailing List; JFS Discussion List
> > > Subject: LVM on Linux
> > > 
> > > 
> > > For anyone considering using LVM on Linux. You might want to take a 
> > > second to look at the following "short" article. It casts a 
> > > questionalble light on the current state of the LVM code.
> > > 
> > > ================================================
> > > 
> > > 0 Jun - 5 Jul (8 posts) Archive Link: [RFC][PATCH] first cut 
> > > 64 bit block
> > > support
> > >                   Summary by Zack Brown
> > > 
> > > Ben LaHaise posted a patch and announced, "Below is the first 
> > > cut at making
> > > the block size limit configurable to 64 bits on x86, as well 
> > > as always 64
> > > bits on 64 bit machines. The audit isn't complete yet, but a 
> > > good chunk of
> > > it is done." [..] "The following should be 64 bit clean now: 
> > > nbd, loop,
> > > raid0, raid1, raid5." He gave links to two homepages at
> > > http://people.redhat.com/bcrl/lb/ and
> > > http://www.kvack.org/~blah/lb/. He added, "Ugly bits: I had 
> > > to add libgcc.a
> > > to satisfy the need for 64 bit division. Yeah, it sucks, but 
> > > RAID needs some
> > > more massaging before I can remove the 64 bit division 
> > > completely. This will
> > > be fixed." Chris Wedgwood proposed some changes to libgcc.a 
> > > to be less ugly,
> > > and Ben replied, "I'm getting rid of the need for libgcc 
> > > entirely. That's
> > > what "This will be fixed" means. If you want to expedite the 
> > > process, send a
> > > patch. Until then, this is Good Enough for testing purposes."
> > > 
> > > Elsewhere, Ragnar Kjarstad was very happy about Ben's work, 
> > > asking if LVM
> > > was also 64-bit clean. Ben replied cryptically, "Errr, I'll 
> > > refrain from
> > > talking about LVM." Ragnar wanted some clarification, and Ben 
> > > explained:
> > > 
> > > Fixing LVM is not on the radar of my priorities. The code is 
> > > sorely in need
> > > of a
> > > rewrite and violates several of the basic planning tenents 
> > > that any good
> > > code in the block layer should follow. Namely, it should have 
> > > 1) planned on
> > > supporting 64 bit offsets, 2) never used multiplication, 
> > > division or modulus
> > > on block numbers, and 3) don't allocate memory structures 
> > > that are indexed
> > > by block numbers. LVM failed on all three of these -- and 
> > > this si just what
> > > I noticed in a quick 5 minute glance through the code. Sorry, 
> > > but LVM is
> > > obsolete by design. It will continue to work on 32 bit block 
> > > devices, but if
> > > you try to use it beyond that, it will fail. That said, we'll 
> > > have to make
> > > sure these failures are graceful and occur prior to the user 
> > > having a chance
> > > at loosing any data.
> > > 
> > > Now, thankfully there are alternatives like ELVM, which are 
> > working on
> > > getting the
> > > details right from the lessons learned. Given that, I think 
> > > we'll be in good
> > > shape
> > > during the 2.5 cycle.
> > > 
> > > End Of Thread (tm).
> > > 
> > > 
> > _______________________________________________
> > linux-lvm mailing list
> > linux-lvm@sistina.com
> > http://lists.sistina.com/mailman/listinfo/linux-lvm
> > read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> > 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

Re: [linux-lvm] FW: LVM on Linux

[Ragnar Kjørstad]

On Tue, Jul 17, 2001 at 05:40:08PM +0100, Joe Thornber wrote:
> This one keeps resurfacing so I had a look at it.
> 
> I had a look at Ben LaHaise's patch, it seems to be ensuring that all
> sector offsets are stored in a blkoff_t variable, which presumably is
> an unsigned 64 bit integer.  The rest of the patch goes through some
> of the block drivers (eg, loop) and ensures that no *, / or %
> operations are performed on blkoff_t's.  Good stuff.

blkoff_t is 64 bit on 64 bit machines, and configurable (32/64) on 32
bit machines. Excelent IMHO.



-- 
Ragnar Kjorstad
Big Storage

Re: [linux-lvm] FW: LVM on Linux

[Ralph Jennings]

On Tue, Jul 17, 2001 at 05:40:08PM +0100, Joe Thornber wrote:
[snip]
>    Here there's one % that we can't get rid of (we could also do chunk = 
>    sector - (pe_size * index)), for the simple fact that the number of
>    stripes is not a power of 2, so we can't replace with shifts and masks.
> 
>    I just had a chat with one of the EVMS guys, EVMS *does* have this
>    exact same problem.
> 
>    Should we restrict stripes sets to powers of 2 ?
[snip]

Why not just make a mod function?

Preceeding code not tested, but should work?
It's been a while since I wrote C code.

BTW, what is a u64 (unsigned 64bit integer) in C called?
Is there any uniform cross platform way to say it (like
u64 perhaps)?

u64 mod_64(u64 number, u64 modNum) {
    while (number > modNum) {
        number -= modNum;
    }
    return number;
}

Re: [linux-lvm] FW: LVM on Linux

[Joe Thornber]

On Tue, Jul 17, 2001 at 12:23:18PM -0700, Ralph Jennings wrote:
> On Tue, Jul 17, 2001 at 05:40:08PM +0100, Joe Thornber wrote:
> [snip]
> >    Here there's one % that we can't get rid of (we could also do chunk = 
> >    sector - (pe_size * index)), for the simple fact that the number of
> >    stripes is not a power of 2, so we can't replace with shifts and masks.
> > 
> >    I just had a chat with one of the EVMS guys, EVMS *does* have this
> >    exact same problem.
> > 
> >    Should we restrict stripes sets to powers of 2 ?
> [snip]
> 
> Why not just make a mod function?
> 
> Preceeding code not tested, but should work?
> It's been a while since I wrote C code.
> 
> BTW, what is a u64 (unsigned 64bit integer) in C called?
> Is there any uniform cross platform way to say it (like
> u64 perhaps)?

long long ?

> 
> u64 mod_64(u64 number, u64 modNum) {
>     while (number > modNum) {
>         number -= modNum;
>     }
>     return number;
> }

I'd like to see the flames if I put this into the driver :) The map
function is called on every io block to an LVM device, it needs to be
quick !  Since we know modNum is smallish, certainly less than 2^32,
and 'number' is 64 bit we could be running around your loop a few
times :)

On a more serious note this function should be provided by the
compiler, since it supports the 64 bit type.  I guess it is normally
implemented in a function that gets linked automatically - it would still
be good to get rid of it.

- Joe

Re: [linux-lvm] FW: LVM on Linux

[Heinz J. Mauelshagen]

On Wed, Jul 18, 2001 at 09:16:39AM +0100, Joe Thornber wrote:
> On Tue, Jul 17, 2001 at 12:23:18PM -0700, Ralph Jennings wrote:
> > On Tue, Jul 17, 2001 at 05:40:08PM +0100, Joe Thornber wrote:
> > [snip]
> > >    Here there's one % that we can't get rid of (we could also do chunk = 
> > >    sector - (pe_size * index)), for the simple fact that the number of
> > >    stripes is not a power of 2, so we can't replace with shifts and masks.
> > > 
> > >    I just had a chat with one of the EVMS guys, EVMS *does* have this
> > >    exact same problem.
> > > 
> > >    Should we restrict stripes sets to powers of 2 ?
> > [snip]
> > 
> > Why not just make a mod function?
> > 
> > Preceeding code not tested, but should work?
> > It's been a while since I wrote C code.
> > 
> > BTW, what is a u64 (unsigned 64bit integer) in C called?
> > Is there any uniform cross platform way to say it (like
> > u64 perhaps)?
> 
> long long ?

u64 = unsigned long long :)

> 
> > 
> > u64 mod_64(u64 number, u64 modNum) {
> >     while (number > modNum) {
> >         number -= modNum;
> >     }
> >     return number;
> > }
> 
> I'd like to see the flames if I put this into the driver :) The map
> function is called on every io block to an LVM device, it needs to be
> quick !  Since we know modNum is smallish, certainly less than 2^32,
> and 'number' is 64 bit we could be running around your loop a few
> times :)

Yep.

> 
> On a more serious note this function should be provided by the
> compiler, since it supports the 64 bit type.  I guess it is normally
> implemented in a function that gets linked automatically - it would still
> be good to get rid of it.

True.
> 
> - Joe
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

-- 

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
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] FW: LVM on Linux

[Steven Lembark]

- Joe Thornber <thornber@btconnect.com> on 07/18/01 09:16:39 +0100:


>> >    Should we restrict stripes sets to powers of 2 ?

Anything else can (a) lead to performance degredation  and/or
(b) serious bugs dealing with a fairly offball case.  

Especially due to (b) I'd bow down at the alter of KISS.

RE: [linux-lvm] FW: LVM on Linux

[Gonyou, Austin]

Thanks for the clarification. I didn't see the start of this thread I don't
think, If I did, I was out to lunch.:) 
At any rate the 32/64 bit numbering issue is explained very well here, and
there is more commentary over on the XFS list too. 
Another thing is also that I believe people are already using Fibre storage
with LVM. No? Anyone?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com 

> -----Original Message-----
> From: Ragnar Kjørstad [mailto:lvm@ragnark.vestdata.no]
> Sent: Monday, July 16, 2001 4:10 PM
> To: linux-lvm@sistina.com
> Subject: Re: [linux-lvm] FW: LVM on Linux
> 
> 
> On Mon, Jul 16, 2001 at 03:42:00PM -0500, Gonyou, Austin wrote:
> > I think ELVM at the bottom is EVMS. I wish I knew where the 
> original article
> > was, cause I'd like to know what 64bit frame he's talking 
> about. Currently
> > I'm using LVM for striping, and plan to use it with Fibre. 
> From what I
> > understand on this list, is that others are using it on 
> fibre already. So,
> > if they are using a 2.4 kernel, with fibre, wouldn't that 
> mean that they'd
> > need to employ 64-bit access(if they use a 64-bit 
> controller+driver?)
> 
> I'm not sure what you mean here.
> 
> The 32/64 bit question in this thread was the datatype used to store
> sector-numbers; the effect of using 32bit is that it limits the
> device-size to 1 (2) TB.
> 
> If you're talking about 64 bit PCI busses and such; this is totally
> unrelated.
> 
> And yes, we'd like to use LVM on FibreChannel devices, and 
> need 64 bit 
> sector numbers :)
> 
> 
> -- 
> Ragnar Kjorstad
> Big Storage
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> 

Re: [linux-lvm] FW: LVM on Linux

[Ragnar Kjørstad]

On Mon, Jul 16, 2001 at 06:26:50PM -0500, Gonyou, Austin wrote:
> Thanks for the clarification. I didn't see the start of this thread I don't
> think, If I did, I was out to lunch.:) 
> At any rate the 32/64 bit numbering issue is explained very well here, and
> there is more commentary over on the XFS list too. 
> Another thing is also that I believe people are already using Fibre storage
> with LVM. No? Anyone?

Yes.



-- 
Ragnar Kjorstad
Big Storage

[linux-lvm] FW: LVM on Linux

[Gonyou, Austin]

From the XFS list. 

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com 

> -----Original Message-----
> From: Ric Tibbetts [mailto:ric@pipcws.ca.boeing.com]
> Sent: Monday, July 16, 2001 3:09 PM
> To: Linux XFS Mailing List; JFS Discussion List
> Subject: LVM on Linux
> 
> 
> For anyone considering using LVM on Linux. You might want to take a 
> second to look at the following "short" article. It casts a 
> questionalble light on the current state of the LVM code.
> 
> ================================================
> 
> 0 Jun - 5 Jul (8 posts) Archive Link: [RFC][PATCH] first cut 
> 64 bit block
> support
>                   Summary by Zack Brown
> 
> Ben LaHaise posted a patch and announced, "Below is the first 
> cut at making
> the block size limit configurable to 64 bits on x86, as well 
> as always 64
> bits on 64 bit machines. The audit isn't complete yet, but a 
> good chunk of
> it is done." [..] "The following should be 64 bit clean now: 
> nbd, loop,
> raid0, raid1, raid5." He gave links to two homepages at
> http://people.redhat.com/bcrl/lb/ and
> http://www.kvack.org/~blah/lb/. He added, "Ugly bits: I had 
> to add libgcc.a
> to satisfy the need for 64 bit division. Yeah, it sucks, but 
> RAID needs some
> more massaging before I can remove the 64 bit division 
> completely. This will
> be fixed." Chris Wedgwood proposed some changes to libgcc.a 
> to be less ugly,
> and Ben replied, "I'm getting rid of the need for libgcc 
> entirely. That's
> what "This will be fixed" means. If you want to expedite the 
> process, send a
> patch. Until then, this is Good Enough for testing purposes."
> 
> Elsewhere, Ragnar Kjarstad was very happy about Ben's work, 
> asking if LVM
> was also 64-bit clean. Ben replied cryptically, "Errr, I'll 
> refrain from
> talking about LVM." Ragnar wanted some clarification, and Ben 
> explained:
> 
> Fixing LVM is not on the radar of my priorities. The code is 
> sorely in need
> of a
> rewrite and violates several of the basic planning tenents 
> that any good
> code in the block layer should follow. Namely, it should have 
> 1) planned on
> supporting 64 bit offsets, 2) never used multiplication, 
> division or modulus
> on block numbers, and 3) don't allocate memory structures 
> that are indexed
> by block numbers. LVM failed on all three of these -- and 
> this si just what
> I noticed in a quick 5 minute glance through the code. Sorry, 
> but LVM is
> obsolete by design. It will continue to work on 32 bit block 
> devices, but if
> you try to use it beyond that, it will fail. That said, we'll 
> have to make
> sure these failures are graceful and occur prior to the user 
> having a chance
> at loosing any data.
> 
> Now, thankfully there are alternatives like ELVM, which are working on
> getting the
> details right from the lessons learned. Given that, I think 
> we'll be in good
> shape
> during the 2.5 cycle.
> 
> End Of Thread (tm).
> 
> 

Re: [linux-lvm] FW: LVM on Linux

[Heinz J. Mauelshagen]

On Mon, Jul 16, 2001 at 03:35:35PM -0500, Gonyou, Austin wrote:
> >From the XFS list. 
> 

Austin,
I stated to Ben's unserious mail you included at the end below but didn't get a
serious asnwer back so far :-(

Don't get me wrong: I really appreciate to get reasonable proposals.

Regards,
Heinz    -- The LVM Guy --


On Thu, Jul 05, 2001 at 03:35:31AM -0400, Ben LaHaise wrote:
> On Thu, 5 Jul 2001, Ragnar Kj�rstad wrote:
> 
> > What do you mean?
> > Is it not feasible to fix this in LVM as well, or do you just not know
> > what needs to be done to LVM?
> 
> Fixing LVM is not on the radar of my priorities.  The code is sorely in
> need of a rewrite and violates several of the basic planning tenents that
> any good code in the block layer should follow.  Namely, it should have 1)
> planned on supporting 64 bit offsets,

What is the particular problem with 1?
Changes need to take place in the whole block device layer during 2.5
development in order to be 64 bit clean.

LVM will just be one member of the bunch :-)

> 2) never used multiplication,
> division or modulus on block numbers,

I assume that you mean an advice ("never use") rather than a statement
that you never used it, right?

FYI: this takes place in multiple block device layer functions.

For sure you can argue that this is supposed to vanish in 2.5 but
were's the document recommending this and defining how to do it?

> and 3) don't allocate memory
> structures that are indexed by block numbers.

Why?

Remapping block devices do that!
Checks against index mismatches are in LVM already.

> Even LVM failed on all three of
> these -- and this si just what I noticed in a quick 5 minute glance
> through the code.  Sorry, but LVM is obsolete by design.

Sorry but you are argueing weakly in a political manor.

Please speak up clearly and talk about the caveats you see and change request
you recommend as an expert or say nothing!

> It will continue
> to work on 32 bit block devices, but if you try to use it beyond that, it
> will fail.

As I said above.
During the 2.5 development cycle it will be addressed.

> That said, we'll have to make sure these failures are graceful
> and occur prior to the user having a chance at loosing any data.

Once 64 bit support will be implemented in the block device layer
and the VFS, LVM as a block device layer entity will support it as well :-)

> 
> Now, thankfully there are alternatives like ELVM, which are working on
> getting the details right from the lessons learned.

ELVM is not in production so far...
If you would have read the EVMS kernel code, you had realized that they do
modulo calculations as well and I think they are doing right!


> Given that, I think
> we'll be in good shape during the 2.5 cycle.

I agree (from a different standpoint though ;-)

Waiting for your serious advice...

> 
> 		-ben
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html


> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com 
> 
> > -----Original Message-----
> > From: Ric Tibbetts [mailto:ric@pipcws.ca.boeing.com]
> > Sent: Monday, July 16, 2001 3:09 PM
> > To: Linux XFS Mailing List; JFS Discussion List
> > Subject: LVM on Linux
> > 
> > 
> > For anyone considering using LVM on Linux. You might want to take a 
> > second to look at the following "short" article. It casts a 
> > questionalble light on the current state of the LVM code.
> > 
> > ================================================
> > 
> > 0 Jun - 5 Jul (8 posts) Archive Link: [RFC][PATCH] first cut 
> > 64 bit block
> > support
> >                   Summary by Zack Brown
> > 
> > Ben LaHaise posted a patch and announced, "Below is the first 
> > cut at making
> > the block size limit configurable to 64 bits on x86, as well 
> > as always 64
> > bits on 64 bit machines. The audit isn't complete yet, but a 
> > good chunk of
> > it is done." [..] "The following should be 64 bit clean now: 
> > nbd, loop,
> > raid0, raid1, raid5." He gave links to two homepages at
> > http://people.redhat.com/bcrl/lb/ and
> > http://www.kvack.org/~blah/lb/. He added, "Ugly bits: I had 
> > to add libgcc.a
> > to satisfy the need for 64 bit division. Yeah, it sucks, but 
> > RAID needs some
> > more massaging before I can remove the 64 bit division 
> > completely. This will
> > be fixed." Chris Wedgwood proposed some changes to libgcc.a 
> > to be less ugly,
> > and Ben replied, "I'm getting rid of the need for libgcc 
> > entirely. That's
> > what "This will be fixed" means. If you want to expedite the 
> > process, send a
> > patch. Until then, this is Good Enough for testing purposes."
> > 
> > Elsewhere, Ragnar Kjarstad was very happy about Ben's work, 
> > asking if LVM
> > was also 64-bit clean. Ben replied cryptically, "Errr, I'll 
> > refrain from
> > talking about LVM." Ragnar wanted some clarification, and Ben 
> > explained:
> > 
> > Fixing LVM is not on the radar of my priorities. The code is 
> > sorely in need
> > of a
> > rewrite and violates several of the basic planning tenents 
> > that any good
> > code in the block layer should follow. Namely, it should have 
> > 1) planned on
> > supporting 64 bit offsets, 2) never used multiplication, 
> > division or modulus
> > on block numbers, and 3) don't allocate memory structures 
> > that are indexed
> > by block numbers. LVM failed on all three of these -- and 
> > this si just what
> > I noticed in a quick 5 minute glance through the code. Sorry, 
> > but LVM is
> > obsolete by design. It will continue to work on 32 bit block 
> > devices, but if
> > you try to use it beyond that, it will fail. That said, we'll 
> > have to make
> > sure these failures are graceful and occur prior to the user 
> > having a chance
> > at loosing any data.
> > 
> > Now, thankfully there are alternatives like ELVM, which are working on
> > getting the
> > details right from the lessons learned. Given that, I think 
> > we'll be in good
> > shape
> > during the 2.5 cycle.
> > 
> > End Of Thread (tm).
> > 
> > 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

*** 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
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-