RE: IDS on AIX 5.2 Offsets? lv types?
malcolm weallans
Murray,
I hate to disagree but I have discovered information
in the IBM web-site that refers to the Logical volume
control block (Lvcb) being 512 bytes. So why would an
8K offset be needed? I can't get any definitve
statement out of IBM tech support. I've called our
support company and they have contacted Informix in
the UK, but no answer if forthcoming. Is this because
they are afraid to make a definitive statement in case
they are wrong? Or is it that they just don't know?
regards
Malcolm
--- "Murray Wood (IList)" <ifxma...@quanta.co.nz>
wrote: > Malcolm
>
> We have exactly the same issue on AIX. You must use
> an offset of 8Kb (I think) for every logical volume
> on AIX 5. Its only an issue if you need the AIX
> control info - which is required if you have a disk
> failure and need to re-mirror the logical volume.
>
> Similarly at the front of the disk on Solaris, you
> cannot use the first disk block (normally 4Kb) as it
> contains the disk partition table. Either create
> the logical volume from block 1 or use a 4Kb offset.
>
> MW
>
> > -----Original Message-----
> > From: owner-inf...@iiug.org
> > [mailto:owner-inf...@iiug.org]On Behalf Of
> malcolm weallans
> > Sent: Friday, 30 July 2004 3:06 a.m.
> > To: inform...@iiug.org
> > Subject: IDS on AIX 5.2 Offsets? lv types?
> >
> >
> > We are running IDS 9.3 on AIX 5.2. We have
> discovered
> > that on AIX 5.2 the logical volume control block
> gets
> > corrupted if offset 0 is used. This doesn't
> normally
> > cause problems until the volume group is exported
> and
> > imported.
> >
> > We also have a problem with defining logical
> volume
> > type. Some installers are setting up the system
> with
> > the lv type set to jfs whilst others are setting
> it to
> > raw.
> >
> > I would welcome any advice on the correct settings
> for
> > offset and lv type, and more importantly any
> advice on
> > what I should do to migrate the system to the
> correct
> > settings.
> >
> > regards
> >
> > Malcolm
> > sending to informix-list
>
> sending to informix-list
>
sending to informix-list
Neil Truby
"malcolm weallans" <malcol...@btopenworld.com> wrote in message
news:cel0f5$32f$1...@news.xmission.com...
>
> Murray,
> I hate to disagree but I have discovered information
> in the IBM web-site that refers to the Logical volume
> control block (Lvcb) being 512 bytes.
Why does it matter? If 8k has been found to be adequate to circumvent the
problem, but you *could* actually get away with less, surely th difference
is so small as to be not worth fretting about?
Alexey Sonkin
Malcolm,
If your logical volumes are located on a disk array
(RAUD 10 or 5), then making offset not proportional to
the database page size is really bad for performance reasons.
The problem is that some (single) page reads would require access to
two disk drives in case offset is not a multiple of page size (4k on AIX)
------------------------------------------
Alexey Sonkin
> -----Original Message-----
> From: malcolm weallans [mailto:malcol...@btopenworld.com]
>
> Murray,
> I hate to disagree but I have discovered information
> in the IBM web-site that refers to the Logical volume
> control block (Lvcb) being 512 bytes. So why would an
> 8K offset be needed?
sending to informix-list
TBP
Why is this an IDS issue, most O/Ses give the complete LV out to
aplication usage, the fact the AIX doesn't is an O/S imposed requirement.
I too have seen a fair amount of documentation regarding the 512 byte
requirement for the LVCB, but perhaps the people to ask would be AIX :)
malcolm weallans
Neil,
the reason why the offset matters to me is that I am
discovering sites with offsets of 0, 1, 2, and 4
pages. I need to know what the minimum offset should
be for satisfactory working. It is obviously a
problem if the offset is set to 0, but is an offset to
1 any guarantee that we won't experience a problem.
Also, any ideas on quick ways to change the offset of
a chunk? I have a particularly Grotty problem at one
of the larger mission critical 24x7 sites where the
only chunk with an offset of 0 is the first chunk of
rootdbs. And they definitely will encounter the
problem as they intend to roll out the existing
machine and roll in a faster machine but using the
same disks.
I have thought of doing an archive and then a restore
to a different structure using IDS 9.4 but that would
involve a large amount of downtime. That is unless
somebody can give me a way of restoring rootdbs
without restoring the data.
regards
Malcolm
--- Neil Truby <neil....@ardenta.com> wrote:
>
> "malcolm weallans" <malcol...@btopenworld.com>
> wrote in message
> news:cel0f5$32f$1...@news.xmission.com...
> >
> > Murray,
> > I hate to disagree but I have discovered
> information
> > in the IBM web-site that refers to the Logical
> volume
> > control block (Lvcb) being 512 bytes.
>
> Why does it matter? If 8k has been found to be
> adequate to circumvent the
> problem, but you *could* actually get away with
> less, surely th difference
> is so small as to be not worth fretting about?
>
>
>
sending to informix-list
Colin Bull
malcolm weallans wrote
> Also, any ideas on quick ways to change the offset of a
> chunk? I have a particularly Grotty problem at one of the
> larger mission critical 24x7 sites where the only chunk with
> an offset of 0 is the first chunk of rootdbs. And they
> definitely will encounter the problem as they intend to roll
> out the existing machine and roll in a faster machine but using the
> same disks.
>
> I have thought of doing an archive and then a restore to a
> different structure using IDS 9.4 but that would involve a
> large amount of downtime. That is unless somebody can give
> me a way of restoring rootdbs without restoring the data.
Informix mirroring is the way.
Some dick head at our company set up about 20 or 30 chunks with the
wrong offset.
The fault was not discovered until a problem occurred 3 months after
going live.
Mirroring allowed all the chunks to be corrected without taking Informix
down.
I am still here to tell the tale :-)
Colin Bull
________________________________________________________________________
This email has been scanned for all known viruses by the MessageLabs Email
Security System.
________________________________________________________________________
sending to informix-list