linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
* [linux-lvm] Swap/DB devices
@ 1999-04-15  8:18 Martyn.AYSHFORD
  1999-04-15 14:10 ` Stephen C. Tweedie
  1999-04-15 14:24 ` Heinz Mauelshagen
  0 siblings, 2 replies; 8+ messages in thread
From: Martyn.AYSHFORD @ 1999-04-15  8:18 UTC (permalink / raw)
  To: linux-lvm

I'm in the process of re-jigging all the file systems to sit in volume
groups.

Two questions :-

a) Can I setup swap to run from a volume group is it a good idea?

b) I have  database devices running in cooked file systems for Oracle,
Sybase and Informix.

Vendor recommendations for sybase and Informix are normally raw, here we
carve our database devices from HP volume groups is this a good idea for
linux?

Anybody done this?

mja

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [linux-lvm] Swap/DB devices
  1999-04-15  8:18 [linux-lvm] Swap/DB devices Martyn.AYSHFORD
@ 1999-04-15 14:10 ` Stephen C. Tweedie
  1999-04-15 14:24 ` Heinz Mauelshagen
  1 sibling, 0 replies; 8+ messages in thread
From: Stephen C. Tweedie @ 1999-04-15 14:10 UTC (permalink / raw)
  To: Martyn.AYSHFORD; +Cc: linux-lvm, Stephen Tweedie

Hi,

On Thu, 15 Apr 1999 09:18:49 +0100, Martyn.AYSHFORD@orange.co.uk said:

> I'm in the process of re-jigging all the file systems to sit in volume
> groups.

> a) Can I setup swap to run from a volume group is it a good idea?

Should work OK.

> b) I have  database devices running in cooked file systems for Oracle,
> Sybase and Informix.

> Vendor recommendations for sybase and Informix are normally raw, here we
> carve our database devices from HP volume groups is this a good idea for
> linux?

We have raw IO under development: look on

	ftp://ftp.uk.linux.org/pub/linux/sct/fs

for my latest snapshots.  This should be usable by any of the
commercial databases, and we have Linus's approval in principle for
this mechanism of implementing the raw transfers.

--Stephen

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [linux-lvm] Swap/DB devices
  1999-04-15  8:18 [linux-lvm] Swap/DB devices 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
  1 sibling, 1 reply; 8+ messages in thread
From: Heinz Mauelshagen @ 1999-04-15 14:24 UTC (permalink / raw)
  To: Martyn.AYSHFORD; +Cc: linux-lvm, mge

> 
> I'm in the process of re-jigging all the file systems to sit in volume
> groups.
> 
> Two questions :-
> 
> a) Can I setup swap to run from a volume group is it a good idea?

Yes.
It's as good as partition based swap (very low LVM driver overhead).

Please take i/o amounts into consideration and avoid to allocate swap LVs
and other i/o intensive LVs on the same PVs.

> 
> b) I have  database devices running in cooked file systems for Oracle,
> Sybase and Informix.
> 
> Vendor recommendations for sybase and Informix are normally raw, here we
> carve our database devices from HP volume groups is this a good idea for
> linux?

There is a raw device patch available by Stephen Tweedie.
IIRC it will make it into the 2.3 kernel (what do you say Stephen?).

LVM has to be enhanced a little bit to support that patch.

> 
> Anybody done this?
> 

Yes, i did successfull tests with a lot of swap LVs.
Anybody out there with (big) database installations on LVM?

BTW: you can have performance boosts by setting up striped LVs
     if your hardware setup is o.k. (enough i/o bandwith on scsi busses,
     several busses ...)
     


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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [linux-lvm] Swap/DB devices
  1999-04-15 14:24 ` Heinz Mauelshagen
@ 1999-04-16 20:43   ` Stephen C. Tweedie
  1999-04-16 21:47     ` Heinz Mauelshagen
  0 siblings, 1 reply; 8+ messages in thread
From: Stephen C. Tweedie @ 1999-04-16 20:43 UTC (permalink / raw)
  To: Heinz Mauelshagen; +Cc: Martyn.AYSHFORD, linux-lvm, mge

Hi,

On Thu, 15 Apr 1999 16:24:10 METDST, Heinz Mauelshagen
<mauelsha@ez-darmstadt.telekom.de> said:

> There is a raw device patch available by Stephen Tweedie.
> IIRC it will make it into the 2.3 kernel (what do you say Stephen?).

That's the plan; Linus has approved it in principle.

> LVM has to be enhanced a little bit to support that patch.

I'm curious: why?  I would have thought that LVM should support any
requests coming in through ll_rw_block already.

--Stephen

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [linux-lvm] Swap/DB devices
  1999-04-16 20:43   ` Stephen C. Tweedie
@ 1999-04-16 21:47     ` Heinz Mauelshagen
  1999-04-17  0:14       ` Stephen C. Tweedie
  0 siblings, 1 reply; 8+ messages in thread
From: Heinz Mauelshagen @ 1999-04-16 21:47 UTC (permalink / raw)
  To: sct; +Cc: mge, linux-lvm

> 
> On Thu, 15 Apr 1999 16:24:10 METDST, Heinz Mauelshagen
> <mauelsha@ez-darmstadt.telekom.de> said:
> 
> > There is a raw device patch available by Stephen Tweedie.
> > IIRC it will make it into the 2.3 kernel (what do you say Stephen?).
> 

On Fri, 16 Apr 1999 21:43:48 +0100 (BST), Stephen Tweedie
<sct@redhat.com> said:
>
> That's the plan; Linus has approved it in principle.
> 
> > LVM has to be enhanced a little bit to support that patch.
> 
> I'm curious: why?  I would have thought that LVM should support any
> requests coming in through ll_rw_block already.
> 

It's simply a matter of userland (lv_create_node() and friends in lvmlib)
to create the LVM 'raw' device specials.
Only regular buffer cached device specials are created up to 0.6.

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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [linux-lvm] Swap/DB devices
  1999-04-16 21:47     ` Heinz Mauelshagen
@ 1999-04-17  0:14       ` Stephen C. Tweedie
  0 siblings, 0 replies; 8+ messages in thread
From: Stephen C. Tweedie @ 1999-04-17  0:14 UTC (permalink / raw)
  To: Heinz Mauelshagen; +Cc: sct, mge, linux-lvm

Hi,

On Fri, 16 Apr 1999 23:47:06 METDST, Heinz Mauelshagen
<mauelsha@ez-darmstadt.telekom.de> said:

>> I'm curious: why?  I would have thought that LVM should support any
>> requests coming in through ll_rw_block already.

> It's simply a matter of userland (lv_create_node() and friends in lvmlib)
> to create the LVM 'raw' device specials.
> Only regular buffer cached device specials are created up to 0.6.

You won't need to.  The raw device patches create one single new major
number, and let you bind the minor numbers to any block devices you
want.  You can access _any_ block device driver without modification.

--Stephen

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [linux-lvm] Swap/DB devices
@ 1999-04-20 22:34 Heinz Mauelshagen
  0 siblings, 0 replies; 8+ messages in thread
From: Heinz Mauelshagen @ 1999-04-20 22:34 UTC (permalink / raw)
  To: linux-lvm


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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [linux-lvm] Swap/DB devices
  1999-04-17 11:22 [linux-lvm] Swap/DB devices (fwd) Heinz Mauelshagen
@ 1999-04-17 20:03 ` Stephen C. Tweedie
  0 siblings, 0 replies; 8+ messages in thread
From: Stephen C. Tweedie @ 1999-04-17 20:03 UTC (permalink / raw)
  To: Heinz Mauelshagen; +Cc: linux-lvm, Stephen Tweedie

Hi,

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.

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.

--Stephen

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~1999-04-20 22:34 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-04-15  8:18 [linux-lvm] Swap/DB devices 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
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-20 22:34 Heinz Mauelshagen

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).