All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heinz Mauelshagen <mauelsha@ez-darmstadt.telekom.de>
To: linux-lvm@msede.com
Subject: Re: [linux-lvm] Swap/DB devices
Date: Wed, 21 Apr 1999 0:34:51 METDST	[thread overview]
Message-ID: <199904202237.AA04089@mailgate1b.telekom.de> (raw)


On Sat, 17 Apr 1999 21:03:50 +0100 (BST), Stephen Tweedie
<sct@redhat.com> said:

> 
> On Sat, 17 Apr 1999 13:22:29 METDST, Heinz Mauelshagen
> <mauelsha@ez-darmstadt.telekom.de> said:
> 
> > The LVM lib creates the device special nodes dynamically if a logical volume
> > is created by lvcreate(8) or found by vgscan(8)/vgimport(8).
> 
> > LVM function lv_create_node() has to be extended to create the raw
> > device too.  The LVM driver can then be accessed by that raw device
> > node _without_ modification.
> 
> No, it doesn't work that way.  The major/minor numbers for the raw
> devices are 100% meaningless.  Creating a raw device inode is all very
> well, but it won't do anything AT ALL until you have done a raw ioctl to
> bind it to a block device.

O.k., o.k ;*)

Didn't see your recent major raw-io rewrite which avoids
the problems of the earlier implementaion.

But my argument basically stays the same.

If i want to have raw i/o specials for the LVM, i'ld prefer to
extend the LVM library and the tools to do the job.
The user does have the option to create and bind them 'by hand' anyway.

> 
> As long as you can create the LVM block devices either in some known
> location or with some known block device number, you can then bind a raw
> device on top without any changes to the driver underneath.
> 

Yes.
Let the LVM lib/tools do it for the user.

Regards,
Heinz


--

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Systemmanagement C/S                             Deutsche Telekom AG
                                                 Entwicklungszentrum Darmstadt
Heinz Mauelshagen                                Otto-Roehm-Strasse 71c
Senior Systems Engineer                          Postfach 10 05 41
                                                 64205 Darmstadt
mge@ez-darmstadt.telekom.de                      Germany
                                                 +49 6151 886-425
                                                          FAX-386
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

             reply	other threads:[~1999-04-20 22:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-04-20 22:34 Heinz Mauelshagen [this message]
  -- strict thread matches above, loose matches on Subject: below --
1999-04-17 11:22 [linux-lvm] Swap/DB devices (fwd) Heinz Mauelshagen
1999-04-17 20:03 ` [linux-lvm] Swap/DB devices Stephen C. Tweedie
1999-04-15  8:18 Martyn.AYSHFORD
1999-04-15 14:10 ` Stephen C. Tweedie
1999-04-15 14:24 ` Heinz Mauelshagen
1999-04-16 20:43   ` Stephen C. Tweedie
1999-04-16 21:47     ` Heinz Mauelshagen
1999-04-17  0:14       ` Stephen C. Tweedie

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=199904202237.AA04089@mailgate1b.telekom.de \
    --to=mauelsha@ez-darmstadt.telekom.de \
    --cc=linux-lvm@msede.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.