Use of offset for new chunks
Hi,
My environment:
Informix 11.70.FC8W1 with HP-UX 11i v3 64 bits.
I use HPUX Logical Volume Manager (LVM) with informix in a raw disk
configuration. The lvols are linked to chunks. For example, for the creation
of a new chunk:
lvextend -l 476 /dev/vg18/lvol99 /dev/disk/disk265
chmod 660 /dev/vg18/rlvol99
chown informix:informix /dev/vg18/rlvol99
ln /dev/vg18/rlvol99 /dev/informix/insttec/chunkL8 (link to rlvol)
onspaces -a dbs10 -p /dev/informix/insttec/chunkL8 -o 1024 -s 1948672
I create a new lvol for each new chunk.
My question is:
With this configuration is necessary the offset?. Why yes or why no?
In my case, I use offsets of 1024, but I think that it could be zero.
Please provide any clues or best practices.
Thanks in advance
Roger
The offset is ONLY necessary if the volume manager places partition
information at the beginning of the partition/lvol. The old Solaris fdisk
partition manager used to do that so it was necessary or the chunk would be
trashed the next time the server booted. This is a better question for an
HPUX forum though to get that answer.
Art
Art S. Kagel, President and Principal Consultant
ASK Database Management
www.askdbmgt.com
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on the IIUG, nor any other organization with which I am
associated either explicitly, implicitly, or by inference. Neither do
those opinions reflect those of other individuals affiliated with any
entity with which I am affiliated nor those of the entities themselves.
On Tue, May 24, 2016 at 6:33 PM, ROGER VILCA <rvilca@luzdelsur.com.pe>
wrote:
> Hi,
> My environment:
> Informix 11.70.FC8W1 with HP-UX 11i v3 64 bits.
>
> I use HPUX Logical Volume Manager (LVM) with informix in a raw disk
> configuration. The lvols are linked to chunks. For example, for the
> creation
> of a new chunk:
>
> lvextend -l 476 /dev/vg18/lvol99 /dev/disk/disk265
> chmod 660 /dev/vg18/rlvol99
> chown informix:informix /dev/vg18/rlvol99
> ln /dev/vg18/rlvol99 /dev/informix/insttec/chunkL8 (link to rlvol)
>
> onspaces -a dbs10 -p /dev/informix/insttec/chunkL8 -o 1024 -s 1948672>
> I create a new lvol for each new chunk.
>
> My question is:
> With this configuration is necessary the offset?. Why yes or why no?
> In my case, I use offsets of 1024, but I think that it could be zero.
> Please provide any clues or best practices.
>
> Thanks in advance
> Roger
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--089e0141a76451a6e405339e4ea9
Roger
Personally I would always recommend using an 8k offset. Its a minimal loss
of space and can save a db restore if the worst happens and you need to do
an O/S and lvm restore. I hit this a few years ago with AIX and the inbuilt
LVM where the O/S got corrupted and I had to restore O/S and LVM, which
overwrote the first k or so of the dbchunks and so required a dbrestore as
well.
Play safe and offset.
Keith
On 24 May 2016 at 23:44, Art Kagel <art.kagel@gmail.com> wrote:
> The offset is ONLY necessary if the volume manager places partition
> information at the beginning of the partition/lvol. The old Solaris fdisk
> partition manager used to do that so it was necessary or the chunk would be
> trashed the next time the server booted. This is a better question for an
> HPUX forum though to get that answer.
>
> Art
>
> Art S. Kagel, President and Principal Consultant
> ASK Database Management
> www.askdbmgt.com
>
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and do not reflect on the IIUG, nor any other organization with which I am
> associated either explicitly, implicitly, or by inference. Neither do
> those opinions reflect those of other individuals affiliated with any
> entity with which I am affiliated nor those of the entities themselves.
>
> On Tue, May 24, 2016 at 6:33 PM, ROGER VILCA <rvilca@luzdelsur.com.pe>
> wrote:
>
> > Hi,
> > My environment:
> > Informix 11.70.FC8W1 with HP-UX 11i v3 64 bits.
> >
> > I use HPUX Logical Volume Manager (LVM) with informix in a raw disk
> > configuration. The lvols are linked to chunks. For example, for the
> > creation
> > of a new chunk:
> >
> > lvextend -l 476 /dev/vg18/lvol99 /dev/disk/disk265
> > chmod 660 /dev/vg18/rlvol99
> > chown informix:informix /dev/vg18/rlvol99
> > ln /dev/vg18/rlvol99 /dev/informix/insttec/chunkL8 (link to rlvol)
> >
> > onspaces -a dbs10 -p /dev/informix/insttec/chunkL8 -o 1024 -s 1948672> >
> > I create a new lvol for each new chunk.
> >
> > My question is:
> > With this configuration is necessary the offset?. Why yes or why no?
> > In my case, I use offsets of 1024, but I think that it could be zero.
> > Please provide any clues or best practices.
> >
> > Thanks in advance
> > Roger
> >
> >
> >
> >
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --089e0141a76451a6e405339e4ea9
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001a114af9085494af0533a5f8d9
We have been running IDS on Linux and using Logical Volumes on raw disk
for many years with chunk offset of 0 ( Zero) with no issue at all.
Not safe ? Comments ?
Thanks
Frank
On Wed, May 25, 2016 at 3:53 AM, Keith Simmons <smiley73@gmail.com> wrote:
> Roger
>
> Personally I would always recommend using an 8k offset. Its a minimal loss
> of space and can save a db restore if the worst happens and you need to do
> an O/S and lvm restore. I hit this a few years ago with AIX and the inbuilt
> LVM where the O/S got corrupted and I had to restore O/S and LVM, which
> overwrote the first k or so of the dbchunks and so required a dbrestore as
> well.
> Play safe and offset.
>
> Keith
>
> On 24 May 2016 at 23:44, Art Kagel <art.kagel@gmail.com> wrote:
>
> > The offset is ONLY necessary if the volume manager places partition
> > information at the beginning of the partition/lvol. The old Solaris fdisk
> > partition manager used to do that so it was necessary or the chunk would
> be
> > trashed the next time the server booted. This is a better question for an
> > HPUX forum though to get that answer.
> >
> > Art
> >
> > Art S. Kagel, President and Principal Consultant
> > ASK Database Management
> > www.askdbmgt.com
> >
> > Blog: http://informix-myview.blogspot.com/
> >
> > Disclaimer: Please keep in mind that my own opinions are my own opinions
> > and do not reflect on the IIUG, nor any other organization with which I
> am
> > associated either explicitly, implicitly, or by inference. Neither do
> > those opinions reflect those of other individuals affiliated with any
> > entity with which I am affiliated nor those of the entities themselves.
> >
> > On Tue, May 24, 2016 at 6:33 PM, ROGER VILCA <rvilca@luzdelsur.com.pe>
> > wrote:
> >
> > > Hi,
> > > My environment:
> > > Informix 11.70.FC8W1 with HP-UX 11i v3 64 bits.
> > >
> > > I use HPUX Logical Volume Manager (LVM) with informix in a raw disk
> > > configuration. The lvols are linked to chunks. For example, for the
> > > creation
> > > of a new chunk:
> > >
> > > lvextend -l 476 /dev/vg18/lvol99 /dev/disk/disk265
> > > chmod 660 /dev/vg18/rlvol99
> > > chown informix:informix /dev/vg18/rlvol99
> > > ln /dev/vg18/rlvol99 /dev/informix/insttec/chunkL8 (link to rlvol)
> > >
> > > onspaces -a dbs10 -p /dev/informix/insttec/chunkL8 -o 1024 -s 1948672> > >
> > > I create a new lvol for each new chunk.
> > >
> > > My question is:
> > > With this configuration is necessary the offset?. Why yes or why no?
> > > In my case, I use offsets of 1024, but I think that it could be zero.
> > > Please provide any clues or best practices.
> > >
> > > Thanks in advance
> > > Roger
> > >
> > >
> > >
> > >
> >
> >
>
>
*******************************************************************************
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> >
> > --089e0141a76451a6e405339e4ea9
> >
> >
> >
> >
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --001a114af9085494af0533a5f8d9
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001a114222c84f2d4805342906b9