On 10/13/02 21:49, Christoph Hellwig wrote:
> On Sun, Oct 13, 2002 at 08:41:20PM +0800, Michael Clark wrote:
>
>>Exactly. I think Christoph is comparing it to the original md
>>architecture thich was more of an evolutionary design on the existing
>>block layer
>
>
> No, I do not. MD is in _no_ ways a volume managment framwork but just
> a few drivers that share common code. That's somethig entirely different.
So why then the requirement that internal remapping layers be
implemented as block devices?
>>it is merely an artifact of this that intermediary
>>devices were present (and consuming minors)
>
>
> I don not think cosumes minors is a valid design criteria for designing
> an inkernel framework.
Neither is implementing an internal logical remapping layer as a
block device just so you can do an ioctl directly to it.
>>in a well architected
>>volume manager, this is not necessary or desirable - not presenting
>>the intermediary devices is IMHO also a saftey feature preventing
>>access to devices that shouldn't be accessed.
>
>
> Please explain why they shouldn't be accessed. And following your
I think the point is really explaining why they _should_ be accessed.
If there is some valid reason other than having something you
can do an ioctl on.
> argumentation tell me why you haven't submitted a patch to Linus
> yet to disallow direct access to block devices that are in use
> by a filesystem.
I think the issue here is an md block device in use by another md block
device. Possbily becuase md's design precludes this (a design artifact)
(ie. md tools need access to the intermediary devices - users don't).
>>Yes, considering the abstraction (and the futureproofing this provides),
>>it would not make sense to bind these logical nodes to the orthogonal
>>block layer - which would probably also make maintenance more complex
>>in the future.
>
>
> Please explain the added complexity in detail. In fact it does remove
> complexity by having a standard set of object to work on, removing the
> need for code, data and data structure duplication. Before answering
> this mail I'd suggest you take a look at ldev_mgr.c in the evms
> tree in detail (and yes, that file is horribly broken implementation-wise,
> but this discussion is about the complexity it adds)
Yes, but the block device encapsulation here removes the need for plugins
to be implemented as block devices ie. removing complexity elsewhere.
I must admit to not being an expert on the block layer - but wouldn't
your suggesed approach mean intermediary layers would each have a
request queue and other unneeded stuff - if so, is this desirable?
(although i suspect i'm likely to be proved wrong - but i'm sure
there are issues with where you want your request queues - only on
the block devices exposed as volumes).
I still can't see the rationale of implementing instances of intermediary
remapping layers as block devices. Since you are the one that is objecting
to the current approach, the owness is on you to prove why an alternative
is needed.
>>I guess one of the advantages of the EVMS approach
>>is the ability for the core code to fit more easily with less changes
>>into kernels with differing block layers (2.4,2.5,future).
>
>
> This argument is NIL if the infrastructure is part of exactly that
> evolving block layer. You might have noticed that kernel code
> compatility to other releases is not really a criteria for the
> linux kernel development, btw..
I agree, maybe this would be worth doing for 2.7/2.8. In the meatime
do you think this would be feasible? - you are basically suggesting
a complete rewrite (or do you think you can do the rewrite to IBM's
satisfaction before the freeze ie. in the eternal linux kernel way,
you want it you write it ;). Me, i'm happy with the current approach
- but of course, i'm only a user ;).
~mc
On Sun, Oct 13, 2002 at 11:16:24PM +0800, Michael Clark wrote:
> On 10/13/02 21:49, Christoph Hellwig wrote:
> > On Sun, Oct 13, 2002 at 08:41:20PM +0800, Michael Clark wrote:
> >
> >>Exactly. I think Christoph is comparing it to the original md
> >>architecture thich was more of an evolutionary design on the existing
> >>block layer
> >
> >
> > No, I do not. MD is in _no_ ways a volume managment framwork but just
> > a few drivers that share common code. That's somethig entirely different.
>
> So why then the requirement that internal remapping layers be
> implemented as block devices?
I don't care how a single remapping layers is implemented. I want
the common Voulme managment API work on public nodes.
> Neither is implementing an internal logical remapping layer as a
> block device just so you can do an ioctl directly to it.
Not without hacks.
> I think the point is really explaining why they _should_ be accessed.
> If there is some valid reason other than having something you
> can do an ioctl on.
Because that
a) removes hacks like the EVMS pass-though
b) allows userspace to easily access it through read/write
>
> > argumentation tell me why you haven't submitted a patch to Linus
> > yet to disallow direct access to block devices that are in use
> > by a filesystem.
>
> I think the issue here is an md block device in use by another md block
> device. Possbily becuase md's design precludes this (a design artifact)
> (ie. md tools need access to the intermediary devices - users don't).
I'm not talksing about MD here. Why do you want to disallow people
using a device just it has another layer above it. E.g. write a change
to the ondisk structures (setting a flag, etcc..) is most logically
expressed by simple, O_DIRECT write to the actual device.
> Yes, but the block device encapsulation here removes the need for plugins
> to be implemented as block devices ie. removing complexity elsewhere.
> I must admit to not being an expert on the block layer - but wouldn't
> your suggesed approach mean intermediary layers would each have a
> request queue
It _coukd_ have a request queue, yes.
> and other unneeded stuff - if so, is this desirable?
What unneeded stuff? block device state contains no state relevant
to userspace access.
> > This argument is NIL if the infrastructure is part of exactly that
> > evolving block layer. You might have noticed that kernel code
> > compatility to other releases is not really a criteria for the
> > linux kernel development, btw..
>
> I agree, maybe this would be worth doing for 2.7/2.8.
Yes.
> In the meatime
> do you think this would be feasible? - you are basically suggesting
> a complete rewrite
Exactly.
> (or do you think you can do the rewrite to IBM's
> satisfaction before the freeze ie. in the eternal linux kernel way,
> you want it you write it ;). Me, i'm happy with the current approach
> - but of course, i'm only a user ;).
_I_ don't want to get EVMS in, sorry. I _do_ want a proper volume
managment framework, but I can live with it not beeing in before 2.8.
On 10/13, Christoph Hellwig said something like:
> On Sun, Oct 13, 2002 at 11:16:24PM +0800, Michael Clark wrote:
> > On 10/13/02 21:49, Christoph Hellwig wrote:
> > > On Sun, Oct 13, 2002 at 08:41:20PM +0800, Michael Clark wrote:
> _I_ don't want to get EVMS in, sorry. I _do_ want a proper volume
> managment framework, but I can live with it not beeing in before 2.8.
I think this is where you're going to get the most disagreement.
It was included in mainline, then it just goes away? Linus has no
obligation at all to include anything, but a lot of people depend
on it.
Yeah yeah, distros can include it at will, but mainline inclusion is the
best way to get large exposure and testing to the thing.
Having said all that, given that your premises are true regarding the
code design problems you have with EVMS, you have a valid point about
including it in mainline. The question is, is this good enough to ignore
having a logical device management system?!?
--
Shawn Leas
[email protected]
I put my air conditioner in backwards. It got cold outside.
The weatherman on TV was confused. "It was supposed to be hot
today."
-- Stephen Wright
On Mon, 14 Oct 2002, Shawn wrote:
> Having said all that, given that your premises are true regarding the
> code design problems you have with EVMS, you have a valid point about
> including it in mainline. The question is, is this good enough to ignore
> having a logical device management system?!?
You're acting like EVMS was the only logical volume manager out there.
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
On Mon, Oct 14, 2002 at 09:20:48AM -0500, Shawn wrote:
> Having said all that, given that your premises are true regarding the
> code design problems you have with EVMS, you have a valid point about
> including it in mainline. The question is, is this good enough to ignore
> having a logical device management system?!?
It is not good enough to ignore it. It is good enough to postpone
integration for 2.7.
Now that Al has sorted out lots of the block device mess in 2.5
I will work together with whoever is interested in it (i.e. the EVMS
folks) to integrate proper higher-level volume-management into
the kernel once the next unstable series opens.
Coing up with lots of code just before feature freeze is just not the way
infrastructure work is done Linux.
I hadn't heard comments yet that anyone thought of dm as ready yet.
This may be the case by now.
On 10/14, Rik van Riel said something like:
> On Mon, 14 Oct 2002, Shawn wrote:
>
> > Having said all that, given that your premises are true regarding the
> > code design problems you have with EVMS, you have a valid point about
> > including it in mainline. The question is, is this good enough to ignore
> > having a logical device management system?!?
>
> You're acting like EVMS was the only logical volume manager out there.
--
Shawn Leas
[email protected]
My grandfather invented Cliff's Notes. It all started back in 1912...
well, to make a long story short...
-- Stephen Wright
Am Montag, 14. Oktober 2002 18:21 schrieb Christoph Hellwig:
> On Mon, Oct 14, 2002 at 09:20:48AM -0500, Shawn wrote:
> > Having said all that, given that your premises are true regarding the
> > code design problems you have with EVMS, you have a valid point about
> > including it in mainline. The question is, is this good enough to ignore
> > having a logical device management system?!?
>
> It is not good enough to ignore it. It is good enough to postpone
> integration for 2.7.
No, that is not an option. Either evms or lvm2 it must be.
Switching later might be difficult. So it has to be decided
quite soon.
Regards
Oliver
On 10/14, Christoph Hellwig said something like:
> On Mon, Oct 14, 2002 at 09:20:48AM -0500, Shawn wrote:
> > Having said all that, given that your premises are true regarding the
> > code design problems you have with EVMS, you have a valid point about
> > including it in mainline. The question is, is this good enough to ignore
> > having a logical device management system?!?
>
> It is not good enough to ignore it. It is good enough to postpone
> integration for 2.7.
I just wish logical volume management in general had not been so
abandoned in mainline in the first place. I'm not saying Linus unfairly
excluded patches, and I'm not saying patches weren't available. I'm just
saying the dynamics of Linus and the maintainers did not allow for a
healthy LVM in mainline, resulting in decay.
If LVM1's destiny was to die during 2.5, then I wish there would have
been a replacement ready during 2.5's lifecycle. Otherwise, keep
creaking along with what's there, and fix it.
The larger question of volume management should have been addressed
before this whole mess happened. It really was, but LVM1 maintenance was
somewhat abandoned in favor of device mapper, and now it's broken, and
the holy wars are upon us again because many are in fear of losing
functionality important to them (at least the ubiquitous nature of the
functonality), and there is panic.
> Now that Al has sorted out lots of the block device mess in 2.5
> I will work together with whoever is interested in it (i.e. the EVMS
> folks) to integrate proper higher-level volume-management into
> the kernel once the next unstable series opens.
I look forward to it. In spite of my personal goals on this, I do
appreciate your pickiness.
> Coing up with lots of code just before feature freeze is just not the way
> infrastructure work is done Linux.
I just wish there were less veto-esque ways to handle EVMS in *-stable.
--
Shawn Leas
[email protected]
I put my air conditioner in backwards. It got cold outside.
The weatherman on TV was confused. "It was supposed to be hot
today."
-- Stephen Wright
On 10/14, Oliver Neukum said something like:
> Am Montag, 14. Oktober 2002 18:21 schrieb Christoph Hellwig:
> > On Mon, Oct 14, 2002 at 09:20:48AM -0500, Shawn wrote:
> > > Having said all that, given that your premises are true regarding the
> > > code design problems you have with EVMS, you have a valid point about
> > > including it in mainline. The question is, is this good enough to ignore
> > > having a logical device management system?!?
> >
> > It is not good enough to ignore it. It is good enough to postpone
> > integration for 2.7.
>
> No, that is not an option. Either evms or lvm2 it must be.
> Switching later might be difficult. So it has to be decided
> quite soon.
I know this has the potential of being an unfortunate situation for
many, but edicts do not help.
If neither LVM2 or EVMS are truly ready, no one is beholden to anyone
else as to anything's inclusion in mainline.
It's a matter of marketing so say whether Linux has volume management.
If all the distros have LVM in some form, then "Linux has an LVM". So,
no one can really say "Linux doesn't have an LVM so it's not enterprise
ready.
It's just really inconvenient for those who
1. want to run a devel kernel
2. want to run an LVM
3. want to be really really up-to-date
because we (the testers) have to do a lot of the forward porting grunt
work fixing all the patch rejects and compile errors that inevitably
come.
--
Shawn Leas
[email protected]
I have a hobby...I have the world's largest collection of sea shells.
I keep it scattered on beaches all over the world. Maybe you've seen
some of it...
-- Stephen Wright
> If neither LVM2 or EVMS are truly ready, no one is beholden to anyone
> else as to anything's inclusion in mainline.
>
> It's a matter of marketing so say whether Linux has volume management.
> If all the distros have LVM in some form, then "Linux has an LVM". So,
> no one can really say "Linux doesn't have an LVM so it's not enterprise
> ready.
This is not true. Something has to be in the mainline, so that bugs can
be fixed. This too important to be left to distributors.
Besides people who compile their own kernels are not that unimportant.
Regards
Oliver
On 10/14, Oliver Neukum said something like:
>
> > If neither LVM2 or EVMS are truly ready, no one is beholden to anyone
> > else as to anything's inclusion in mainline.
> >
> > It's a matter of marketing so say whether Linux has volume management.
> > If all the distros have LVM in some form, then "Linux has an LVM". So,
> > no one can really say "Linux doesn't have an LVM so it's not enterprise
> > ready.
>
> This is not true. Something has to be in the mainline, so that bugs can
> be fixed. This too important to be left to distributors.
As I said before, edicts help no one. I appreciate your sentiment, and
to some degree share it, but you have to take a non-cheerleader look at
things like this.
> Besides people who compile their own kernels are not that unimportant.
No one is saying that. No one is even saying that mainline inclusion
isn't extremely beneficial to EVMS or DM. The question isn't whether DM
or EVMS would be impacted more positively if it were included. The
question is whether mainline would be better off including them, and not
the other way around.
Also, let me define the phrase "better off" to mean "better off W.R.T.
design, architecture, overall code quality, abstractions in the right
place, etc etc", and not to mean politically, as in, more users.
Honestly though, if you aren't able to do the work it takes to be a 3rd
party patch tester, it's less likely you can properly test or submit
proper bug reports in the first place.
--
Shawn Leas
[email protected]
I had some eyeglasses. I was walking down the street when
suddenly the prescription ran out.
-- Stephen Wright
On Tue, 15 Oct 2002, Oliver Neukum wrote:
>
> > If neither LVM2 or EVMS are truly ready, no one is beholden to anyone
> > else as to anything's inclusion in mainline.
> >
> > It's a matter of marketing so say whether Linux has volume management.
> > If all the distros have LVM in some form, then "Linux has an LVM". So,
> > no one can really say "Linux doesn't have an LVM so it's not enterprise
> > ready.
>
> This is not true. Something has to be in the mainline, so that bugs can
> be fixed. This too important to be left to distributors.
>
> Besides people who compile their own kernels are not that unimportant.
As for the bugs getting fixed, one of the main problems with EVMS merge
now is that it (as any merge) shifts part of that very burden from EVMS
maintainers to other developers *and* *it* *shifts* *too* *much*.
That's what "ready to be merged" boils down to. It's a question of how
many problems will be inflicted by the merge upon current and future
development - over all kernel. AFAICS in its current state EVMS is not
ready. And yes, it means that EVMS maintainers get to play catch up for
a while. Nobody refuses to help them, BTW.
> As I said before, edicts help no one. I appreciate your sentiment, and
> to some degree share it, but you have to take a non-cheerleader look at
> things like this.
I'd be happy if there were no such problem.
> > Besides people who compile their own kernels are not that unimportant.
>
> No one is saying that. No one is even saying that mainline inclusion
> isn't extremely beneficial to EVMS or DM. The question isn't whether DM
> or EVMS would be impacted more positively if it were included. The
> question is whether mainline would be better off including them, and not
> the other way around.
>
> Also, let me define the phrase "better off" to mean "better off W.R.T.
> design, architecture, overall code quality, abstractions in the right
> place, etc etc", and not to mean politically, as in, more users.
While these are important choices, Linux is an OS for practical use
and needs to meet some minimum of necessary features.
> Honestly though, if you aren't able to do the work it takes to be a 3rd
> party patch tester, it's less likely you can properly test or submit
> proper bug reports in the first place.
That's not the problem. There'd be bug reports from half a dozen vendor
kernels, one incorporating lvm2, the other evms and probably several
versions of them plus their own kernel patches.
A gigantic mess.
Regards
Oliver
On Tue, 15 Oct 2002, Oliver Neukum wrote:
> > Also, let me define the phrase "better off" to mean "better off W.R.T.
> > design, architecture, overall code quality, abstractions in the right
> > place, etc etc", and not to mean politically, as in, more users.
>
> While these are important choices, Linux is an OS for practical use
> and needs to meet some minimum of necessary features.
Come back when you are in position to make demands. Until then, feel
free to bugger off.
Arrogant demands are _not_ going to impress anybody - $DEITY witness,
arrogance is not in short supply around here and with waay better
credentials to back it up.
If you are willing to help EVMS folks - go ahead and offer them your help in
cleaning the codebase up. _That_ can change situation. Public wankathlon
will earn you a warm spot in killfiles and fail to affect any merges in
any direction.
*plonk*
Am Dienstag, 15. Oktober 2002 01:16 schrieb Alexander Viro:
> On Tue, 15 Oct 2002, Oliver Neukum wrote:
> > > Also, let me define the phrase "better off" to mean "better off W.R.T.
> > > design, architecture, overall code quality, abstractions in the right
> > > place, etc etc", and not to mean politically, as in, more users.
> >
> > While these are important choices, Linux is an OS for practical use
> > and needs to meet some minimum of necessary features.
>
> Come back when you are in position to make demands. Until then, feel
> free to bugger off.
Demands? That was an oppinion, not a demand. And a little civility would
suit you just fine.
> Arrogant demands are _not_ going to impress anybody - $DEITY witness,
> arrogance is not in short supply around here and with waay better
> credentials to back it up.
>
> If you are willing to help EVMS folks - go ahead and offer them your help
> in cleaning the codebase up. _That_ can change situation. Public
> wankathlon will earn you a warm spot in killfiles and fail to affect any
> merges in any direction.
I did improvements to it to the best of my abilities, which as I freely admit
lesser than yours.
If a short civilised discussion earns me a place in your killfiles I'll happily
reside there.
Oliver
On Mon, Oct 14, 2002 at 07:16:22PM -0400, Alexander Viro wrote:
> If you are willing to help EVMS folks - go ahead and offer them your help in
> cleaning the codebase up.
They refused my patches.
Does anyone want me to dig them up?
Andrew
On Mon, Oct 14, 2002 at 04:47:30PM -0500, Shawn wrote:
> On 10/14, Christoph Hellwig said something like:
> > On Mon, Oct 14, 2002 at 09:20:48AM -0500, Shawn wrote:
> > > Having said all that, given that your premises are true regarding the
> > > code design problems you have with EVMS, you have a valid point about
> > > including it in mainline. The question is, is this good enough to ignore
> > > having a logical device management system?!?
> >
> > It is not good enough to ignore it. It is good enough to postpone
> > integration for 2.7.
>
> I just wish logical volume management in general had not been so
> abandoned in mainline in the first place. I'm not saying Linus unfairly
> excluded patches, and I'm not saying patches weren't available. I'm just
> saying the dynamics of Linus and the maintainers did not allow for a
> healthy LVM in mainline, resulting in decay.
>
> If LVM1's destiny was to die during 2.5, then I wish there would have
> been a replacement ready during 2.5's lifecycle. Otherwise, keep
> creaking along with what's there, and fix it.
True, we aim to replace the LVM1 driver with device-mapper in 2.5, which we
strongly believe to be a first step to generic volume management in the kernel.
Feel free to blame us that we didn't have more capacity to
make it happen earlier ;-)
device-mapper is in the -ac kernel since last week. Thanks Alan.
Please have a look at the rather small amount of clean code.
>
> The larger question of volume management should have been addressed
> before this whole mess happened. It really was, but LVM1 maintenance was
> somewhat abandoned in favor of device mapper, and now it's broken, and
> the holy wars are upon us again because many are in fear of losing
> functionality important to them (at least the ubiquitous nature of the
> functonality), and there is panic.
There's no need to be afraid because device-mapper and the LVM2 tools offer
a compatible path _now_ supporting all given LVM1 configurations.
The device-mapper code has already been merged by Alan (which is a very good
approval IMNSHO) and is rather easy to overlook.
Please help us and have a look...
>
> > Now that Al has sorted out lots of the block device mess in 2.5
> > I will work together with whoever is interested in it (i.e. the EVMS
> > folks) to integrate proper higher-level volume-management into
> > the kernel once the next unstable series opens.
>
> I look forward to it. In spite of my personal goals on this, I do
> appreciate your pickiness.
>
> > Coing up with lots of code just before feature freeze is just not the way
> > infrastructure work is done Linux.
>
> I just wish there were less veto-esque ways to handle EVMS in *-stable.
>
> --
> Shawn Leas
> [email protected]
>
> I put my air conditioner in backwards. It got cold outside.
> The weatherman on TV was confused. "It was supposed to be hot
> today."
> -- Stephen Wright
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Evms-devel mailing list
> [email protected]
> To subscribe/unsubscribe, please visit:
> https://lists.sourceforge.net/lists/listinfo/evms-devel
--
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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-