From: Michael Clark <michael@metaparadigm.com>
To: Mark Peloquin <markpeloquin@hotmail.com>
Cc: hch@infradead.org, linux-kernel@vger.kernel.org,
torvalds@transmeta.com, evms-devel@lists.sourceforge.net
Subject: Re: [Evms-devel] Re: Linux v2.5.42
Date: Sun, 13 Oct 2002 20:41:20 +0800 [thread overview]
Message-ID: <3DA969F0.1060109@metaparadigm.com> (raw)
In-Reply-To: F87rkrlMjzmfv2NkkSD000144a9@hotmail.com
On 10/13/02 01:14, Mark Peloquin wrote:
> On 2002-10-12 13:32:33, Christoph Hellwig wrote:
>
>> The problem in my eyes is that large
>> parts of what evms does should be in the higher layers, i.e. the
>> block layer, but they implement their own new layer as the consumer > of
>> those. i.e. instead of using the generic block layer structures to
>> present a volume/device they use their own,
>
>
> More accurately, we do use generic block layers structures to present
> volumes that are visible to the user/system.
Exactly. I think Christoph is comparing it to the original md
architecture thich was more of an evolutionary design on the existing
block layer - it is merely an artifact of this that intermediary
devices were present (and consuming minors) - 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.
>> private structures that
>> need hacks to get the access right (pass-through ioctls) and need
>> constant resyncing with the native structures in the case where we
>> have both (the lowest layer).
>
>
> The point of contention is that EVMS does not provide generic access
> (block layer operations) to the components that make up the volume, but
> only to the user/system accessible volumes themselves. EVMS consumes
> (primarily disk) devices and produces volumes. The intermediate points
> are abstracted by the volume manager.
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. 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).
~mc
next prev parent reply other threads:[~2002-10-13 12:35 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-12 17:14 Linux v2.5.42 Mark Peloquin
2002-10-12 19:34 ` Alan Cox
2002-10-12 19:37 ` jbradford
2002-10-13 23:55 ` Rob Landley
2002-10-13 12:41 ` Michael Clark [this message]
2002-10-13 13:49 ` [Evms-devel] " Christoph Hellwig
2002-10-13 15:16 ` Michael Clark
2002-10-13 15:35 ` Christoph Hellwig
2002-10-13 16:11 ` Brian Jackson
2002-10-13 16:26 ` Arjan van de Ven
2002-10-13 17:06 ` Brian Jackson
2002-10-13 19:58 ` Mark Hahn
2002-10-13 19:57 ` Rik van Riel
2002-10-13 20:26 ` Sean Neakums
2002-10-24 11:45 ` Alexander Kellett
2002-10-13 19:59 ` Andrew Morton
2002-10-13 20:24 ` Bernd Eckenfels
2002-10-14 15:11 ` Christoph Hellwig
2002-10-14 22:27 ` Bernd Eckenfels
2002-10-14 4:55 ` [Evms-devel] " Andreas Dilger
2002-10-13 17:46 ` Robert Love
2002-10-13 18:34 ` Brian Jackson
2002-10-14 4:23 ` [Evms-devel] " Andreas Dilger
2002-10-14 16:08 ` Christoph Hellwig
2002-10-14 14:45 ` Christoph Hellwig
2002-10-13 16:18 ` [Evms-devel] " Michael Clark
2002-10-13 17:10 ` Alexander Viro
2002-10-13 17:41 ` Michael Clark
2002-10-14 4:43 ` Andreas Dilger
2002-10-14 16:16 ` Christoph Hellwig
2002-10-14 15:21 ` Christoph Hellwig
2002-10-14 14:42 ` Shawn
2002-10-14 15:15 ` Christoph Hellwig
2002-10-14 14:20 ` Shawn
2002-10-14 16:15 ` Rik van Riel
2002-10-14 21:34 ` Shawn
2002-10-14 16:21 ` Christoph Hellwig
2002-10-14 16:38 ` Jeff Garzik
2002-10-14 21:47 ` Shawn
2002-10-15 7:42 ` Heinz J . Mauelshagen
2002-10-14 21:48 ` Oliver Neukum
2002-10-14 21:55 ` Shawn
2002-10-14 22:35 ` Oliver Neukum
2002-10-14 22:53 ` Shawn
2002-10-14 23:04 ` Oliver Neukum
2002-10-14 23:16 ` Alexander Viro
2002-10-14 23:30 ` Oliver Neukum
2002-10-15 0:10 ` Andrew Clausen
2002-10-14 22:57 ` Alexander Viro
2002-10-13 13:41 ` Christoph Hellwig
2002-10-14 23:57 [Evms-devel] " Mark Peloquin
2002-10-15 14:51 Steve Pratt
2002-10-15 21:18 ` Andrew Clausen
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=3DA969F0.1060109@metaparadigm.com \
--to=michael@metaparadigm.com \
--cc=evms-devel@lists.sourceforge.net \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=markpeloquin@hotmail.com \
--cc=torvalds@transmeta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).