linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Steve Pratt" <slpratt@us.ibm.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "Mark Peloquin" <peloquin@us.ibm.com>,
	torvalds@transmeta.com, linux-kernel@vger.kernel.org,
	evms-devel@lists.sourceforge.net
Subject: Re: [Evms-devel] Re: [PATCH] EVMS core 2/4: evms.h
Date: Fri, 4 Oct 2002 13:45:04 -0500	[thread overview]
Message-ID: <OF57AD2670.5A531CF2-ON85256C48.006578C9@pok.ibm.com> (raw)


Christoph Hellwig wrote:
>On Fri, Oct 04, 2002 at 08:34:02AM -0600, Andreas Dilger wrote:
>> On Oct 04, 2002  15:14 +0100, Christoph Hellwig wrote:
>> > > the IOCTL entry point is used to send to volumes.
>> > > the DIRECT_IOCTL entry point is used for point-
>> > > to-point ioctls between corresponding user space
>> > > and kernel space plugins.
>> >
>> > Do the ioctl directly to the device node of the lower layer plugin
instead.
>>
>> Not possible - EVMS doesn't export the lower-level device nodes at all.
>> That is one of the benefits - you can take 1000 drives and stack them
>> and raid and LVM them all you want, and you don't consume 1000*layers
>> device nodes.

>I don't think it's a benefit but really ugly.  There is no reason to now
>allow access to the lower layers.  How do I e.g. write a new volume label
to
>the lower level devices?

I am not sure I understand your question.  Did you mean that there does not
appear to be a **way** to access lower level devices or did you really mean
no reason to do so?  The reason to do so is for plug-ins such as MD which
may want to kick an array member out of the array which is a command
specific to MD.  The way in which this is accomplished in EVMS is as Mark
described above through the use of the DIRECT_IOCTL which allows for direct
communication to intermediate levels of an EVMS volume stack.

Note that this method is only used for certain cases like the MD one
described.  For normal IO type operations such as writing metadata or
changing volume labels, since EVMS in userspace knows about ALL of the
layers of the volume stack we can resolve all metadata writes to disk
relative offsets in our userspace config tools and thus don't have to write
to intermediate nodes to build more complex volumes.

Steve




             reply	other threads:[~2002-10-04 18:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-04 18:45 Steve Pratt [this message]
2002-10-07 17:25 ` [Evms-devel] Re: [PATCH] EVMS core 2/4: evms.h Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2002-10-04 14:59 Mark Peloquin
2002-10-04 13:59 Mark Peloquin
2002-10-03 18:59 Mark Peloquin
2002-10-04 14:14 ` Christoph Hellwig
2002-10-04 14:34   ` Andreas Dilger
2002-10-04 17:10     ` Christoph Hellwig
2002-10-03 17:42 Mark Peloquin
2002-10-04 12:28 ` Robert Varga
2002-10-04 14:08 ` Christoph Hellwig
2002-10-04 14:36   ` Richard B. Johnson
2002-10-03 12:36 Kevin Corry
2002-10-03 14:50 ` Christoph Hellwig
2002-10-03 15:10   ` [Evms-devel] " Michael Clark
2002-10-03 15:14     ` Christoph Hellwig
2002-10-03 16:22       ` Linus Torvalds

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=OF57AD2670.5A531CF2-ON85256C48.006578C9@pok.ibm.com \
    --to=slpratt@us.ibm.com \
    --cc=evms-devel@lists.sourceforge.net \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peloquin@us.ibm.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).