From: "Heinz J. Mauelshagen" <Mauelshagen@sistina.com>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] Re: [PATCH] 64 bit scsi read/write
Date: Tue, 10 Jul 2001 15:45:30 +0200 [thread overview]
Message-ID: <20010710154530.A18025@sistina.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0107050310570.1063-100000@toomuch.toronto.redhat.com>; from bcrl@redhat.com on Thu, Jul 05, 2001 at 03:35:31AM -0400
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
--
Regards,
Heinz -- The LVM Guy --
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
Mauelshagen@Sistina.com +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2001-07-10 13:45 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-01 4:53 [RFC][PATCH] first cut 64 bit block support Ben LaHaise
2001-07-03 4:53 ` Ragnar Kjørstad
2001-07-04 2:19 ` [PATCH] 64 bit scsi read/write Ben LaHaise
2001-07-04 7:11 ` Alan Cox
2001-07-05 6:34 ` [linux-lvm] " Ragnar Kjørstad
2001-07-05 6:34 ` Ragnar Kjørstad
2001-07-05 7:35 ` [linux-lvm] " Ben LaHaise
2001-07-05 7:35 ` Ben LaHaise
2001-07-05 16:46 ` [linux-lvm] " AJ Lewis
2001-07-05 17:09 ` Eric M. Hopper
2001-07-10 13:45 ` Heinz J. Mauelshagen [this message]
2001-07-13 18:20 ` Albert D. Cahalan
2001-07-13 18:20 ` Albert D. Cahalan
2001-07-13 20:41 ` [linux-lvm] " Andreas Dilger
2001-07-13 20:41 ` Andreas Dilger
2001-07-13 21:07 ` Chris Wedgwood
2001-07-13 22:04 ` [linux-lvm] " Andreas Dilger
2001-07-13 22:04 ` Andreas Dilger
2001-07-14 0:49 ` [linux-lvm] " Jonathan Lundell
2001-07-14 0:49 ` Jonathan Lundell
2001-07-14 12:27 ` Paul Jakma
2001-07-14 14:48 ` Chris Wedgwood
2001-07-14 15:42 ` Paul Jakma
2001-07-14 17:18 ` Chris Wedgwood
2001-07-20 17:03 ` Stephen C. Tweedie
2001-07-16 18:53 ` Andreas Dilger
2001-07-16 19:13 ` Ragnar Kjørstad
2001-07-13 21:14 ` [linux-lvm] " Alan Cox
2001-07-13 21:14 ` Alan Cox
2001-07-14 3:23 ` [linux-lvm] " Andrew Morton
2001-07-14 3:23 ` Andrew Morton
2001-07-14 8:45 ` [linux-lvm] " Alan Cox
2001-07-14 8:45 ` Alan Cox
2001-07-14 13:54 ` [linux-lvm] " Steven Lembark
2001-07-14 14:50 ` Chris Wedgwood
2001-07-14 15:41 ` [linux-lvm] " Jonathan Lundell
2001-07-14 15:41 ` Jonathan Lundell
2001-07-14 17:00 ` Chris Wedgwood
2001-07-14 20:11 ` [linux-lvm] " Daniel Phillips
2001-07-14 20:11 ` Daniel Phillips
2001-07-15 1:21 ` [linux-lvm] " Andrew Morton
2001-07-15 1:21 ` Andrew Morton
2001-07-15 1:53 ` [linux-lvm] " Daniel Phillips
2001-07-15 1:53 ` Daniel Phillips
2001-07-15 3:36 ` Chris Wedgwood
2001-07-15 6:05 ` [linux-lvm] " John Alvord
2001-07-15 6:05 ` John Alvord
2001-07-15 6:07 ` Chris Wedgwood
2001-07-15 13:16 ` [linux-lvm] " Ken Hirsch
2001-07-15 13:16 ` Ken Hirsch
2001-07-15 14:50 ` Chris Wedgwood
2001-07-15 22:14 ` [linux-lvm] " Daniel Phillips
2001-07-15 22:14 ` Daniel Phillips
2001-07-17 0:31 ` [linux-lvm] " Juan Quintela
2001-07-17 0:31 ` Juan Quintela
2001-07-15 13:44 ` [linux-lvm] " Daniel Phillips
2001-07-15 13:44 ` Daniel Phillips
2001-07-15 14:39 ` Chris Wedgwood
2001-07-15 15:06 ` [linux-lvm] " Jonathan Lundell
2001-07-15 15:06 ` Jonathan Lundell
2001-07-15 15:22 ` Chris Wedgwood
2001-07-15 17:44 ` [linux-lvm] " Jonathan Lundell
2001-07-15 17:44 ` Jonathan Lundell
2001-07-15 17:47 ` [linux-lvm] " Justin T. Gibbs
2001-07-15 17:47 ` Justin T. Gibbs
2001-07-15 23:14 ` [linux-lvm] " Rod Van Meter
2001-07-15 23:14 ` Rod Van Meter
2001-07-16 0:37 ` Jonathan Lundell
2001-07-16 15:11 ` Rod Van Meter
2001-07-16 8:56 ` Chris Wedgwood
2001-07-16 13:19 ` [linux-lvm] " Daniel Phillips
2001-07-16 13:19 ` Daniel Phillips
2001-07-16 14:26 ` [linux-lvm] " Heinz J. Mauelshagen
2001-07-15 15:32 ` Alan Cox
2001-07-15 15:32 ` Alan Cox
2001-07-15 15:33 ` Chris Wedgwood
2001-07-15 16:24 ` Chris Wedgwood
2001-07-16 1:08 ` Albert D. Cahalan
2001-07-16 8:49 ` Chris Wedgwood
2001-07-21 19:18 ` Alexander Griesser
2001-07-22 3:52 ` Albert D. Cahalan
2001-07-23 14:41 ` Daniel Phillips
2001-07-24 4:29 ` Albert D. Cahalan
2001-07-24 11:45 ` Daniel Phillips
2001-07-14 17:33 ` [linux-lvm] " Jonathan Lundell
2001-07-14 17:33 ` Jonathan Lundell
2001-07-15 4:02 ` Chris Wedgwood
2001-07-15 5:46 ` [linux-lvm] " Jonathan Lundell
2001-07-15 5:46 ` Jonathan Lundell
2001-07-15 17:10 ` Chris Wedgwood
2001-07-15 17:39 ` Jonathan Lundell
2001-07-26 2:18 ` Ragnar Kjørstad
2001-07-26 16:24 ` Andreas Dilger
2001-08-10 19:42 ` Ben LaHaise
2001-08-10 19:51 ` Ragnar Kjørstad
2001-08-10 20:02 ` Ben LaHaise
2001-08-11 0:18 ` Steve Lord
2001-08-11 21:44 ` Matti Aarnio
2001-07-04 10:16 ` [RFC][PATCH] first cut 64 bit block support Chris Wedgwood
2001-07-04 16:59 ` Ben LaHaise
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010710154530.A18025@sistina.com \
--to=mauelshagen@sistina.com \
--cc=linux-lvm@sistina.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.