[linux-lvm] Can we make char files not blocked for the volumes

[linux-lvm] Can we make char files not blocked for the volumes

[Chris Anderson]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

Can lvm create char devices not blocked for the volumes?

Did a listing in the volume group dir.  Note the char device file
(group).  How can we make the other files / volumes the same.  Informix
wants char devices not blocked.  I seem to note that linux does not
really treat them different but...

$ ls -l

crw-r-----   1 root     root     109,   0 Jan 29 18:46 group
brw-rw----   1 informix informix  58,   1 Jan 29 19:10 infx_data1
brw-rw----   1 informix informix  58,   0 Jan 29 19:09 infx_root

Thanks,

   Chris Anderson
    chris@alwan.com


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 2730 bytes --]

Re: [linux-lvm] Can we make char files not blocked for the volumes

[Heinz Mauelshagen]

Please have a look at the rawio support for Linux.
This enables you to create raw devices for every block device in the system
including the LVM ones.

Heinz

> Can lvm create char devices not blocked for the volumes?
> 
> Did a listing in the volume group dir.  Note the char device file
> (group).  How can we make the other files / volumes the same.  Informix
> wants char devices not blocked.  I seem to note that linux does not
> really treat them different but...
> 
> $ ls -l
> 
> crw-r-----   1 root     root     109,   0 Jan 29 18:46 group
> brw-rw----   1 informix informix  58,   1 Jan 29 19:10 infx_data1
> brw-rw----   1 informix informix  58,   0 Jan 29 19:09 infx_root
> 
> Thanks,
> 
>    Chris Anderson
>     chris@alwan.com
> 
Content-Description: S/MIME Cryptographic Signature

[Attachment, skipping...]


-- 

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

Systemmanagement CS-TS                           T-Nova
                                                 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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] Can we make char files not blocked for the volumes

[Chris Anderson]

[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]

Heinz Mauelshagen wrote:

> Please have a look at the rawio support for Linux.

Where can I find this?  In the kernel?  Any help would be great.

>
> This enables you to create raw devices for every block device in the system
> including the LVM ones.
>
> Heinz
>
> > Can lvm create char devices not blocked for the volumes?
> >
> > Did a listing in the volume group dir.  Note the char device file
> > (group).  How can we make the other files / volumes the same.  Informix
> > wants char devices not blocked.  I seem to note that linux does not
> > really treat them different but...
> >
> > $ ls -l
> >
> > crw-r-----   1 root     root     109,   0 Jan 29 18:46 group
> > brw-rw----   1 informix informix  58,   1 Jan 29 19:10 infx_data1
> > brw-rw----   1 informix informix  58,   0 Jan 29 19:09 infx_root
> >
> > Thanks,
> >
> >    Chris Anderson
> >     chris@alwan.com
> >
> Content-Description: S/MIME Cryptographic Signature
>
> [Attachment, skipping...]
>
> --
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
> Systemmanagement CS-TS                           T-Nova
>                                                  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
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 2730 bytes --]

Re: [linux-lvm] Can we make char files not blocked for the volumes

[Stephen C. Tweedie]

Hi,

On Sat, 19 Feb 2000 07:08:29 -0600, Chris Anderson <chris@alwan.com> said:

> Heinz Mauelshagen wrote:
>> Please have a look at the rawio support for Linux.

> Where can I find this?  In the kernel?  Any help would be great.

2.3 has it, and there are 2.2 patches on 

ftp://ftp.uk.linux.org/pub/linux/sct/fs/raw-io

It comes with all recent Red Hat and SuSE distributions as standard,
btw.  I'm not sure about other distributions (anyone know?)

--Stephen

Re: [linux-lvm] Can we make char files not blocked for the volumes

[Chris Anderson]

[-- Attachment #1.1: Type: text/plain, Size: 1377 bytes --]

"Stephen C. Tweedie" wrote:

> Hi,
>
> On Sat, 19 Feb 2000 07:08:29 -0600, Chris Anderson <chris@alwan.com> said:
>
> > Heinz Mauelshagen wrote:
> >> Please have a look at the rawio support for Linux.
>
> > Where can I find this?  In the kernel?  Any help would be great.
>
> 2.3 has it, and there are 2.2 patches on
>
> ftp://ftp.uk.linux.org/pub/linux/sct/fs/raw-io

Thanks.  I used the link and download the files.

 It is odd how it is used.  I had to hack it into 2.2.14, but go it working.
I think the "raw" command is odd, also it needs to be run every time you
reboot.  Also who is the owner of this code. How does it find its way into
the standard 2.3 and lvm has not yet?  That is odd too.

My test with Informix IDS 7.3 for linux showed that the raw io is twice as
slow.  A 17 mins load under block device using lvm but took 31mins for the
raw linked version.  I will be testing the Informix 9.2 version tonight.  I
could not find much doc from informix other then the device need to be
char/raw.

Anyone using raw out there?  Did you find that you must call raw at reboot to
link back?  Who is the owner of the code?  What are the next step for the raw
code? Any thing would be great?

Thanks,

   Chris Anderson

>
>
> It comes with all recent Red Hat and SuSE distributions as standard,
> btw.  I'm not sure about other distributions (anyone know?)
>
> --Stephen

[-- Attachment #1.2: Type: text/html, Size: 1743 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 2730 bytes --]

Re: [linux-lvm] Can we make char files not blocked for the volumes

[Andi Kleen]

On Mon, Feb 21, 2000 at 04:45:06PM -0600, Chris Anderson wrote:
> "Stephen C. Tweedie" wrote:
> 
> > Hi,
> >
> > On Sat, 19 Feb 2000 07:08:29 -0600, Chris Anderson <chris@alwan.com> said:
> >
> > > Heinz Mauelshagen wrote:
> > >> Please have a look at the rawio support for Linux.
> >
> > > Where can I find this?  In the kernel?  Any help would be great.
> >
> > 2.3 has it, and there are 2.2 patches on
> >
> > ftp://ftp.uk.linux.org/pub/linux/sct/fs/raw-io
> 
> Thanks.  I used the link and download the files.
> 
>  It is odd how it is used.  I had to hack it into 2.2.14, but go it working.
> I think the "raw" command is odd, also it needs to be run every time you
> reboot.  Also who is the owner of this code. How does it find its way into
> the standard 2.3 and lvm has not yet?  That is odd too.

LVM is in 2.3.47.

> My test with Informix IDS 7.3 for linux showed that the raw io is twice as
> slow.  A 17 mins load under block device using lvm but took 31mins for the
> raw linked version.  I will be testing the Informix 9.2 version tonight.  I
> could not find much doc from informix other then the device need to be
> char/raw.

rawio does not do any caching (as the name says), so you probably 
need to configure the database to cache more on itself.  


-Andi

[linux-lvm] LVM Petition (Or, page-to-show-our-interest-for-LVM-in-the-Kernel :)

[Dominic J. Eidson]

On Tue, 22 Feb 2000, Andi Kleen wrote:

> LVM is in 2.3.47.

This is I'm sure a great day for us all - I noticed this, went to add it
to the "news" section on the petition page (I've been told "petition" was
a poor word choice, but at the time I couldn't think of anything better -
and the name (as taken from the subject) would sound a little funny... ;)
- I also updated all the links to point to the correct posts (apologies
for not noticing it before - the archives changed, and all links to the
posts changed with it..) - anyways, I just thought I'd post my 2 cents
worth of trivial information before I go back to lurking...


Dominic

P.S> Finally got to play with LVM on a SuSE box here at work... Aah, feels
good to be back in good old LVM-land again... :)

-- 
Dominic J. Eidson
                                         "Baruk Khazad! Khazad ai-menu!" - Gimli
--------------------------------------------------------------------------------
http://www.the-infinite.org/               http://www.the-infinite.org/~dominic/

Re: [linux-lvm] Can we make char files not blocked for the volumes

[Stephen C. Tweedie]

Hi,

On Mon, 21 Feb 2000 16:45:06 -0600, Chris Anderson <chris@alwan.com>
said:

>  It is odd how it is used.  I had to hack it into 2.2.14, but go it working.
> I think the "raw" command is odd, also it needs to be run every time you
> reboot.  

Indeed --- the raw interfaces need to be bound to specific devices just
as eth* network interface names need to be bound to addresses.

> Also who is the owner of this code. How does it find its way into
> the standard 2.3 and lvm has not yet?  That is odd too.

lvm just took a little longer --- they are both in 2.3 now.

> My test with Informix IDS 7.3 for linux showed that the raw io is twice as
> slow.  A 17 mins load under block device using lvm but took 31mins for the
> raw linked version.  I will be testing the Informix 9.2 version
> tonight. 

Raw IO does not do any caching in the O/S.  Specifically, it doesn't
perform any readahead or writebehind.  If the application was using
that implicit caching then raw IO will necessarily be slower.

--Stephen