From: Christoph Hellwig <hch@infradead.org>
To: Michael Clark <michael@metaparadigm.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Mark Peloquin <markpeloquin@hotmail.com>,
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 16:35:51 +0100 [thread overview]
Message-ID: <20021013163551.A18184@infradead.org> (raw)
In-Reply-To: <3DA98E48.9000001@metaparadigm.com>; from michael@metaparadigm.com on Sun, Oct 13, 2002 at 11:16:24PM +0800
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.
next prev parent reply other threads:[~2002-10-13 15:30 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 ` [Evms-devel] " Michael Clark
2002-10-13 13:49 ` Christoph Hellwig
2002-10-13 15:16 ` Michael Clark
2002-10-13 15:35 ` Christoph Hellwig [this message]
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=20021013163551.A18184@infradead.org \
--to=hch@infradead.org \
--cc=evms-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=markpeloquin@hotmail.com \
--cc=michael@metaparadigm.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).