is there a way to find out the physical device fil
On SLES 11, a DBA lost the /dev symlinks (and device ownership/permissions) used as Informix chunk paths after a reboot, and couldn't tell which logical volume (vol01, vol02...) belonged to which chunk. Art Kagel explained Informix stores only the link names, but suggested reading each raw device's first page with dd | od -x, where the first six bytes encode the chunk number; matching that against oncfg_servername.0 let the links be rebuilt. Startup then aborted with errno 2 on chunk 1; Art attributed it to permissions (devices informix:informix 0660, links 777). The thread ends without confirmation that this fixed the startup, and no SUSE device-mapper guidance was given.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Help! 11.70.FC1 on Linux SUSE 11 SLES After setting up a 11.7 IDS instance and creating a bunch of Logical Volumes, creating Symbolic Links in /dev that pointed to the block device files that the LV Manager created, changing the ownership and permission on these device files appropriately, creating dbspaces from the chunks *using the Symbolic Link pathnames* to the chunk device files, I found out that when the Linux system was rebooted all of the Symbolic Links for my Informix Chunks were deleted from /dev (and also that the ownership and permissions for the chunk devices files had reverted to my pre-configured state). I need to re-create the symbolic links for the chunks, in some non-system directory I assume. The names of the symbolic links that I created indicated what dbspace the each chunk belonged to. I have those link names in my $INFORMIXDIR/etc/oncfg_servername.0 file as the pathname to each Chunks. UNFORTUNATELY, the names that I gave the Logical Volumes, and hence the names of the devices files created for the LVs/Chunks, did not indicate which Chunk/DBSpace each was created for (i.e.: I used a systematic pattern vol01, vol02, vol02,...) So, I need a way to find out the physical device file pathname that each of the symbolic links had pointed to, so that I can recreate the links correctly. OR since those links have been blown away by the OS and the instance is down, is there a file somewhere where I would find this info? Or is there an Informix Utility that can be run against a down instance that would list out the chunks that had been created for that instance along with the physical device file pathname for each? Any information or ideas would be appreciated. Thanks, Jim Cramer Univ of Iowa
Unfortunately, no. Informix only stored the links you provide, it does not
follow the links to their core names at all, it depends on the OS to
maintain and promote the links.
HOWEVER, there is one way. Use dd piped to od -x to read the first few
pages (so 2K each if you used the default pagesize or whatever the pagesize
of the dbspaces were) of each chunk's physical device. The first six bytes
of each page have the chunk number encoded. So on my server for chunk #1:
$ dd if=/opt/informix/infmx.11.70.FC1B7/dbspaces/rootdb.1.chunk bs=2k
count=2|od -x2+0 records in
2+0 records out
4096 bytes (4.1 kB) copied, 0.00441886 s, 927 kB/s
0000000 *0000 0000 0001* 9600 0003 1800 0130 06c0
0000020 0000 0000 0000 0000 4249 204d 6e49 6f66
For chunk #6:
$ dd if=/opt/informix/infmx.11.70.FC1B7/dbspaces/tempdbs1.1.chunk bs=2k
count=1|od -x1+0 records in
1+0 records out
2048 bytes (2.0 kB) copied, 7.7661e-05 s, 26.4 MB/s
0000000 *0000 0000 0006* 492e 0000 1800 0018 07e4
0000020 0000 0000 0000 0000 0000 0000 0000 0000
Armed with the chunk numbers you should be able to recreate the links.
Art S. Kagel
Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Thu, Jun 16, 2011 at 2:23 PM, jim-cramer@uiowa.edu
<jim-cramer@uiowa.edu>wrote:
> Help!
>
> 11.70.FC1 on Linux SUSE 11 SLES
>
> After setting up a 11.7 IDS instance and creating a bunch
> of Logical Volumes, creating Symbolic Links in /dev that
> pointed to the block device files that the LV Manager created,
> changing the ownership and permission on these device files
> appropriately, creating dbspaces from the chunks *using the
> Symbolic Link pathnames* to the chunk device files,
> I found out that when the Linux system was rebooted all
> of the Symbolic Links for my Informix Chunks were deleted
> from /dev (and also that the ownership and permissions for the
> chunk devices files had reverted to my pre-configured state).
>
> I need to re-create the symbolic links for the chunks, in
> some non-system directory I assume.
>
> The names of the symbolic links that I created indicated
> what dbspace the each chunk belonged to. I have those link names in
> my $INFORMIXDIR/etc/oncfg_servername.0 file as the pathname
> to each Chunks.
>
> UNFORTUNATELY, the names that I gave the Logical
> Volumes, and hence the names of the devices files created
> for the LVs/Chunks, did not indicate which Chunk/DBSpace
> each was created for (i.e.: I used a systematic pattern vol01,
> vol02, vol02,...)
>
> So, I need a way to find out the physical device file pathname
> that each of the symbolic links had pointed to, so that I
> can recreate the links correctly.
>
> OR
>
> since those links have been blown away by the OS and the instance
> is down, is there a file somewhere where I would find this info?
>
> Or
>
> is there an Informix Utility that can be run against a down instance
> that would list out the chunks that had been created for that instance
> along with the physical device file pathname for each?
>
> Any information or ideas would be appreciated.
>
> Thanks,
>
> Jim Cramer
> Univ of Iowa
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--bcaec5016349fe9e0304a5d882f3
Hi Art,
Well, no doubt about it, you are THE MAN! I *almost* have the server
back up (see below). Good news and bad news.
Thanks very much for the clever way of recreating lost symbolic links
used originally to create chunks and pointing these links at the actual
chunk device file paths/names. This method is based upon your expert
knowledge
of chunk storage internals.
I used your method to get the chunk number for each chunk/block device
file (using RAW chunks), looked for that number in the oncfg file's
"Chunks" section, got the name of the symbolic link used to create
the chunk from that line in the file, and created a script to recreate
the symbolic links/pathnames that had been used in the onspaces commands
that created the chunks.
The server begins to start with the "oninit" command, but it ABORTS.
According to the online.log file, it gets quite a ways through startup
but finds something wrong, Errno 2 (missing file or directory?)
with chunk 1, my rootdbs. I have included the tail end of the log file,
starting just before the warning about chunk 1, continuing to the end.
Any ideas? It seems like perhaps I made a mistake with the creation of
the symbolic link for rootdbs, but it looks OK I think. The "ls -l" of it
produces:
lrwxrwxrwx 1 root root 19 Jun 16 15:18 /dev/rootdbs ->
/dev/VolGrp01/vol01
and the rootdbs link points to another link, and ls -l on that link
produces:
lrwxrwxrwx 1 root root 26 Jun 15 15:49 /dev/VolGrp01/vol01 ->
/dev/mapper/VolGrp01-vol01
and ls -l on the target of that link, the block device file for the LV that
I used to create Chunk 1 with, produces:
brw-rw---- 1 informix informix 253, 5 Jun 15 10:49
/dev/mapper/VolGrp01-vol01
The "ls -lL /dev/rootdbs" command produces:
brw-rw---- 1 informix informix 253, 5 Jun 15 10:49 /dev/rootdbs
I am new to Linux (SUSE 11 SLES) and trying to migrate IDS from HPUX to it.
I
do not really understand the "device-mapper" Linux functionality that is
creating
symbolic links instead of Logical Volume device files in the traditional
directory
created for the Volume Group that the LVs belong to, and pointing those
links in
the VG dir to /dev/mapper, where the device files for the LV actually
reside.
So, due to my lack of knowledge of mapper, the following might be the
problem and
I would appreciate your opinion on it.
Originally I created the sym links in /dev to point straight at the device
file
in /dev/mapper. For example, the rootdbs was created with:
ln -s /dev/mapper/VolGrp01-vol01b /dev/rootdbs
However, due to some discussions with our Linux Sys Admins here, I have
recreated
the links in /dev to point to the sym links in the /dev/vgxx dir, which then
point
to the actual device files that I have set the ownershiip and permissions on
correctly.
The rootdbs was created with the path /dev/rootdbs, and the "ls -lL" on that
sym link/path
shows the target of this double-linking to be:
brw-rw---- 1 informix informix 253, 5 Jun 15 10:49 /dev/rootdbs
which looks OK permissions and ownership-wise, but perhaps the double
linking is the problem?
What do you think? Sorry this is so long. Thanks for bearing with me.
Jim
15:30:20 Event notification facility epoll enabled.
15:30:20 IBM Informix Dynamic Server Version 11.70.FC1GE Software Serial
Number AAA#B000000
15:30:20 Warning: stat() failed for chunk file /dev/rootdbs
15:30:22 IBM Informix Dynamic Server Initialized -- Shared Memory
Initialized.
15:30:22 Started 1 B-tree scanners.
15:30:22 B-tree scanner threshold set at 5000.
15:30:22 B-tree scanner range scan size set to -1.
15:30:22 B-tree scanner ALICE mode set to 6.
15:30:22 B-tree scanner index compression level set to med.
15:30:22 Physical Recovery Started at Page (2:131643).
15:30:23 Physical Recovery Complete: 8 Pages Examined, 8 Pages Restored.
15:30:23 Logical Recovery Started.
15:30:23 Dynamically allocated new virtual shared memory segment (size
8192KB)
15:30:23 Memory sizes:resident:192512 KB, virtual:253840 KB,
SHMTOTAL:16777216 KB
15:30:23 10 recovery worker threads will be started.
15:30:23 Assert Warning: I/O read chunk 1, pagenum 6641, pagecnt 1 -->
errno = 2
15:30:23 IBM Informix Dynamic Server Version 11.70.FC1GE
15:30:23 Who: Session(9, informix@s-l008, 0, 0x50291c20)
Thread(29, xchg_1.2, 502519a8, 3)
File: rsbuff.c Line: 6302
15:30:23 Action: Please notify IBM Informix Technical Support.
15:30:23 stack trace for pid 12822 written to /opt/db/ids/tmp/af.40567de
15:30:23 See Also: /opt/db/ids/tmp/af.40567de
15:30:23 I/O read chunk 1, pagenum 6641, pagecnt 1 --> errno = 2
15:30:23 Rollforward of log record failed. iserrno = 126
15:30:23 Log Record: log = 27, pos = 0x3ef8518, type = OLDRSAM:HINSERT(40),
trans = 26
15:30:23 Assert Failed: INFORMIX-OnLine Must ABORT
Critical media failure.
15:30:23 IBM Informix Dynamic Server Version 11.70.FC1GE
15:30:23 Who: Session(9, informix@s-l008, 0, 0x50291c20)
Thread(29, xchg_1.2, 502519a8, 3)
File: rsmirror.c Line: 1734
15:30:23 stack trace for pid 12822 written to /opt/db/ids/tmp/af.40567de
15:30:23 See Also: /opt/db/ids/tmp/af.40567de, shmem.40567de.0
15:30:28 Starting crash time check of:
15:30:28 1. memory block headers
15:30:28 2. stacks
15:30:28 Crash time checking found no problems
15:30:28 rsmirror.c, line 1734, thread 29, proc id 12822, INFORMIX-OnLine
Must ABORT
Critical media failure..
15:30:29 Fatal error in ADM VP at mt.c:14250
15:30:29 Unexpected virtual processor termination, pid = 12822, exit =
0x100
15:30:29 PANIC: Attempting to bring system down
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
Kagel
Sent: Thursday, June 16, 2011 1:34 PM
To: ids@iiug.org
Subject: Re: is there a way to find out the physical de.... [24060]
Unfortunately, no. Informix only stored the links you provide, it does not
follow the links to their core names at all, it depends on the OS to
maintain and promote the links.
HOWEVER, there is one way. Use dd piped to od -x to read the first few
pages (so 2K each if you used the default pagesize or whatever the pagesize
of the dbspaces were) of each chunk's physical device. The first six bytes
of each page have the chunk number encoded. So on my server for chunk #1:
$ dd if=/opt/informix/infmx.11.70.FC1B7/dbspaces/rootdb.1.chunk bs=2k
count=2|od -x2+0 records in
2+0 records out
4096 bytes (4.1 kB) copied, 0.00441886 s, 927 kB/s
0000000 *0000 0000 0001* 9600 0003 1800 0130 06c0
0000020 0000 0000 0000 0000 4249 204d 6e49 6f66
For chunk #6:
$ dd if=/opt/informix/infmx.11.70.FC1B7/dbspaces/tempdbs1.1.chunk bs=2k
count=1|od -x1+0 records in
1+0 records out
2048 bytes (2.0 kB) copied, 7.7661e-05 s, 26.4 MB/s
0000000 *0000 0000 0006* 492e 0000 1800 0018 07e4
0000020 0000 0000 0000 0000 0000 0000 0000 0000
Armed with the chunk numbers you should be able to recreate the links.
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://
Errno 2 is permissions (EPERM). Make sure that all of the low level chunk
devices are informix:informix with 0660 privileges and make sure that the
links themselves are 777 (owner of the links doesn't really matter, but I
usually make them informix:informix also).
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Thu, Jun 16, 2011 at 5:17 PM, jim-cramer@uiowa.edu
<jim-cramer@uiowa.edu>wrote:
> Hi Art,
>
> Well, no doubt about it, you are THE MAN! I *almost* have the server
> back up (see below). Good news and bad news.
>
> Thanks very much for the clever way of recreating lost symbolic links
> used originally to create chunks and pointing these links at the actual
> chunk device file paths/names. This method is based upon your expert
> knowledge
> of chunk storage internals.
>
> I used your method to get the chunk number for each chunk/block device
> file (using RAW chunks), looked for that number in the oncfg file's
> "Chunks" section, got the name of the symbolic link used to create
> the chunk from that line in the file, and created a script to recreate
> the symbolic links/pathnames that had been used in the onspaces commands
> that created the chunks.
>
> The server begins to start with the "oninit" command, but it ABORTS.
> According to the online.log file, it gets quite a ways through startup
> but finds something wrong, Errno 2 (missing file or directory?)
> with chunk 1, my rootdbs. I have included the tail end of the log file,
> starting just before the warning about chunk 1, continuing to the end.
>
> Any ideas? It seems like perhaps I made a mistake with the creation of
> the symbolic link for rootdbs, but it looks OK I think. The "ls -l" of it
> produces:
>
> lrwxrwxrwx 1 root root 19 Jun 16 15:18 /dev/rootdbs ->
> /dev/VolGrp01/vol01
>
> and the rootdbs link points to another link, and ls -l on that link
> produces:
>
> lrwxrwxrwx 1 root root 26 Jun 15 15:49 /dev/VolGrp01/vol01 ->
> /dev/mapper/VolGrp01-vol01
>
> and ls -l on the target of that link, the block device file for the LV that
> I used to create Chunk 1 with, produces:
>
> brw-rw---- 1 informix informix 253, 5 Jun 15 10:49
> /dev/mapper/VolGrp01-vol01
>
> The "ls -lL /dev/rootdbs" command produces:
>
> brw-rw---- 1 informix informix 253, 5 Jun 15 10:49 /dev/rootdbs
>
> I am new to Linux (SUSE 11 SLES) and trying to migrate IDS from HPUX to it.
> I
> do not really understand the "device-mapper" Linux functionality that is
> creating
> symbolic links instead of Logical Volume device files in the traditional
> directory
> created for the Volume Group that the LVs belong to, and pointing those
> links in
> the VG dir to /dev/mapper, where the device files for the LV actually
> reside.
>
> So, due to my lack of knowledge of mapper, the following might be the
> problem and
> I would appreciate your opinion on it.
>
> Originally I created the sym links in /dev to point straight at the device
> file
> in /dev/mapper. For example, the rootdbs was created with:
>
> ln -s /dev/mapper/VolGrp01-vol01b /dev/rootdbs
>
> However, due to some discussions with our Linux Sys Admins here, I have
> recreated
> the links in /dev to point to the sym links in the /dev/vgxx dir, which
> then
> point
> to the actual device files that I have set the ownershiip and permissions
> on
>
> correctly.
>
> The rootdbs was created with the path /dev/rootdbs, and the "ls -lL" on
> that
> sym link/path
> shows the target of this double-linking to be:
>
> brw-rw---- 1 informix informix 253, 5 Jun 15 10:49 /dev/rootdbs
>
> which looks OK permissions and ownership-wise, but perhaps the double
> linking is the problem?
>
> What do you think? Sorry this is so long. Thanks for bearing with me.
>
> Jim
>
> 15:30:20 Event notification facility epoll enabled.
> 15:30:20 IBM Informix Dynamic Server Version 11.70.FC1GE Software Serial
> Number AAA#B000000
> 15:30:20 Warning: stat() failed for chunk file /dev/rootdbs
> 15:30:22 IBM Informix Dynamic Server Initialized -- Shared Memory
> Initialized.
>
> 15:30:22 Started 1 B-tree scanners.
> 15:30:22 B-tree scanner threshold set at 5000.
> 15:30:22 B-tree scanner range scan size set to -1.
> 15:30:22 B-tree scanner ALICE mode set to 6.
> 15:30:22 B-tree scanner index compression level set to med.
> 15:30:22 Physical Recovery Started at Page (2:131643).
> 15:30:23 Physical Recovery Complete: 8 Pages Examined, 8 Pages Restored.
> 15:30:23 Logical Recovery Started.
> 15:30:23 Dynamically allocated new virtual shared memory segment (size
> 8192KB)
> 15:30:23 Memory sizes:resident:192512 KB, virtual:253840 KB,
> SHMTOTAL:16777216 KB
> 15:30:23 10 recovery worker threads will be started.
> 15:30:23 Assert Warning: I/O read chunk 1, pagenum 6641, pagecnt 1 -->
> errno = 2
> 15:30:23 IBM Informix Dynamic Server Version 11.70.FC1GE
> 15:30:23 Who: Session(9, informix@s-l008, 0, 0x50291c20)
>
> Thread(29, xchg_1.2, 502519a8, 3)
>
> File: rsbuff.c Line: 6302
> 15:30:23 Action: Please notify IBM Informix Technical Support.
> 15:30:23 stack trace for pid 12822 written to /opt/db/ids/tmp/af.40567de
> 15:30:23 See Also: /opt/db/ids/tmp/af.40567de
> 15:30:23 I/O read chunk 1, pagenum 6641, pagecnt 1 --> errno = 2
> 15:30:23 Rollforward of log record failed. iserrno = 126
> 15:30:23 Log Record: log = 27, pos = 0x3ef8518, type = OLDRSAM:HINSERT(40),
> trans = 26
> 15:30:23 Assert Failed: INFORMIX-OnLine Must ABORT
>
> Critical media failure.
> 15:30:23 IBM Informix Dynamic Server Version 11.70.FC1GE
> 15:30:23 Who: Session(9, informix@s-l008, 0, 0x50291c20)
>
> Thread(29, xchg_1.2, 502519a8, 3)
>
> File: rsmirror.c Line: 1734
> 15:30:23 stack trace for pid 12822 written to /opt/db/ids/tmp/af.40567de
> 15:30:23 See Also: /opt/db/ids/tmp/af.40567de, shmem.40567de.0
> 15:30:28 Starting crash time check of:
> 15:30:28 1. memory block headers
> 15:30:28 2. stacks
> 15:30:28 Crash time checking found no problems
> 15:30:28 rsmirror.c, line 1734, thread 29, proc id 12822, INFORMIX-OnLine
> Must ABORT
>
> Critical media failure..
> 15:30:29 Fatal error in ADM VP at mt.c:14250
> 15:30:29 Unexpected virtual processor termination, pid = 12822, exit =
> 0x100
>
> 15:30:29 PANIC: Attempting to bring system down
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
> Kagel
> Sent: Thursday, June 16, 2011 1:34 PM
> To: ids@iiug.org
> Subject: Re: is there a way to find out the physical de.... [24060]
>
> Unfortunately, no. Informix only stored the links you provide,
Thanks again Art.
I will check what you suggest.
Regarding using IDS on Linux SuSE 11
SLES, have you setup IDS on that OS?
If you have, was the" device-mapper"
functionality turned on and the LVM for
the system creating the device files
for the LVs in/ dev/mapper?
If you have encountered this scenario,
then did you point your symbolic
link for the chunks directly at the
device files in. /dev/mapper, or did
you point your links at the links in
/dev/VolGrpxx, which, in turn, point to
the device files in/ dev/mapper??
Jim
Connected by DROID on Verizon Wireless
Connected by DROID on Verizon Wireless
-----Original message-----
From: Art Kagel <art.kagel@gmail.com>
To: ids@iiug.org
Sent: Thu, Jun 16, 2011 23:03:59 GMT+00:00
Subject: Re: is there a way to find out the physical de.... [24068]
Errno 2 is permissions (EPERM). Make sure that all of the low level chunk
devices are informix:informix with 0660 privileges and make sure that the
links themselves are 777 (owner of the links doesn't really matter, but I
usually make them informix:informix also).
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Thu, Jun 16, 2011 at 5:17 PM, jim-cramer@uiowa.edu
wrote:
> Hi Art,
>
> Well, no doubt about it, you are THE MAN! I *almost* have the server
> back up (see below). Good news and bad news.
>
> Thanks very much for the clever way of recreating lost symbolic links
> used originally to create chunks and pointing these links at the actual
> chunk device file paths/names. This method is based upon your expert
> knowledge
> of chunk storage internals.
>
> I used your method to get the chunk number for each chunk/block device
> file (using RAW chunks), looked for that number in the oncfg file's
> "Chunks" section, got the name of the symbolic link used to create
> the chunk from that line in the file, and created a script to recreate
> the symbolic links/pathnames that had been used in the onspaces commands
> that created the chunks.
>
> The server begins to start with the "oninit" command, but it ABORTS.
> According to the online.log file, it gets quite a ways through startup
> but finds something wrong, Errno 2 (missing file or directory?)
> with chunk 1, my rootdbs. I have included the tail end of the log file,
> starting just before the warning about chunk 1, continuing to the end.
>
> Any ideas? It seems like perhaps I made a mistake with the creation of
> the symbolic link for rootdbs, but it looks OK I think. The "ls -l" of it
> produces:
>
> lrwxrwxrwx 1 root root 19 Jun 16 15:18 /dev/rootdbs ->
> /dev/VolGrp01/vol01
>
> and the rootdbs link points to another link, and ls -l on that link
> produces:
>
> lrwxrwxrwx 1 root root 26 Jun 15 15:49 /dev/VolGrp01/vol01 ->
> /dev/mapper/VolGrp01-vol01
>
> and ls -l on the target of that link, the block device file for the LV that
> I used to create Chunk 1 with, produces:
>
> brw-rw---- 1 informix informix 253, 5 Jun 15 10:49
> /dev/mapper/VolGrp01-vol01
>
> The "ls -lL /dev/rootdbs" command produces:
>
> brw-rw---- 1 informix informix 253, 5 Jun 15 10:49 /dev/rootdbs
>
> I am new to Linux (SUSE 11 SLES) and trying to migrate IDS from HPUX to it.
> I
> do not really understand the "device-mapper" Linux functionality that is
> creating
> symbolic links instead of Logical Volume device files in the traditional
> directory
> created for the Volume Group that the LVs belong to, and pointing those
> links in
> the VG dir to /dev/mapper, where the device files for the LV actually
> reside.
>
> So, due to my lack of knowledge of mapper, the following might be the
> problem and
> I would appreciate your opinion on it.
>
> Originally I created the sym links in /dev to point straight at the device
> file
> in /dev/mapper. For example, the rootdbs was created with:
>
> ln -s /dev/mapper/VolGrp01-vol01b /dev/rootdbs
>
> However, due to some discussions with our Linux Sys Admins here, I have
> recreated
> the links in /dev to point to the sym links in the /dev/vgxx dir, which
> then
> point
> to the actual device files that I have set the ownershiip and permissions
> on
>
> correctly.
>
> The rootdbs was created with the path /dev/rootdbs, and the "ls -lL" on
> that
> sym link/path
> shows the target of this double-linking to be:
>
> brw-rw---- 1 informix informix 253, 5 Jun 15 10:49 /dev/rootdbs
>
> which looks OK permissions and ownership-wise, but perhaps the double
> linking is the problem?
>
> What do you think? Sorry this is so long. Thanks for bearing with me.
>
> Jim
>
> 15:30:20 Event notification facility epoll enabled.
> 15:30:20 IBM Informix Dynamic Server Version 11.70.FC1GE Software Serial
> Number AAA#B000000
> 15:30:20 Warning: stat() failed for chunk file /dev/rootdbs
> 15:30:22 IBM Informix Dynamic Server Initialized -- Shared Memory
> Initialized.
>
> 15:30:22 Started 1 B-tree scanners.
> 15:30:22 B-tree scanner threshold set at 5000.
> 15:30:22 B-tree scanner range scan size set to -1.
> 15:30:22 B-tree scanner ALICE mode set to 6.
> 15:30:22 B-tree scanner index compression level set to med.
> 15:30:22 Physical Recovery Started at Page (2:131643).
> 15:30:23 Physical Recovery Complete: 8 Pages Examined, 8 Pages Restored.
> 15:30:23 Logical Recovery Started.
> 15:30:23 Dynamically allocated new virtual shared memory segment (size
> 8192KB)
> 15:30:23 Memory sizes:resident:192512 KB, virtual:253840 KB,
> SHMTOTAL:16777216 KB
> 15:30:23 10 recovery worker threads will be started.
> 15:30:23 Assert Warning: I/O read chunk 1, pagenum 6641, pagecnt 1 -->
> errno = 2
> 15:30:23 IBM Informix Dynamic Server Version 11.70.FC1GE
> 15:30:23 Who: Session(9, informix@s-l008, 0, 0x50291c20)
>
> Thread(29, xchg_1.2, 502519a8, 3)
>
> File: rsbuff.c Line: 6302
> 15:30:23 Action: Please notify IBM Informix Technical Support.
> 15:30:23 stack trace for pid 12822 written to /opt/db/ids/tmp/af.40567de
> 15:30:23 See Also: /opt/db/ids/tmp/af.40567de
> 15:30:23 I/O read chunk 1, pagenum 6641, pagecnt 1 --> errno = 2
> 15:30:23 Rollforward of log record failed. iserrno = 126
> 15:30:23 Log Record: log = 27, pos = 0x3ef8518, type = OLDRSAM:HINSERT(40),
> trans = 26
> 15:30:23 Assert Failed: INFORMIX-OnLine Must ABORT
>
> Critical media failure.
> 15:30:23 IBM Informix Dynamic Server Version 11.70.FC1GE
> 15:30:23 Who: Session(9, informix@s-l008, 0, 0x50291c20)
>
> Thread(29, xchg_1.2, 502519a8, 3)
>
> File: rsmirror.c Line: 1734
> 15:30:23 stack trace for pid 12822 written to /opt/db/i
I haven't used SUSE with Informix myself. I use Ubuntu here at home but
with simple files and DIRECT_IO just for simplicity of mgt. At ADTC out
main servers are on Sun/Solaris and the training servers are SUSE but again
just using simple files. When clients have systems for me to configure, I
try not to get involved in the "how" of implementing the storage whenever I
can. I haven't done serious SA work in 20 years or more so I try to stay
out.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Fri, Jun 17, 2011 at 9:41 AM, jim-cramer@uiowa.edu
<jim-cramer@uiowa.edu>wrote:
> Thanks again Art.
>
> I will check what you suggest.
>
> Regarding using IDS on Linux SuSE 11
> SLES, have you setup IDS on that OS?
>
> If you have, was the" device-mapper"
> functionality turned on and the LVM for
> the system creating the device files
> for the LVs in/ dev/mapper?
>
> If you have encountered this scenario,
> then did you point your symbolic
> link for the chunks directly at the
> device files in. /dev/mapper, or did
> you point your links at the links in
> /dev/VolGrpxx, which, in turn, point to
> the device files in/ dev/mapper??
>
> Jim
>
> Connected by DROID on Verizon Wireless
> Connected by DROID on Verizon Wireless
>
> -----Original message-----
>
> From: Art Kagel <art.kagel@gmail.com>
> To: ids@iiug.org
> Sent: Thu, Jun 16, 2011 23:03:59 GMT+00:00
> Subject: Re: is there a way to find out the physical de.... [24068]
>
> Errno 2 is permissions (EPERM). Make sure that all of the low level chunk
> devices are informix:informix with 0660 privileges and make sure that the
> links themselves are 777 (owner of the links doesn't really matter, but I
> usually make them informix:informix also).
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Thu, Jun 16, 2011 at 5:17 PM, jim-cramer@uiowa.edu
> wrote:
>
> > Hi Art,
> >
> > Well, no doubt about it, you are THE MAN! I *almost* have the server
> > back up (see below). Good news and bad news.
> >
> > Thanks very much for the clever way of recreating lost symbolic links
> > used originally to create chunks and pointing these links at the actual
> > chunk device file paths/names. This method is based upon your expert
> > knowledge
> > of chunk storage internals.
> >
> > I used your method to get the chunk number for each chunk/block device
> > file (using RAW chunks), looked for that number in the oncfg file's
> > "Chunks" section, got the name of the symbolic link used to create
> > the chunk from that line in the file, and created a script to recreate
> > the symbolic links/pathnames that had been used in the onspaces commands
> > that created the chunks.
> >
> > The server begins to start with the "oninit" command, but it ABORTS.
> > According to the online.log file, it gets quite a ways through startup
> > but finds something wrong, Errno 2 (missing file or directory?)
> > with chunk 1, my rootdbs. I have included the tail end of the log file,
> > starting just before the warning about chunk 1, continuing to the end.
> >
> > Any ideas? It seems like perhaps I made a mistake with the creation of
> > the symbolic link for rootdbs, but it looks OK I think. The "ls -l" of it
> > produces:
> >
> > lrwxrwxrwx 1 root root 19 Jun 16 15:18 /dev/rootdbs ->
> > /dev/VolGrp01/vol01
> >
> > and the rootdbs link points to another link, and ls -l on that link
> > produces:
> >
> > lrwxrwxrwx 1 root root 26 Jun 15 15:49 /dev/VolGrp01/vol01 ->
> > /dev/mapper/VolGrp01-vol01
> >
> > and ls -l on the target of that link, the block device file for the LV
> that
> > I used to create Chunk 1 with, produces:
> >
> > brw-rw---- 1 informix informix 253, 5 Jun 15 10:49
> > /dev/mapper/VolGrp01-vol01
> >
> > The "ls -lL /dev/rootdbs" command produces:
> >
> > brw-rw---- 1 informix informix 253, 5 Jun 15 10:49 /dev/rootdbs
> >
> > I am new to Linux (SUSE 11 SLES) and trying to migrate IDS from HPUX to
> it.
> > I
> > do not really understand the "device-mapper" Linux functionality that is
> > creating
> > symbolic links instead of Logical Volume device files in the traditional
> > directory
> > created for the Volume Group that the LVs belong to, and pointing those
> > links in
> > the VG dir to /dev/mapper, where the device files for the LV actually
> > reside.
> >
> > So, due to my lack of knowledge of mapper, the following might be the
> > problem and
> > I would appreciate your opinion on it.
> >
> > Originally I created the sym links in /dev to point straight at the
> device
> > file
> > in /dev/mapper. For example, the rootdbs was created with:
> >
> > ln -s /dev/mapper/VolGrp01-vol01b /dev/rootdbs
> >
> > However, due to some discussions with our Linux Sys Admins here, I have
> > recreated
> > the links in /dev to point to the sym links in the /dev/vgxx dir, which
> > then
> > point
> > to the actual device files that I have set the ownershiip and permissions
> > on
> >
> > correctly.
> >
> > The rootdbs was created with the path /dev/rootdbs, and the "ls -lL" on
> > that
> > sym link/path
> > shows the target of this double-linking to be:
> >
> > brw-rw---- 1 informix informix 253, 5 Jun 15 10:49 /dev/rootdbs
> >
> > which looks OK permissions and ownership-wise, but perhaps the double
> > linking is the problem?
> >
> > What do you think? Sorry this is so long. Thanks for bearing with me.
> >
> > Jim
> >
> > 15:30:20 Event notification facility epoll enabled.
> > 15:30:20 IBM Informix Dynamic Server Version 11.70.FC1GE Software Serial
> > Number AAA#B000000
> > 15:30:20 Warning: stat() failed for chunk file /dev/rootdbs
> > 15:30:22 IBM Informix Dynamic Server Initialized -- Shared Memory
> > Initialized.
> >
> > 15:30:22 Started 1 B-tree scanners.
> > 15:30:22 B-tree scanner threshold set at 5000.
> > 15:30:22 B-tree scanner range scan size set to -1.
> > 15:30:22 B-tree scanner ALICE mode set to 6.
> > 15:30:22 B-tree scanner index compression level set to med.
> > 15:30:22 Physical Recovery Started at Page (2:13164
Hi Art,
Thanks for answering this and I understand.
I will figure out the details of this SuSE device file symbolic link
shuffling. Or, if anyone who happens to read this knows what to
point the Symbolic Links the DBA creates for the Informix Chunks at,
please post it or email me.
Again, I owe you major thanks Art for the information and clever way
of finding out which Informix Chunk# every device file had been assigned,
in the case that the Symbolic Links used to create the Chunks in Informix
get blown away and have to be recreated.
I could not have gotten anywhere without that info.
Much appreciated,
Jim Cramer
Univ of Iowa
jim-cramer@uiowa.edu
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Art Kagel
> Sent: Friday, June 17, 2011 9:09 AM
> To: ids@iiug.org
> Subject: Re: is there a way to find out the physical de.... [24076]
>
> I haven't used SUSE with Informix myself. I use Ubuntu here at home but
> with simple files and DIRECT_IO just for simplicity of mgt. At ADTC out
> main servers are on Sun/Solaris and the training servers are SUSE but
> again
> just using simple files. When clients have systems for me to configure,
> I
> try not to get involved in the "how" of implementing the storage
> whenever I
> can. I haven't done serious SA work in 20 years or more so I try to
> stay
> out.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Fri, Jun 17, 2011 at 9:41 AM, jim-cramer@uiowa.edu
> <jim-cramer@uiowa.edu>wrote:
>
> > Thanks again Art.
> >
> > I will check what you suggest.
> >
> > Regarding using IDS on Linux SuSE 11
> > SLES, have you setup IDS on that OS?
> >
> > If you have, was the" device-mapper"
> > functionality turned on and the LVM for
> > the system creating the device files
> > for the LVs in/ dev/mapper?
> >
> > If you have encountered this scenario,
> > then did you point your symbolic
> > link for the chunks directly at the
> > device files in. /dev/mapper, or did
> > you point your links at the links in
> > /dev/VolGrpxx, which, in turn, point to
> > the device files in/ dev/mapper??
> >
> > Jim
> >
> > Connected by DROID on Verizon Wireless
> > Connected by DROID on Verizon Wireless
> >
> > -----Original message-----
> >
> > From: Art Kagel <art.kagel@gmail.com>
> > To: ids@iiug.org
> > Sent: Thu, Jun 16, 2011 23:03:59 GMT+00:00
> > Subject: Re: is there a way to find out the physical de.... [24068]
> >
> > Errno 2 is permissions (EPERM). Make sure that all of the low level
> chunk
> > devices are informix:informix with 0660 privileges and make sure that
> the
> > links themselves are 777 (owner of the links doesn't really matter,
> but I
> > usually make them informix:informix also).
> >
> > Art
> >
> > Art S. Kagel
> > Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Thu, Jun 16, 2011 at 5:17 PM, jim-cramer@uiowa.edu
> > wrote:
> >
> > > Hi Art,
> > >
> > > Well, no doubt about it, you are THE MAN! I *almost* have the
> server
> > > back up (see below). Good news and bad news.
> > >
> > > Thanks very much for the clever way of recreating lost symbolic
> links
> > > used originally to create chunks and pointing these links at the
> actual
> > > chunk device file paths/names. This method is based upon your
> expert
> > > knowledge
> > > of chunk storage internals.
> > >
> > > I used your method to get the chunk number for each chunk/block
> device
> > > file (using RAW chunks), looked for that number in the oncfg file's
> > > "Chunks" section, got the name of the symbolic link used to create
> > > the chunk from that line in the file, and created a script to
> recreate
> > > the symbolic links/pathnames that had been used in the onspaces
> commands
> > > that created the chunks.
> > >
> > > The server begins to start with the "oninit" command, but it
> ABORTS.
> > > According to the online.log file, it gets quite a ways through
> startup
> > > but finds something wrong, Errno 2 (missing file or directory?)
> > > with chunk 1, my rootdbs. I have included the tail end of the log
> file,
> > > starting just before the warning about chunk 1, continuing to the
> end.
> > >
> > > Any ideas? It seems like perhaps I made a mistake with the creation
> of
> > > the symbolic link for rootdbs, but it looks OK I think. The "ls -l"
> of it
> > > produces:
> > >
> > > lrwxrwxrwx 1 root root 19 Jun 16 15:18 /dev/rootdbs ->
> > > /dev/VolGrp01/vol01
> > >
> > > and the rootdbs link points to another link, and ls -l on that link
> > > produces:
> > >
> > > lrwxrwxrwx 1 root root 26 Jun 15 15:49 /dev/VolGrp01/vol01 ->
> > > /dev/mapper/VolGrp01-vol01
> > >
> > > and ls -l on the target of that link, the block device file for the
> LV
> > that
> > > I used to create Chunk 1 with, produces:
> > >
> > > brw-rw---- 1 informix informix 253, 5 Jun 15 10:49
> > > /dev/mapper/VolGrp01-vol01
> > >
> > > The "ls -lL /dev/rootdbs" command produces:
> > >
> > > brw-rw---- 1 informix informix 253, 5 Jun 15 10:49 /dev/rootdbs
> > >
> > > I am new to Linux (SUSE 11 SLES) and trying to migrate IDS from
> HPUX to
> > it.
> > > I
> > > do not really understand the "device-mapper" Linux functionality
> that is
> > > creating
> > > symbolic links instead of Logical Volume device files in the
> traditional
> > > directory
> > > created for the Volume Group that the LVs belong to, and pointing
> those
> > > links in
> > > the VG dir to /dev/mapper, where the device files for the LV
> actually
> > > reside.
> > >
> > > So, due to my lack of knowledge of mapper, the following might be
> the
> > > problem and
> > > I would appreciate your opinion on it.
> > >
> > > Originally I created the sym links in /dev to point straight at the
> > device
> > > file
> > > in /dev/mapper. For example, the rootdbs was created with:
> > >
> > > ln -s /d
We use the same concept with creating sym links to the actual LVM devices.
The difference is that we create our own block devices that use the same
major,minor numbers as the LVM device and then point the sym links to the
ones we created.
For example:
LVM device:
brw-rw---- 1 root disk 253, 8 May 13 11:37 dm-8 (notice the major,minor is
253,8)
We have a directory called /ifxslices/blockdevices that has our created
devices. Use the mknod command to create the device.
brw-rw----. 1 informix informix 253, 8 Jun 17 07:33
/ifxslices/blockdevices/rootdbs (notice that the major,minor numbers are
the same as the LVM device, and the permissions/ownership are set the way
informix needs them to be).
Lastly, we create sym links to point to our block devices and use them in
the creation of the dbspaces.
lrwxrwxrwx. 1 informix informix 20 May 2 15:12 /ifxslices/rootdbs ->
blockdevices/rootdbs
This way there's in a script or anything that needs to be run on every
machine boot to make sure that the devices are setup the way you need them
to be. Just make sure to protect the directory that you put everything in
so that there's no chance to somebody removing them accidently.
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
jim-cramer@uiowa.edu
Sent: Friday, June 17, 2011 9:57 AM
To: ids@iiug.org
Subject: RE: is there a way to find out the physical de.... [24077]
Hi Art,
Thanks for answering this and I understand.
I will figure out the details of this SuSE device file symbolic link
shuffling. Or, if anyone who happens to read this knows what to point the
Symbolic Links the DBA creates for the Informix Chunks at, please post it or
email me.
Again, I owe you major thanks Art for the information and clever way of
finding out which Informix Chunk# every device file had been assigned, in
the case that the Symbolic Links used to create the Chunks in Informix get
blown away and have to be recreated.
I could not have gotten anywhere without that info.
Much appreciated,
Jim Cramer
Univ of Iowa
jim-cramer@uiowa.edu
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Art Kagel
> Sent: Friday, June 17, 2011 9:09 AM
> To: ids@iiug.org
> Subject: Re: is there a way to find out the physical de.... [24076]
>
> I haven't used SUSE with Informix myself. I use Ubuntu here at home
> but with simple files and DIRECT_IO just for simplicity of mgt. At
> ADTC out main servers are on Sun/Solaris and the training servers are
> SUSE but again just using simple files. When clients have systems for
> me to configure, I try not to get involved in the "how" of
> implementing the storage whenever I can. I haven't done serious SA
> work in 20 years or more so I try to stay out.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Fri, Jun 17, 2011 at 9:41 AM, jim-cramer@uiowa.edu
> <jim-cramer@uiowa.edu>wrote:
>
> > Thanks again Art.
> >
> > I will check what you suggest.
> >
> > Regarding using IDS on Linux SuSE 11 SLES, have you setup IDS on
> > that OS?
> >
> > If you have, was the" device-mapper"
> > functionality turned on and the LVM for the system creating the
> > device files for the LVs in/ dev/mapper?
> >
> > If you have encountered this scenario, then did you point your
> > symbolic link for the chunks directly at the device files in.
> > /dev/mapper, or did you point your links at the links in
> > /dev/VolGrpxx, which, in turn, point to the device files in/
> > dev/mapper??
> >
> > Jim
> >
> > Connected by DROID on Verizon Wireless Connected by DROID on Verizon
> > Wireless
> >
> > -----Original message-----
> >
> > From: Art Kagel <art.kagel@gmail.com>
> > To: ids@iiug.org
> > Sent: Thu, Jun 16, 2011 23:03:59 GMT+00:00
> > Subject: Re: is there a way to find out the physical de.... [24068]
> >
> > Errno 2 is permissions (EPERM). Make sure that all of the low level
> chunk
> > devices are informix:informix with 0660 privileges and make sure
> > that
> the
> > links themselves are 777 (owner of the links doesn't really matter,
> but I
> > usually make them informix:informix also).
> >
> > Art
> >
> > Art S. Kagel
> > Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Thu, Jun 16, 2011 at 5:17 PM, jim-cramer@uiowa.edu
> > wrote:
> >
> > > Hi Art,
> > >
> > > Well, no doubt about it, you are THE MAN! I *almost* have the
> server
> > > back up (see below). Good news and bad news.
> > >
> > > Thanks very much for the clever way of recreating lost symbolic
> links
> > > used originally to create chunks and pointing these links at the
> actual
> > > chunk device file paths/names. This method is based upon your
> expert
> > > knowledge
> > > of chunk storage internals.
> > >
> > > I used your method to get the chunk number for each chunk/block
> device
> > > file (using RAW chunks), looked for that number in the oncfg
> > > file's "Chunks" section, got the name of the symbolic link used to
> > > create the chunk from that line in the file, and created a script
> > > to
> recreate
> > > the symbolic links/pathnames that had been used in the onspaces
> commands
> > > that created the chunks.
> > >
> > > The server begins to start with the "oninit" command, but it
> ABORTS.
> > > According to the online.log file, it gets quite a ways through
> startup
> > > but finds something wrong, Errno 2 (missing file or directory?)
> > > with chunk 1, my rootdbs. I have included the tail end of the log
> file,
> > > starting just before the warning about chunk 1, continuing to the
> end.
> > >
> > > Any ideas? It seems like perhaps I made a mistake with the
> > > creation
> of
> > > the symbolic link for rootdbs, but it looks OK I think. The "ls -l"
> of it
> > > produces:
> > >
> > > lrwxrwxrwx 1 root root 19 Jun 16 15:18 /dev/rootdbs ->
> > > /dev/VolGrp01/vol01
> > >
> > > and the rootdbs link points to another link, and ls
Hi Art,
Thanks for your reply from 6/16 with some suggested things to check.
The permissions and ownership of the chunk device files, in /dev/mapper
directory, had been correct.
Your suggestion about changing the ownership of the links might
have helped. Before I changed the ownership, I had errno 2 on rootdbs
and this logged into online.log:
15:30:23 Assert Warning: I/O read chunk 1, pagenum 6641, pagecnt 1 -->
errno = 2
15:30:23 IBM Informix Dynamic Server Version 11.70.FC1GE
15:30:23 Who: Session(9, informix@s-l008, 0, 0x50291c20)
Thread(29, xchg_1.2, 502519a8, 3)
File: rsbuff.c Line: 6302
15:30:23 Action: Please notify IBM Informix Technical Support.
15:30:23 stack trace for pid 12822 written to /opt/db/ids/tmp/af.40567de
15:30:23 See Also: /opt/db/ids/tmp/af.40567de
15:30:23 I/O read chunk 1, pagenum 6641, pagecnt 1 --> errno = 2
15:30:23 Rollforward of log record failed. iserrno = 126
15:30:23 Log Record: log = 27, pos = 0x3ef8518, type = OLDRSAM:HINSERT(40),
trans = 26
15:30:23 Assert Failed: INFORMIX-OnLine Must ABORT
Critical media failure.
(By the way, I also noticed just now that one of my attempts to restart the
instance failed on Chunk 6, which is the first chunk of my Logical Logs,
instead of on Chunk 1.)
NOW:
The ownership of my symbolic link in /dev was 777 BEFORE (when the crash
shown above
happened) but the ownership was root. So, I changed the ownership of the
link to
informix:informix and quite a bit of the above error message went away.
However, I still had an assertion failure, but of a different nature.
Instead of
an errno 2 error on my 1st chunk, some sort of sanity check fails at a
different
routine in the Thread on I now get this in online.log:
10:52:59 IBM Informix Dynamic Server Version 11.70.FC1GE Software Serial
Number AAA#B000000
10:52:59 Warning: stat() failed for chunk file /dev/rootdbs
10:53:00 Assert Warning: chunk failed sanity check
10:53:00 IBM Informix Dynamic Server Version 11.70.FC1GE
10:53:00 Who: Session(1, informix@s-l008, 0, 0x5028e028)
Thread(8, main_loop(), 50249028, 3)
File: rspartn.c Line: 10531
10:53:00 Results: Chunk 1 is being taken OFFLINE.
10:53:00 Action: For all spaces other than temporary dbspaces, restore the
space
containing the chunk from the archive. If this chunk belongs to a
temporary dbspace and if it is not the only chunk in that
dbspace,
then drop and re-create the chunk. Otherwise drop and re-create
the temporary dbspace.
10:53:00 stack trace for pid 8923 written to /opt/db/ids/tmp/af.3f06cdc
10:53:00 See Also: /opt/db/ids/tmp/af.3f06cdc
10:53:00 chunk failed sanity check
10:53:01 I/O error, Primary Chunk '/dev/rootdbs' -- Offline (sanity)
10:53:01 oninit: Fatal error in shared memory initialization
10:53:01 IBM Informix Dynamic Server Stopped.
10:53:01 mt_shm_remove: WARNING: may not have removed all/correct segments
So, I am going to go ahead and change the ownership of all of the symbolic
links that I created for chunks to informix:informix and see what happens.
I will let you know.
Thanks,
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
Kagel
Sent: Thursday, June 16, 2011 5:59 PM
To: ids@iiug.org
Subject: Re: is there a way to find out the physical de.... [24068]
Errno 2 is permissions (EPERM). Make sure that all of the low level chunk
devices are informix:informix with 0660 privileges and make sure that the
links themselves are 777 (owner of the links doesn't really matter, but I
usually make them informix:informix also).
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Thu, Jun 16, 2011 at 5:17 PM, jim-cramer@uiowa.edu
<jim-cramer@uiowa.edu>wrote:
> Hi Art,
>
> Well, no doubt about it, you are THE MAN! I *almost* have the server
> back up (see below). Good news and bad news.
>
> Thanks very much for the clever way of recreating lost symbolic links
> used originally to create chunks and pointing these links at the actual
> chunk device file paths/names. This method is based upon your expert
> knowledge
> of chunk storage internals.
>
> I used your method to get the chunk number for each chunk/block device
> file (using RAW chunks), looked for that number in the oncfg file's
> "Chunks" section, got the name of the symbolic link used to create
> the chunk from that line in the file, and created a script to recreate
> the symbolic links/pathnames that had been used in the onspaces commands
> that created the chunks.
>
> The server begins to start with the "oninit" command, but it ABORTS.
> According to the online.log file, it gets quite a ways through startup
> but finds something wrong, Errno 2 (missing file or directory?)
> with chunk 1, my rootdbs. I have included the tail end of the log file,
> starting just before the warning about chunk 1, continuing to the end.
>
> Any ideas? It seems like perhaps I made a mistake with the creation of
> the symbolic link for rootdbs, but it looks OK I think. The "ls -l" of it
> produces:
>
> lrwxrwxrwx 1 root root 19 Jun 16 15:18 /dev/rootdbs ->
> /dev/VolGrp01/vol01
>
> and the rootdbs link points to another link, and ls -l on that link
> produces:
>
> lrwxrwxrwx 1 root root 26 Jun 15 15:49 /dev/VolGrp01/vol01 ->
> /dev/mapper/VolGrp01-vol01
>
> and ls -l on the target of that link, the block device file for the LV
that
> I used to create Chunk 1 with, produces:
>
> brw-rw---- 1 informix informix 253, 5 Jun 15 10:49
> /dev/mapper/VolGrp01-vol01
>
> The "ls -lL /dev/rootdbs" command produces:
>
> brw-rw---- 1 informix informix 253, 5 Jun 15 10:49 /dev/rootdbs
>
> I am new to Linux (SUSE 11 SLES) and trying to migrate IDS from HPUX to
it.
> I
> do not really understand the "device-mapper" Linux functionality that is
> creating
> symbolic links instead of Logical Volume device files in the traditional
> directory
> created for the Volume Group that the LVs belong to, and pointing those
> links in
> the VG dir to /dev/mapper, where the device files for the LV actually
> reside.
>
> So, due to my lack of knowledge of mapper, the following might be the
> problem and
> I would appreciate your opinion on it.
>
> Originally I created the sym links in /dev to point straight at the device
> file
> in /dev/mapper. For example, the rootdbs was created with:
>
> ln -s /dev/mapper/VolGrp01-vol01b /dev/rootdbs
>
> However, due to some discussions with our Linux Sys Admins here, I have
> recreated
> the links in /dev to po
Jamie, Thanks for the idea. I need a bit more info if you have time.. 1. What is the OS and Version that you are running IDS on? 2. And if Linux, is it the Open Edition or the Enterprise Edition? 3. If it is on Linux, is the OS using the "device mapper". You can tell by looking in /dev for a directory called mapper. If it is there, you should find the actual block device files that the system's Logical Volume Manager created if you used it to partition a disk. If you did, then the device files are in /etc/mapper instead of in /dev/VolGrpxx (where xx is the Volume Group Number that the Logical Volumes were created from), and in this directory are symbolic links, instead of the actual LV device files, which point to the actual device files in /dev/mapper. Again, does your system use this mapper functionality? It is important for me to know in order to know whether I will be able to get away with using the method that you use and have explained below. Please let me know the answers to these questions if you have the time. Thanks again, Jim -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Jamie Gedye Sent: Friday, June 17, 2011 12:16 PM To: ids@iiug.org Subject: RE: is there a way to find out the physical de.... [24078] We use the same concept with creating sym links to the actual LVM devices. The difference is that we create our own block devices that use the same major,minor numbers as the LVM device and then point the sym links to the ones we created. For example: LVM device: brw-rw---- 1 root disk 253, 8 May 13 11:37 dm-8 (notice the major,minor is 253,8) We have a directory called /ifxslices/blockdevices that has our created devices. Use the mknod command to create the device. brw-rw----. 1 informix informix 253, 8 Jun 17 07:33 /ifxslices/blockdevices/rootdbs (notice that the major,minor numbers are the same as the LVM device, and the permissions/ownership are set the way informix needs them to be). Lastly, we create sym links to point to our block devices and use them in the creation of the dbspaces. lrwxrwxrwx. 1 informix informix 20 May 2 15:12 /ifxslices/rootdbs -> blockdevices/rootdbs This way there's in a script or anything that needs to be run on every machine boot to make sure that the devices are setup the way you need them to be. Just make sure to protect the directory that you put everything in so that there's no chance to somebody removing them accidently. -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of jim-cramer@uiowa.edu Sent: Friday, June 17, 2011 9:57 AM To: ids@iiug.org Subject: RE: is there a way to find out the physical de.... [24077] Hi Art, Thanks for answering this and I understand. I will figure out the details of this SuSE device file symbolic link shuffling. Or, if anyone who happens to read this knows what to point the Symbolic Links the DBA creates for the Informix Chunks at, please post it or email me. Again, I owe you major thanks Art for the information and clever way of finding out which Informix Chunk# every device file had been assigned, in the case that the Symbolic Links used to create the Chunks in Informix get blown away and have to be recreated. I could not have gotten anywhere without that info. Much appreciated, Jim Cramer Univ of Iowa jim-cramer@uiowa.edu > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > Art Kagel > Sent: Friday, June 17, 2011 9:09 AM > To: ids@iiug.org > Subject: Re: is there a way to find out the physical de.... [24076] > > I haven't used SUSE with Informix myself. I use Ubuntu here at home > but with simple files and DIRECT_IO just for simplicity of mgt. At > ADTC out main servers are on Sun/Solaris and the training servers are > SUSE but again just using simple files. When clients have systems for > me to configure, I try not to get involved in the "how" of > implementing the storage whenever I can. I haven't done serious SA > work in 20 years or more so I try to stay out. > > Art > > Art S. Kagel > Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Fri, Jun 17, 2011 at 9:41 AM, jim-cramer@uiowa.edu > <jim-cramer@uiowa.edu>wrote: > > > Thanks again Art. > > > > I will check what you suggest. > > > > Regarding using IDS on Linux SuSE 11 SLES, have you setup IDS on > > that OS? > > > > If you have, was the" device-mapper" > > functionality turned on and the LVM for the system creating the > > device files for the LVs in/ dev/mapper? > > > > If you have encountered this scenario, then did you point your > > symbolic link for the chunks directly at the device files in. > > /dev/mapper, or did you point your links at the links in > > /dev/VolGrpxx, which, in turn, point to the device files in/ > > dev/mapper?? > > > > Jim > > > > Connected by DROID on Verizon Wireless Connected by DROID on Verizon > > Wireless > > > > -----Original message----- > > > > From: Art Kagel <art.kagel@gmail.com> > > To: ids@iiug.org > > Sent: Thu, Jun 16, 2011 23:03:59 GMT+00:00 > > Subject: Re: is there a way to find out the physical de.... [24068] > > > > Errno 2 is permissions (EPERM). Make sure that all of the low level > chunk > > devices are informix:informix with 0660 privileges and make sure > > that > the > > links themselves are 777 (owner of the links doesn't really matter, > but I > > usually make them informix:informix also). > > > > Art > > > > Art S. Kagel > > Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Thu, Jun 16, 2011 at 5:17 PM, jim-cramer@uiowa.edu > > wrote: > > > > > Hi Art, > > > > > > Well, no doubt about it, you are THE MAN! I *almost* have the > server > > > back up (see below). Good news and bad news. > > > > > > Thanks very much for the clever way of recreating lost symbolic > links > > > used originally to create chunks and pointing these links at the > actual@@
Sanity check failures mean that the pages in the chunks do not "look
right". The 20 byte at the beginning of each page doesn't look like it
contains the correct header information or the checksum at the bottom of the
page does not match the calculated checksum for the page. Also the first
page of the first chunk must contain copyright, platform, and version
details.
Just for information sake. Good luck.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Mon, Jun 20, 2011 at 1:31 PM, jim-cramer@uiowa.edu
<jim-cramer@uiowa.edu>wrote:
> Hi Art,
>
> Thanks for your reply from 6/16 with some suggested things to check.
>
> The permissions and ownership of the chunk device files, in /dev/mapper
> directory, had been correct.
>
> Your suggestion about changing the ownership of the links might
> have helped. Before I changed the ownership, I had errno 2 on rootdbs
> and this logged into online.log:
>
> 15:30:23 Assert Warning: I/O read chunk 1, pagenum 6641, pagecnt 1 -->
> errno = 2
> 15:30:23 IBM Informix Dynamic Server Version 11.70.FC1GE
> 15:30:23 Who: Session(9, informix@s-l008, 0, 0x50291c20)
>
> Thread(29, xchg_1.2, 502519a8, 3)
>
> File: rsbuff.c Line: 6302
> 15:30:23 Action: Please notify IBM Informix Technical Support.
> 15:30:23 stack trace for pid 12822 written to /opt/db/ids/tmp/af.40567de
> 15:30:23 See Also: /opt/db/ids/tmp/af.40567de
> 15:30:23 I/O read chunk 1, pagenum 6641, pagecnt 1 --> errno = 2
> 15:30:23 Rollforward of log record failed. iserrno = 126
> 15:30:23 Log Record: log = 27, pos = 0x3ef8518, type = OLDRSAM:HINSERT(40),
> trans = 26
> 15:30:23 Assert Failed: INFORMIX-OnLine Must ABORT
>
> Critical media failure.
>
> (By the way, I also noticed just now that one of my attempts to restart the
> instance failed on Chunk 6, which is the first chunk of my Logical Logs,
> instead of on Chunk 1.)
>
> NOW:
>
> The ownership of my symbolic link in /dev was 777 BEFORE (when the crash
> shown above
> happened) but the ownership was root. So, I changed the ownership of the
> link to
> informix:informix and quite a bit of the above error message went away.
>
> However, I still had an assertion failure, but of a different nature.
> Instead of
> an errno 2 error on my 1st chunk, some sort of sanity check fails at a
> different
> routine in the Thread on I now get this in online.log:
>
> 10:52:59 IBM Informix Dynamic Server Version 11.70.FC1GE Software Serial
> Number AAA#B000000
> 10:52:59 Warning: stat() failed for chunk file /dev/rootdbs
> 10:53:00 Assert Warning: chunk failed sanity check
>
> 10:53:00 IBM Informix Dynamic Server Version 11.70.FC1GE
> 10:53:00 Who: Session(1, informix@s-l008, 0, 0x5028e028)
>
> Thread(8, main_loop(), 50249028, 3)
>
> File: rspartn.c Line: 10531
> 10:53:00 Results: Chunk 1 is being taken OFFLINE.
> 10:53:00 Action: For all spaces other than temporary dbspaces, restore the
> space
>
> containing the chunk from the archive. If this chunk belongs to a
>
> temporary dbspace and if it is not the only chunk in that
> dbspace,
>
> then drop and re-create the chunk. Otherwise drop and re-create
>
> the temporary dbspace.
> 10:53:00 stack trace for pid 8923 written to /opt/db/ids/tmp/af.3f06cdc
> 10:53:00 See Also: /opt/db/ids/tmp/af.3f06cdc
> 10:53:00 chunk failed sanity check
>
> 10:53:01 I/O error, Primary Chunk '/dev/rootdbs' -- Offline (sanity)
> 10:53:01 oninit: Fatal error in shared memory initialization
>
> 10:53:01 IBM Informix Dynamic Server Stopped.
>
> 10:53:01 mt_shm_remove: WARNING: may not have removed all/correct segments
>
> So, I am going to go ahead and change the ownership of all of the symbolic
> links that I created for chunks to informix:informix and see what happens.
>
> I will let you know.
>
> Thanks,
>
> Jim
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
> Kagel
> Sent: Thursday, June 16, 2011 5:59 PM
> To: ids@iiug.org
> Subject: Re: is there a way to find out the physical de.... [24068]
>
> Errno 2 is permissions (EPERM). Make sure that all of the low level chunk
> devices are informix:informix with 0660 privileges and make sure that the
> links themselves are 777 (owner of the links doesn't really matter, but I
> usually make them informix:informix also).
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Thu, Jun 16, 2011 at 5:17 PM, jim-cramer@uiowa.edu
> <jim-cramer@uiowa.edu>wrote:
>
> > Hi Art,
> >
> > Well, no doubt about it, you are THE MAN! I *almost* have the server
> > back up (see below). Good news and bad news.
> >
> > Thanks very much for the clever way of recreating lost symbolic links
> > used originally to create chunks and pointing these links at the actual
> > chunk device file paths/names. This method is based upon your expert
> > knowledge
> > of chunk storage internals.
> >
> > I used your method to get the chunk number for each chunk/block device
> > file (using RAW chunks), looked for that number in the oncfg file's
> > "Chunks" section, got the name of the symbolic link used to create
> > the chunk from that line in the file, and created a script to recreate
> > the symbolic links/pathnames that had been used in the onspaces commands
> > that created the chunks.
> >
> > The server begins to start with the "oninit" command, but it ABORTS.
> > According to the online.log file, it gets quite a ways through startup
> > but finds something wrong, Errno 2 (missing file or directory?)
> > with chunk 1, my rootdbs. I have included the tail end of the log file,
> > starting just before the warning about chunk 1, continuing to the end.
> >
> > Any ideas? It seems like perhaps I made a mistake with the creation of
> > the symbolic link for rootdbs, but it looks OK I think. The "ls -l" of it
> > produces:
> >
> > lrwxrwxrwx 1 root root 19 Jun 16 15:18 /dev/rootdbs ->
> > /dev/VolGrp01/vol01
> >
> > and the rootdbs link points to another link, and ls -l on that link
> > produces:
> >
> > lrwxrwxrwx 1 root root 26 Jun 15 15:49 /dev/VolGrp01/vol01 ->
> > /d
Thanks Art,
This info will be useful either this time around or in
the future for checking chunks validity.
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
Kagel
Sent: Monday, June 20, 2011 1:24 PM
To: ids@iiug.org
Subject: Re: is there a way to find out the physical de.... [24093]
Sanity check failures mean that the pages in the chunks do not "look
right". The 20 byte at the beginning of each page doesn't look like it
contains the correct header information or the checksum at the bottom of the
page does not match the calculated checksum for the page. Also the first
page of the first chunk must contain copyright, platform, and version
details.
Just for information sake. Good luck.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Mon, Jun 20, 2011 at 1:31 PM, jim-cramer@uiowa.edu
<jim-cramer@uiowa.edu>wrote:
> Hi Art,
>
> Thanks for your reply from 6/16 with some suggested things to check.
>
> The permissions and ownership of the chunk device files, in /dev/mapper
> directory, had been correct.
>
> Your suggestion about changing the ownership of the links might
> have helped. Before I changed the ownership, I had errno 2 on rootdbs
> and this logged into online.log:
>
> 15:30:23 Assert Warning: I/O read chunk 1, pagenum 6641, pagecnt 1 -->
> errno = 2
> 15:30:23 IBM Informix Dynamic Server Version 11.70.FC1GE
> 15:30:23 Who: Session(9, informix@s-l008, 0, 0x50291c20)
>
> Thread(29, xchg_1.2, 502519a8, 3)
>
> File: rsbuff.c Line: 6302
> 15:30:23 Action: Please notify IBM Informix Technical Support.
> 15:30:23 stack trace for pid 12822 written to /opt/db/ids/tmp/af.40567de
> 15:30:23 See Also: /opt/db/ids/tmp/af.40567de
> 15:30:23 I/O read chunk 1, pagenum 6641, pagecnt 1 --> errno = 2
> 15:30:23 Rollforward of log record failed. iserrno = 126
> 15:30:23 Log Record: log = 27, pos = 0x3ef8518, type =
OLDRSAM:HINSERT(40),
> trans = 26
> 15:30:23 Assert Failed: INFORMIX-OnLine Must ABORT
>
> Critical media failure.
>
> (By the way, I also noticed just now that one of my attempts to restart
the
> instance failed on Chunk 6, which is the first chunk of my Logical Logs,
> instead of on Chunk 1.)
>
> NOW:
>
> The ownership of my symbolic link in /dev was 777 BEFORE (when the crash
> shown above
> happened) but the ownership was root. So, I changed the ownership of the
> link to
> informix:informix and quite a bit of the above error message went away.
>
> However, I still had an assertion failure, but of a different nature.
> Instead of
> an errno 2 error on my 1st chunk, some sort of sanity check fails at a
> different
> routine in the Thread on I now get this in online.log:
>
> 10:52:59 IBM Informix Dynamic Server Version 11.70.FC1GE Software Serial
> Number AAA#B000000
> 10:52:59 Warning: stat() failed for chunk file /dev/rootdbs
> 10:53:00 Assert Warning: chunk failed sanity check
>
> 10:53:00 IBM Informix Dynamic Server Version 11.70.FC1GE
> 10:53:00 Who: Session(1, informix@s-l008, 0, 0x5028e028)
>
> Thread(8, main_loop(), 50249028, 3)
>
> File: rspartn.c Line: 10531
> 10:53:00 Results: Chunk 1 is being taken OFFLINE.
> 10:53:00 Action: For all spaces other than temporary dbspaces, restore the
> space
>
> containing the chunk from the archive. If this chunk belongs to a
>
> temporary dbspace and if it is not the only chunk in that
> dbspace,
>
> then drop and re-create the chunk. Otherwise drop and re-create
>
> the temporary dbspace.
> 10:53:00 stack trace for pid 8923 written to /opt/db/ids/tmp/af.3f06cdc
> 10:53:00 See Also: /opt/db/ids/tmp/af.3f06cdc
> 10:53:00 chunk failed sanity check
>
> 10:53:01 I/O error, Primary Chunk '/dev/rootdbs' -- Offline (sanity)
> 10:53:01 oninit: Fatal error in shared memory initialization
>
> 10:53:01 IBM Informix Dynamic Server Stopped.
>
> 10:53:01 mt_shm_remove: WARNING: may not have removed all/correct segments
>
> So, I am going to go ahead and change the ownership of all of the symbolic
> links that I created for chunks to informix:informix and see what happens.
>
> I will let you know.
>
> Thanks,
>
> Jim
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
> Kagel
> Sent: Thursday, June 16, 2011 5:59 PM
> To: ids@iiug.org
> Subject: Re: is there a way to find out the physical de.... [24068]
>
> Errno 2 is permissions (EPERM). Make sure that all of the low level chunk
> devices are informix:informix with 0660 privileges and make sure that the
> links themselves are 777 (owner of the links doesn't really matter, but I
> usually make them informix:informix also).
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Thu, Jun 16, 2011 at 5:17 PM, jim-cramer@uiowa.edu
> <jim-cramer@uiowa.edu>wrote:
>
> > Hi Art,
> >
> > Well, no doubt about it, you are THE MAN! I *almost* have the server
> > back up (see below). Good news and bad news.
> >
> > Thanks very much for the clever way of recreating lost symbolic links
> > used originally to create chunks and pointing these links at the actual
> > chunk device file paths/names. This method is based upon your expert
> > knowledge
> > of chunk storage internals.
> >
> > I used your method to get the chunk number for each chunk/block device
> > file (using RAW chunks), looked for that number in the oncfg file's
> > "Chunks" section, got the name of the symbolic link used to create
> > the chunk from that line in the file, and created a script to recreate
> > the symbolic links/pathnames that had been used in the onspaces commands
> > that created the chunks.
> >
> > The server begins to start with the "oninit" command, but it ABORTS.
> > According to the online.log file, it gets quite a ways through startup
> > but finds something wrong, Errno 2 (missing file or directory?)
> > with chunk 1, my rootdbs. I have included the tail end of the log file,
> > starting just before the warning about chunk 1, continuing to the end.
> >
> > Any
Jim, We use either CentOS or RedHat Enterprise versions (depends on development or production). It is definitely using the Logical Volume Manager. There is no /etc/mapper directory in our version, but the concepts should be the same for you. Below is an example of the shell I use to create the devices. In this case, I had already created a volume group called "informix", and then created logical volumes that all started with sdn. I then created a "links" file that map the relationship between the block device name and the sym link name used to build the actual informix chunks. Hope this helps. ============================================================================ ==================================== #!/bin/bash . /etc/profile cd /ifxslices for device in `ls -l /dev/mapper/informix-sdn[1-9]*|tr -s " "|tr " " "|"` do major=`echo $device |cut -d "|" -f5` minor=`echo $device |cut -d "|" -f6` block="blockdevices/`echo $device |cut -d "|" -f10|cut -d "-" -f2`" echo $major $minor $block mknod $block b $major $minor chown informix:informix $block chmod 660 $block done for line in `cat newlinks4` do slice=`echo $line|cut -d "|" -f1` block=`echo $line|cut -d "|" -f2` echo $slice ln -s blockdevices/${block} $slice done chown -h informix:informix slice* ============================================================================ ======================== Here's my mapping file from the block device to the sym link (newlinks4) slice161|sdn1 slice162|sdn2 slice163|sdn3 slice164|sdn5 slice165|sdn6 slice166|sdn7 slice167|sdn8 slice168|sdn9 ============================================================================ ========================= -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Cramer, James A Sent: Monday, June 20, 2011 12:44 PM To: ids@iiug.org Subject: RE: is there a way to find out the physical de.... [24091] Jamie, Thanks for the idea. I need a bit more info if you have time.. 1. What is the OS and Version that you are running IDS on? 2. And if Linux, is it the Open Edition or the Enterprise Edition? 3. If it is on Linux, is the OS using the "device mapper". You can tell by looking in /dev for a directory called mapper. If it is there, you should find the actual block device files that the system's Logical Volume Manager created if you used it to partition a disk. If you did, then the device files are in /etc/mapper instead of in /dev/VolGrpxx (where xx is the Volume Group Number that the Logical Volumes were created from), and in this directory are symbolic links, instead of the actual LV device files, which point to the actual device files in /dev/mapper. Again, does your system use this mapper functionality? It is important for me to know in order to know whether I will be able to get away with using the method that you use and have explained below. Please let me know the answers to these questions if you have the time. Thanks again, Jim -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Jamie Gedye Sent: Friday, June 17, 2011 12:16 PM To: ids@iiug.org Subject: RE: is there a way to find out the physical de.... [24078] We use the same concept with creating sym links to the actual LVM devices. The difference is that we create our own block devices that use the same major,minor numbers as the LVM device and then point the sym links to the ones we created. For example: LVM device: brw-rw---- 1 root disk 253, 8 May 13 11:37 dm-8 (notice the major,minor is 253,8) We have a directory called /ifxslices/blockdevices that has our created devices. Use the mknod command to create the device. brw-rw----. 1 informix informix 253, 8 Jun 17 07:33 /ifxslices/blockdevices/rootdbs (notice that the major,minor numbers are the same as the LVM device, and the permissions/ownership are set the way informix needs them to be). Lastly, we create sym links to point to our block devices and use them in the creation of the dbspaces. lrwxrwxrwx. 1 informix informix 20 May 2 15:12 /ifxslices/rootdbs -> blockdevices/rootdbs This way there's in a script or anything that needs to be run on every machine boot to make sure that the devices are setup the way you need them to be. Just make sure to protect the directory that you put everything in so that there's no chance to somebody removing them accidently. -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of jim-cramer@uiowa.edu Sent: Friday, June 17, 2011 9:57 AM To: ids@iiug.org Subject: RE: is there a way to find out the physical de.... [24077] Hi Art, Thanks for answering this and I understand. I will figure out the details of this SuSE device file symbolic link shuffling. Or, if anyone who happens to read this knows what to point the Symbolic Links the DBA creates for the Informix Chunks at, please post it or email me. Again, I owe you major thanks Art for the information and clever way of finding out which Informix Chunk# every device file had been assigned, in the case that the Symbolic Links used to create the Chunks in Informix get blown away and have to be recreated. I could not have gotten anywhere without that info. Much appreciated, Jim Cramer Univ of Iowa jim-cramer@uiowa.edu > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > Art Kagel > Sent: Friday, June 17, 2011 9:09 AM > To: ids@iiug.org > Subject: Re: is there a way to find out the physical de.... [24076] > > I haven't used SUSE with Informix myself. I use Ubuntu here at home > but with simple files and DIRECT_IO just for simplicity of mgt. At > ADTC out main servers are on Sun/Solaris and the training servers are > SUSE but again just using simple files. When clients have systems for > me to configure, I try not to get involved in the "how" of > implementing the storage whenever I can. I haven't done serious SA > work in 20 years or more so I try to stay out. > > Art > > Art S. Kagel > Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Fri, Jun 17, 2011 at 9:41 AM, jim-cramer@uiowa.edu > <jim-cramer@uiowa.edu>wrote: > > > Thanks again Art. > > > > I will check what you suggest. > > >
Thanks again for your help Jamie and the further
information. I will have a look at this for ideas
for the future.
I figured out what to point my Informix Chunks symbolic
links at in our SuSE Enterprise system.
In case you ever need to do an Informix IDS install on
a system that uses the "Device Mapper" device abstraction
concept, be sure to make the target of the symbolic
links you create (for onspaces use) at the device files
which you will find in /dev/mapper dir.
The Device Mapper concept is to handle the situation
when, at system boot, physical storage devices are
sometimes presented to the system in a different order
and therefore the low level name for the storage
devices changes (ex: sd1 becomes sd3). The device mapper
ensures that the Logical Volume Manager and other things
always can use the same pathname to reference the same
Volume Group or Logical Volume. It prevents the old
problem that Windows95 and Windows98 had where the Windows
Drive Letter for a peripheral device would change
(ex: D: becomes E:) and that would break things that used
a path, with the Drive Letter, to files on the peripheral
device.
Thanks again,
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Jamie
Gedye
Sent: Monday, June 20, 2011 2:08 PM
To: ids@iiug.org
Subject: RE: is there a way to find out the physical de.... [24097]
Jim,
We use either CentOS or RedHat Enterprise versions (depends on development
or production).
It is definitely using the Logical Volume Manager.
There is no /etc/mapper directory in our version, but the concepts should be
the same for you.
Below is an example of the shell I use to create the devices. In this case,
I had already created a volume group called "informix", and then created
logical volumes that all started with sdn. I then created a "links" file
that map the relationship between the block device name and the sym link
name used to build the actual informix chunks.
Hope this helps.
============================================================================
====================================
#!/bin/bash
.. /etc/profile
cd /ifxslices
for device in `ls -l /dev/mapper/informix-sdn[1-9]*|tr -s " "|tr " " "|"`
do
major=`echo $device |cut -d "|" -f5`
minor=`echo $device |cut -d "|" -f6`
block="blockdevices/`echo $device |cut -d "|" -f10|cut -d "-" -f2`"
echo $major $minor $block
mknod $block b $major $minor
chown informix:informix $block
chmod 660 $block
done
for line in `cat newlinks4`
do
slice=`echo $line|cut -d "|" -f1`
block=`echo $line|cut -d "|" -f2`
echo $slice
ln -s blockdevices/${block} $slice
done
chown -h informix:informix slice*
============================================================================
========================
Here's my mapping file from the block device to the sym link (newlinks4)
slice161|sdn1
slice162|sdn2
slice163|sdn3
slice164|sdn5
slice165|sdn6
slice166|sdn7
slice167|sdn8
slice168|sdn9
============================================================================
=========================
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Cramer, James A
Sent: Monday, June 20, 2011 12:44 PM
To: ids@iiug.org
Subject: RE: is there a way to find out the physical de.... [24091]
Jamie,
Thanks for the idea. I need a bit more info if you have time..
1. What is the OS and Version that you are running IDS on?
2. And if Linux, is it the Open Edition or the Enterprise Edition?
3. If it is on Linux, is the OS using the "device mapper". You can tell by
looking in /dev for a directory called mapper.
If it is there, you should find the actual block device files that the
system's Logical Volume Manager created if you used it to partition a disk.
If you did, then the device files are in /etc/mapper instead of in
/dev/VolGrpxx (where xx is the Volume Group Number that the Logical Volumes
were created from), and in this directory are symbolic links, instead of the
actual LV device files, which point to the actual device files in
/dev/mapper.
Again, does your system use this mapper functionality? It is important for
me to know in order to know whether I will be able to get away with using
the method that you use and have explained below.
Please let me know the answers to these questions if you have the time.
Thanks again,
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Jamie
Gedye
Sent: Friday, June 17, 2011 12:16 PM
To: ids@iiug.org
Subject: RE: is there a way to find out the physical de.... [24078]
We use the same concept with creating sym links to the actual LVM devices.
The difference is that we create our own block devices that use the same
major,minor numbers as the LVM device and then point the sym links to the
ones we created.
For example:
LVM device:
brw-rw---- 1 root disk 253, 8 May 13 11:37 dm-8 (notice the major,minor is
253,8)
We have a directory called /ifxslices/blockdevices that has our created
devices. Use the mknod command to create the device.
brw-rw----. 1 informix informix 253, 8 Jun 17 07:33
/ifxslices/blockdevices/rootdbs (notice that the major,minor numbers are the
same as the LVM device, and the permissions/ownership are set the way
informix needs them to be).
Lastly, we create sym links to point to our block devices and use them in
the creation of the dbspaces.
lrwxrwxrwx. 1 informix informix 20 May 2 15:12 /ifxslices/rootdbs ->
blockdevices/rootdbs
This way there's in a script or anything that needs to be run on every
machine boot to make sure that the devices are setup the way you need them
to be. Just make sure to protect the directory that you put everything in so
that there's no chance to somebody removing them accidently.
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
jim-cramer@uiowa.edu
Sent: Friday, June 17, 2011 9:57 AM
To: ids@iiug.org
Subject: RE: is there a way to find out the physical de.... [24077]
Hi Art,
Thanks for answering this and I understand.
I will figure out the details of this SuSE device file symbolic link
shuffling. Or, if anyone who happens to read this knows what to point the
Symbolic Links the DBA creates for the Informix Chunks at, please post it or
email me.
Again, I owe you major thanks Art for the information and clever way of
finding out which Informix Chunk# every device file had been assigned, in
the case that the Symbolic Links used to create the Chunks in Informix get
blown away and have to be recreated.
I could not have gotten anywhere without that info.
Much appreciated,
Jim C
Art, and anyone who wants to install IDS on Enterprise SuSE 11,
please read on:
The permissions and ownership of the sym links pointing to the
logical volume device files for my IDS Chunks was not causing
the problem and errno 2 that happened when trying to start up IDS.
It turns out that I had the sym links that I created pointing at
the sym links created by the Device Mapper feature of Enterprise
SuSE 11. The Mapper's sym links in turn point at the actual
device files for the Logical Volumes which live in /dev/mapper.
Apparently this does not work. The sym links that I create
must point directly to the device files in /dev/mapper.
This probably sounds a bit nebulous and anyone installing IDS
on a Linux system using Device Mapper should know what to do,
so I will give an example of what I mean:
For my rootdbs, I created a Logical Volume using the SuSE 11
"Partitioner" and called it "vol01".
Instead of finding the device file for it, that the LVM created,
in /dev/<volume_group_name> with the name "vol01", I
found it in the dir /etc/mapper with the name "<volume_group_name>-vol01".
In /dev/<volume_group_name> I found a symbolic link created by
either the LVM or Device Mapper called "vol01" that points to the
actual device file /etc/mapper/<vol_grp_name>-vol01.
1) for my rootdbs chunk, I created the symbolic link /dev/rootdbs:
ls -l /dev listing shows:
lrwxrwxrwx 1 root root 26 Jun 20 15:20 rootdbs ->
/dev/mapper/VolGrp01-vol01
ls -lL /dev listing shows:
brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
rootdbs
2) Originally, I had my link from (1) pointing straight to the device file
shown in (3), as the
"ls -l" in (1) shows. After rebooting the system and discovering that
all of the links that
I created in /dev were removed by the reboot and that the reboot had
also undone the
permissions and ownership changes that I gave the device files in (3).
So, when I recreated my sym links that I use with onspaces to create the
IDS Chunks, I was
not sure what was going on so I tried pointing the links that I created
in (1) at the links
in (2), which in turn point to the device files. Note that the "ls -lL"
listing in (1) even
shows the correct permissions and ownership of the link's target which
is accessed via a
double-link hop.
BUT THIS DOES NOT WORK.
ls -l /dev/VolGrp01 shows:
lrwxrwxrwx 1 root root 26 Jun 15 15:49 vol01 ->
/dev/mapper/VolGrp01-vol01
ls -lL /dev/VolGrp01 shows:
brw-rw---- 1 informix informix 253, 5 Jun 21 01:00 vol01
3) THE SYBMOLIC LINKS CREATED BY THE DBA FOR USE WITH onspaces MUST POINT
DIRECTLY TO THESE OBJECTS:
ls -l /dev/mapper shows:
brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
VolGrp01-vol01
ls -lL /dev/mapper shows:
brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
VolGrp01-vol01
What is really irritating is that the nowhere in the IDS 11 Information
Center, IDS Installation
Guide, Administrator Manuals, Release Notes for the 11.70.xC1 IDS Version,
and Machine Notes for
the port was there any mention or warning about symbolic links in /dev being
removed &
permissions and ownership customizations of logical volume device files used
as chunks being undone
when the system is rebooted, or how to deal with it. In fact, when I called
it in to Informix Tech
Support under my contract, the engineer had apparently never heard about
this scenario that occurs
when installing IDS on some flavors of Linux.
What is doubly annoying is that, apparently, when using IDS on Linux, the
DBA needs to
refer to manuals or notes in manuals that are specific for "Unix", as
opposed to Windows,
and there is no documentation or notes in documentation regarding
Linux-specific issues
such as what happened to me. Certainly there are many more Linux-specific
instructions,
notes, etc. that would not apply to the commercial Unix systems.
Regards,
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
Kagel
Sent: Thursday, June 16, 2011 5:59 PM
To: ids@iiug.org
Subject: Re: is there a way to find out the physical de.... [24068]
Errno 2 is permissions (EPERM). Make sure that all of the low level chunk
devices are informix:informix with 0660 privileges and make sure that the
links themselves are 777 (owner of the links doesn't really matter, but I
usually make them informix:informix also).
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Thu, Jun 16, 2011 at 5:17 PM, jim-cramer@uiowa.edu
<jim-cramer@uiowa.edu>wrote:
> Hi Art,
>
> Well, no doubt about it, you are THE MAN! I *almost* have the server
> back up (see below). Good news and bad news.
>
> Thanks very much for the clever way of recreating lost symbolic links
> used originally to create chunks and pointing these links at the actual
> chunk device file paths/names. This method is based upon your expert
> knowledge
> of chunk storage internals.
>
> I used your method to get the chunk number for each chunk/block device
> file (using RAW chunks), looked for that number in the oncfg file's
> "Chunks" section, got the name of the symbolic link used to create
> the chunk from that line in the file, and created a script to recreate
> the symbolic links/pathnames that had been used in the onspaces commands
> that created the chunks.
>
> The server begins to start with the "oninit" command, but it ABORTS.
> According to the online.log file, it gets quite a ways through startup
> but finds something wrong, Errno 2 (missing file or directory?)
> with chunk 1, my rootdbs. I have included the tail end of the log file,
> starting just before the warning about chunk 1, continuing to the end.
>
> Any ideas? It seems like perhaps I made a mistake with the creation of
> the symbolic link for rootdbs, but it looks OK I think. The "ls -l" of it
> produces:
>
> lrwxrwxrwx 1 root root 19 Jun 16 15:18 /dev/rootdbs ->
> /dev/VolGrp01/vol01
>
> and the rootdbs link points to another link, and ls -l on that link
> produces:
>
> lrwxrwxrwx 1 root root 26 Jun 15 15:49 /dev/VolGrp01/vol01 ->
> /dev/mapper/VolGrp01-vol01
>
> and ls -l on the target of that link, the block device file for the LV
that
> I used to create Chunk 1 with, produces:
>
> brw-rw---- 1 informix informix 253, 5 Jun 15 10:49
> /dev/mapper/VolGrp01-vol01
>
> The "ls -lL /dev/rootdbs" command produces:
>
> brw-rw---- 1 informix informix 253, 5 Jun 15 10:49 /dev/r
Thanks Jim. Your pain will be everyone's gain.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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, Jun 21, 2011 at 1:06 PM, jim-cramer@uiowa.edu
<jim-cramer@uiowa.edu>wrote:
> Art, and anyone who wants to install IDS on Enterprise SuSE 11,
> please read on:
>
> The permissions and ownership of the sym links pointing to the
> logical volume device files for my IDS Chunks was not causing
> the problem and errno 2 that happened when trying to start up IDS.
>
> It turns out that I had the sym links that I created pointing at
> the sym links created by the Device Mapper feature of Enterprise
> SuSE 11. The Mapper's sym links in turn point at the actual
> device files for the Logical Volumes which live in /dev/mapper.
> Apparently this does not work. The sym links that I create
> must point directly to the device files in /dev/mapper.
>
> This probably sounds a bit nebulous and anyone installing IDS
> on a Linux system using Device Mapper should know what to do,
> so I will give an example of what I mean:
>
> For my rootdbs, I created a Logical Volume using the SuSE 11
> "Partitioner" and called it "vol01".
>
> Instead of finding the device file for it, that the LVM created,
> in /dev/<volume_group_name> with the name "vol01", I
> found it in the dir /etc/mapper with the name "<volume_group_name>-vol01".
>
> In /dev/<volume_group_name> I found a symbolic link created by
> either the LVM or Device Mapper called "vol01" that points to the
> actual device file /etc/mapper/<vol_grp_name>-vol01.
>
> 1) for my rootdbs chunk, I created the symbolic link /dev/rootdbs:
>
> ls -l /dev listing shows:
>
> lrwxrwxrwx 1 root root 26 Jun 20 15:20 rootdbs ->
> /dev/mapper/VolGrp01-vol01
>
> ls -lL /dev listing shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
> rootdbs
>
> 2) Originally, I had my link from (1) pointing straight to the device file
> shown in (3), as the
>
> "ls -l" in (1) shows. After rebooting the system and discovering that
> all of the links that
>
> I created in /dev were removed by the reboot and that the reboot had
> also undone the
>
> permissions and ownership changes that I gave the device files in (3).
>
> So, when I recreated my sym links that I use with onspaces to create the
> IDS Chunks, I was
>
> not sure what was going on so I tried pointing the links that I created
> in (1) at the links
>
> in (2), which in turn point to the device files. Note that the "ls -lL"
> listing in (1) even
>
> shows the correct permissions and ownership of the link's target which
> is accessed via a
>
> double-link hop.
>
> BUT THIS DOES NOT WORK.
>
> ls -l /dev/VolGrp01 shows:
>
> lrwxrwxrwx 1 root root 26 Jun 15 15:49 vol01 ->
> /dev/mapper/VolGrp01-vol01
>
> ls -lL /dev/VolGrp01 shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00 vol01
>
> 3) THE SYBMOLIC LINKS CREATED BY THE DBA FOR USE WITH onspaces MUST POINT
> DIRECTLY TO THESE OBJECTS:
>
> ls -l /dev/mapper shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
> VolGrp01-vol01
>
> ls -lL /dev/mapper shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
> VolGrp01-vol01
>
> What is really irritating is that the nowhere in the IDS 11 Information
> Center, IDS Installation
> Guide, Administrator Manuals, Release Notes for the 11.70.xC1 IDS Version,
> and Machine Notes for
> the port was there any mention or warning about symbolic links in /dev
> being
> removed &
> permissions and ownership customizations of logical volume device files
> used
> as chunks being undone
> when the system is rebooted, or how to deal with it. In fact, when I called
> it in to Informix Tech
> Support under my contract, the engineer had apparently never heard about
> this scenario that occurs
> when installing IDS on some flavors of Linux.
>
> What is doubly annoying is that, apparently, when using IDS on Linux, the
> DBA needs to
> refer to manuals or notes in manuals that are specific for "Unix", as
> opposed to Windows,
> and there is no documentation or notes in documentation regarding
> Linux-specific issues
> such as what happened to me. Certainly there are many more Linux-specific
> instructions,
> notes, etc. that would not apply to the commercial Unix systems.
>
> Regards,
>
> Jim
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
> Kagel
> Sent: Thursday, June 16, 2011 5:59 PM
> To: ids@iiug.org
> Subject: Re: is there a way to find out the physical de.... [24068]
>
> Errno 2 is permissions (EPERM). Make sure that all of the low level chunk
> devices are informix:informix with 0660 privileges and make sure that the
> links themselves are 777 (owner of the links doesn't really matter, but I
> usually make them informix:informix also).
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Thu, Jun 16, 2011 at 5:17 PM, jim-cramer@uiowa.edu
> <jim-cramer@uiowa.edu>wrote:
>
> > Hi Art,
> >
> > Well, no doubt about it, you are THE MAN! I *almost* have the server
> > back up (see below). Good news and bad news.
> >
> > Thanks very much for the clever way of recreating lost symbolic links
> > used originally to create chunks and pointing these links at the actual
> > chunk device file paths/names. This method is based upon your expert
> > knowledge
> > of chunk storage internals.
> >
> > I used your method to get the chunk number for each chunk/block device
> > file (using RAW chunks), looked for that number in the oncfg file's
> > "Chunks" section, got the name of the symbolic link used to create
> > the chunk from that line in the file, and created a script to recreate
> > the symbolic links/pathnames that had been used in the onspaces commands
> > that created the chunks.
> >
> > The server begins to start with the "oninit" command, but it ABORTS.
> > According to the online.log file, it gets quite a ways through startup
> > but finds something wrong, Errno 2 (missing file or d
Jim,
I found using sym links to be a pain in the butt with sles. I found that it
was much easier to just use persistent storage device minor numbers and make
nodes that point to those devices like so:
cd /dev/mapper
ll
lrwxrwxrwx 1 root root 16 2009-06-29 09:27 control -> ../device-mapper
brw------- 1 root root 253, 4 2009-06-29 09:27 InformixMirror-IDSdbs
brw------- 1 root root 253, 3 2009-06-29 09:27 InformixMirror-IDSRoot
brw------- 1 root root 253, 2 2009-06-29 09:27 InformixPrimary-IDSdbs
brw------- 1 root root 253, 0 2009-06-29 09:27 InformixPrimary-IDSRoot
brw------- 1 root root 253, 1 2009-06-29 09:27 InformixPrimary-IDSTemp
lvchange -M y --major 253 --minor 100 "/dev/mapper/InformixPrimary-IDSRoot"
lvchange -M y --major 253 --minor 101 "/dev/mapper/InformixPrimary-IDSdbs"
lvchange -M y --major 253 --minor 102 "/dev/mapper/InformixPrimary-IDSTemp"
lvchange -M y --major 253 --minor 110 "/dev/mapper/InformixMirror-IDSRoot"
lvchange -M y --major 253 --minor 111 "/dev/mapper/InformixMirror-IDSdbs"
cd /opt/informix
mkdir dev
cd dev
mknod dbs1.1 b 253 101
mknod dbs1.1m b 253 111
mknod dbsroot1.1 b 253 100
mknod dbsroot1.1m b 253 110
mknod dbstemp b 253 102
chown informix:informix *
chmod 660 *
ll /opt/informix/dev
total 0
brw-rw---- 1 informix informix 253, 101 Jun 21 13:45 dbs1.1
brw-rw---- 1 informix informix 253, 111 Jun 21 13:45 dbs1.1m
brw-rw---- 1 informix informix 253, 100 Jun 21 13:49 dbsroot1.1
brw-rw---- 1 informix informix 253, 110 Jun 21 13:49 dbsroot1.1m
brw-rw---- 1 informix informix 253, 103 Jun 21 13:48 dbstemp
Just a thought.
Jonathon Wyza
CX & CBORD System Administrator
CX Programmer/Analyst
Administrative Computing
Bethel College
(574)-807-SQL5(7755)
AIM: Iamwyza
jonathon.wyza@bethelcollege.edu
===============================
SLES 11x64 & IDS 11.50.FC6
JICS 7.4.1 & Cognos 8
"Don't document the problem, fix it."
- Atli Björgvin Oddsson
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art Kagel
Sent: Tuesday, June 21, 2011 1:14 PM
To: ids@iiug.org
Subject: Re: is there a way to find out the physical de.... [24103]
Thanks Jim. Your pain will be everyone's gain.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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, Jun 21, 2011 at 1:06 PM, jim-cramer@uiowa.edu
<jim-cramer@uiowa.edu>wrote:
> Art, and anyone who wants to install IDS on Enterprise SuSE 11, please
> read on:
>
> The permissions and ownership of the sym links pointing to the logical
> volume device files for my IDS Chunks was not causing the problem and
> errno 2 that happened when trying to start up IDS.
>
> It turns out that I had the sym links that I created pointing at the
> sym links created by the Device Mapper feature of Enterprise SuSE 11.
> The Mapper's sym links in turn point at the actual device files for
> the Logical Volumes which live in /dev/mapper.
> Apparently this does not work. The sym links that I create must point
> directly to the device files in /dev/mapper.
>
> This probably sounds a bit nebulous and anyone installing IDS on a
> Linux system using Device Mapper should know what to do, so I will
> give an example of what I mean:
>
> For my rootdbs, I created a Logical Volume using the SuSE 11
> "Partitioner" and called it "vol01".
>
> Instead of finding the device file for it, that the LVM created, in
> /dev/<volume_group_name> with the name "vol01", I found it in the dir
> /etc/mapper with the name "<volume_group_name>-vol01".
>
> In /dev/<volume_group_name> I found a symbolic link created by either
> the LVM or Device Mapper called "vol01" that points to the actual
> device file /etc/mapper/<vol_grp_name>-vol01.
>
> 1) for my rootdbs chunk, I created the symbolic link /dev/rootdbs:
>
> ls -l /dev listing shows:
>
> lrwxrwxrwx 1 root root 26 Jun 20 15:20 rootdbs ->
> /dev/mapper/VolGrp01-vol01
>
> ls -lL /dev listing shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00 rootdbs
>
> 2) Originally, I had my link from (1) pointing straight to the device
> file shown in (3), as the
>
> "ls -l" in (1) shows. After rebooting the system and discovering that
> all of the links that
>
> I created in /dev were removed by the reboot and that the reboot had
> also undone the
>
> permissions and ownership changes that I gave the device files in (3).
>
> So, when I recreated my sym links that I use with onspaces to create
> the IDS Chunks, I was
>
> not sure what was going on so I tried pointing the links that I
> created in (1) at the links
>
> in (2), which in turn point to the device files. Note that the "ls -lL"
> listing in (1) even
>
> shows the correct permissions and ownership of the link's target which
> is accessed via a
>
> double-link hop.
>
> BUT THIS DOES NOT WORK.
>
> ls -l /dev/VolGrp01 shows:
>
> lrwxrwxrwx 1 root root 26 Jun 15 15:49 vol01 ->
> /dev/mapper/VolGrp01-vol01
>
> ls -lL /dev/VolGrp01 shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00 vol01
>
> 3) THE SYBMOLIC LINKS CREATED BY THE DBA FOR USE WITH onspaces MUST
> POINT DIRECTLY TO THESE OBJECTS:
>
> ls -l /dev/mapper shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
> VolGrp01-vol01
>
> ls -lL /dev/mapper shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
> VolGrp01-vol01
>
> What is really irritating is that the nowhere in the IDS 11
> Information Center, IDS Installation Guide, Administrator Manuals,
> Release Notes for the 11.70.xC1 IDS Version, and Machine Notes for the
> port was there any mention or warning about symbolic links in /dev
> being removed & permissions and ownership customizations of logical
> volume device files used as chunks being undone when the system is
> rebooted, or how to deal with it. In fact, when I called it in to
> Informix Tech Support under my contract, the engineer had apparently
> never heard about this scenario that occurs when installing IDS on
> some flavors of Linux.
>
> What is doubly annoying is that, apparently, when using IDS on Linux,
> the DBA needs to refer to manuals or notes in manuals that are
> specific for "Unix", as opposed to Windows, and there is no
> documentation or notes in documentation regarding Linux-specific
> issues such as what happened to me. Certainly there are many more
> Linux-specific instructions, notes, etc. that would not apply to the
> commercial Unix systems.
>
> Regards,
>
> Jim
>@@NL
I like that Art. I think I will put that phrase on
a sign above the door to my office.
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
Kagel
Sent: Tuesday, June 21, 2011 12:14 PM
To: ids@iiug.org
Subject: Re: is there a way to find out the physical de.... [24103]
Thanks Jim. Your pain will be everyone's gain.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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, Jun 21, 2011 at 1:06 PM, jim-cramer@uiowa.edu
<jim-cramer@uiowa.edu>wrote:
> Art, and anyone who wants to install IDS on Enterprise SuSE 11,
> please read on:
>
> The permissions and ownership of the sym links pointing to the
> logical volume device files for my IDS Chunks was not causing
> the problem and errno 2 that happened when trying to start up IDS.
>
> It turns out that I had the sym links that I created pointing at
> the sym links created by the Device Mapper feature of Enterprise
> SuSE 11. The Mapper's sym links in turn point at the actual
> device files for the Logical Volumes which live in /dev/mapper.
> Apparently this does not work. The sym links that I create
> must point directly to the device files in /dev/mapper.
>
> This probably sounds a bit nebulous and anyone installing IDS
> on a Linux system using Device Mapper should know what to do,
> so I will give an example of what I mean:
>
> For my rootdbs, I created a Logical Volume using the SuSE 11
> "Partitioner" and called it "vol01".
>
> Instead of finding the device file for it, that the LVM created,
> in /dev/<volume_group_name> with the name "vol01", I
> found it in the dir /etc/mapper with the name "<volume_group_name>-vol01".
>
> In /dev/<volume_group_name> I found a symbolic link created by
> either the LVM or Device Mapper called "vol01" that points to the
> actual device file /etc/mapper/<vol_grp_name>-vol01.
>
> 1) for my rootdbs chunk, I created the symbolic link /dev/rootdbs:
>
> ls -l /dev listing shows:
>
> lrwxrwxrwx 1 root root 26 Jun 20 15:20 rootdbs ->
> /dev/mapper/VolGrp01-vol01
>
> ls -lL /dev listing shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
> rootdbs
>
> 2) Originally, I had my link from (1) pointing straight to the device file
> shown in (3), as the
>
> "ls -l" in (1) shows. After rebooting the system and discovering that
> all of the links that
>
> I created in /dev were removed by the reboot and that the reboot had
> also undone the
>
> permissions and ownership changes that I gave the device files in (3).
>
> So, when I recreated my sym links that I use with onspaces to create the
> IDS Chunks, I was
>
> not sure what was going on so I tried pointing the links that I created
> in (1) at the links
>
> in (2), which in turn point to the device files. Note that the "ls -lL"
> listing in (1) even
>
> shows the correct permissions and ownership of the link's target which
> is accessed via a
>
> double-link hop.
>
> BUT THIS DOES NOT WORK.
>
> ls -l /dev/VolGrp01 shows:
>
> lrwxrwxrwx 1 root root 26 Jun 15 15:49 vol01 ->
> /dev/mapper/VolGrp01-vol01
>
> ls -lL /dev/VolGrp01 shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00 vol01
>
> 3) THE SYBMOLIC LINKS CREATED BY THE DBA FOR USE WITH onspaces MUST POINT
> DIRECTLY TO THESE OBJECTS:
>
> ls -l /dev/mapper shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
> VolGrp01-vol01
>
> ls -lL /dev/mapper shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
> VolGrp01-vol01
>
> What is really irritating is that the nowhere in the IDS 11 Information
> Center, IDS Installation
> Guide, Administrator Manuals, Release Notes for the 11.70.xC1 IDS Version,
> and Machine Notes for
> the port was there any mention or warning about symbolic links in /dev
> being
> removed &
> permissions and ownership customizations of logical volume device files
> used
> as chunks being undone
> when the system is rebooted, or how to deal with it. In fact, when I
called
> it in to Informix Tech
> Support under my contract, the engineer had apparently never heard about
> this scenario that occurs
> when installing IDS on some flavors of Linux.
>
> What is doubly annoying is that, apparently, when using IDS on Linux, the
> DBA needs to
> refer to manuals or notes in manuals that are specific for "Unix", as
> opposed to Windows,
> and there is no documentation or notes in documentation regarding
> Linux-specific issues
> such as what happened to me. Certainly there are many more Linux-specific
> instructions,
> notes, etc. that would not apply to the commercial Unix systems.
>
> Regards,
>
> Jim
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
> Kagel
> Sent: Thursday, June 16, 2011 5:59 PM
> To: ids@iiug.org
> Subject: Re: is there a way to find out the physical de.... [24068]
>
> Errno 2 is permissions (EPERM). Make sure that all of the low level chunk
> devices are informix:informix with 0660 privileges and make sure that the
> links themselves are 777 (owner of the links doesn't really matter, but I
> usually make them informix:informix also).
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Thu, Jun 16, 2011 at 5:17 PM, jim-cramer@uiowa.edu
> <jim-cramer@uiowa.edu>wrote:
>
> > Hi Art,
> >
> > Well, no doubt about it, you are THE MAN! I *almost* have the server
> > back up (see below). Good news and bad news.
> >
> > Thanks very much for the clever way of recreating lost symbolic links
> > used originally to create chunks and pointing these links at the actual
> > chunk device file paths/names. This method is based upon your expert
> > knowledge
> > of chunk storage internals.
> >
> > I used your method to get the chunk number for each chunk/block device
> > file (using RAW chunks), looked for that number in the oncfg file's
> > "Chunks" section, got the name of the symbolic link used to create
> > t
Thank you very much for sharing how you deal with this
SLES scenario Jonathon. I was not aware of the concept
of persistent storage device minor numbers. I can see
where it definitely cuts out not only the hassle with
restoring the symbolic links at system restart time, but
also the removes need to deal with restoring the
permissions and ownership on the /dev/mapper device
files when restarting the system and before brining
up IDS.
Also, your method seems similar to the one that
Jamie Gedye suggested to this thread last week.
I need to look at some man pages relevant to your
method and then discuss this with our Linux Sys Admins.
If I can get them to check off on your method,
I may "borrow it" from you and go that route
instead of recreating symbolic links and resetting
device file permissions & ownership in the system
startup script for IDS.
Thanks again,
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Wyza,
Jonathon
Sent: Tuesday, June 21, 2011 12:56 PM
To: ids@iiug.org
Subject: RE: is there a way to find out the physical de.... [24104]
Jim,
I found using sym links to be a pain in the butt with sles. I found that it
was much easier to just use persistent storage device minor numbers and make
nodes that point to those devices like so:
cd /dev/mapper
ll
lrwxrwxrwx 1 root root 16 2009-06-29 09:27 control -> ../device-mapper
brw------- 1 root root 253, 4 2009-06-29 09:27 InformixMirror-IDSdbs
brw------- 1 root root 253, 3 2009-06-29 09:27 InformixMirror-IDSRoot
brw------- 1 root root 253, 2 2009-06-29 09:27 InformixPrimary-IDSdbs
brw------- 1 root root 253, 0 2009-06-29 09:27 InformixPrimary-IDSRoot
brw------- 1 root root 253, 1 2009-06-29 09:27 InformixPrimary-IDSTemp
lvchange -M y --major 253 --minor 100 "/dev/mapper/InformixPrimary-IDSRoot"
lvchange -M y --major 253 --minor 101 "/dev/mapper/InformixPrimary-IDSdbs"
lvchange -M y --major 253 --minor 102 "/dev/mapper/InformixPrimary-IDSTemp"
lvchange -M y --major 253 --minor 110 "/dev/mapper/InformixMirror-IDSRoot"
lvchange -M y --major 253 --minor 111 "/dev/mapper/InformixMirror-IDSdbs"
cd /opt/informix
mkdir dev
cd dev
mknod dbs1.1 b 253 101
mknod dbs1.1m b 253 111
mknod dbsroot1.1 b 253 100
mknod dbsroot1.1m b 253 110
mknod dbstemp b 253 102
chown informix:informix *
chmod 660 *
ll /opt/informix/dev
total 0
brw-rw---- 1 informix informix 253, 101 Jun 21 13:45 dbs1.1
brw-rw---- 1 informix informix 253, 111 Jun 21 13:45 dbs1.1m
brw-rw---- 1 informix informix 253, 100 Jun 21 13:49 dbsroot1.1
brw-rw---- 1 informix informix 253, 110 Jun 21 13:49 dbsroot1.1m
brw-rw---- 1 informix informix 253, 103 Jun 21 13:48 dbstemp
Just a thought.
Jonathon Wyza
CX & CBORD System Administrator
CX Programmer/Analyst
Administrative Computing
Bethel College
(574)-807-SQL5(7755)
AIM: Iamwyza
jonathon.wyza@bethelcollege.edu
===============================
SLES 11x64 & IDS 11.50.FC6
JICS 7.4.1 & Cognos 8
"Don't document the problem, fix it."
- Atli Björgvin Oddsson
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
Kagel
Sent: Tuesday, June 21, 2011 1:14 PM
To: ids@iiug.org
Subject: Re: is there a way to find out the physical de.... [24103]
Thanks Jim. Your pain will be everyone's gain.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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, Jun 21, 2011 at 1:06 PM, jim-cramer@uiowa.edu
<jim-cramer@uiowa.edu>wrote:
> Art, and anyone who wants to install IDS on Enterprise SuSE 11, please
> read on:
>
> The permissions and ownership of the sym links pointing to the logical
> volume device files for my IDS Chunks was not causing the problem and
> errno 2 that happened when trying to start up IDS.
>
> It turns out that I had the sym links that I created pointing at the
> sym links created by the Device Mapper feature of Enterprise SuSE 11.
> The Mapper's sym links in turn point at the actual device files for
> the Logical Volumes which live in /dev/mapper.
> Apparently this does not work. The sym links that I create must point
> directly to the device files in /dev/mapper.
>
> This probably sounds a bit nebulous and anyone installing IDS on a
> Linux system using Device Mapper should know what to do, so I will
> give an example of what I mean:
>
> For my rootdbs, I created a Logical Volume using the SuSE 11
> "Partitioner" and called it "vol01".
>
> Instead of finding the device file for it, that the LVM created, in
> /dev/<volume_group_name> with the name "vol01", I found it in the dir
> /etc/mapper with the name "<volume_group_name>-vol01".
>
> In /dev/<volume_group_name> I found a symbolic link created by either
> the LVM or Device Mapper called "vol01" that points to the actual
> device file /etc/mapper/<vol_grp_name>-vol01.
>
> 1) for my rootdbs chunk, I created the symbolic link /dev/rootdbs:
>
> ls -l /dev listing shows:
>
> lrwxrwxrwx 1 root root 26 Jun 20 15:20 rootdbs ->
> /dev/mapper/VolGrp01-vol01
>
> ls -lL /dev listing shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00 rootdbs
>
> 2) Originally, I had my link from (1) pointing straight to the device
> file shown in (3), as the
>
> "ls -l" in (1) shows. After rebooting the system and discovering that
> all of the links that
>
> I created in /dev were removed by the reboot and that the reboot had
> also undone the
>
> permissions and ownership changes that I gave the device files in (3).
>
> So, when I recreated my sym links that I use with onspaces to create
> the IDS Chunks, I was
>
> not sure what was going on so I tried pointing the links that I
> created in (1) at the links
>
> in (2), which in turn point to the device files. Note that the "ls -lL"
> listing in (1) even
>
> shows the correct permissions and ownership of the link's target which
> is accessed via a
>
> double-link hop.
>
> BUT THIS DOES NOT WORK.
>
> ls -l /dev/VolGrp01 shows:
>
> lrwxrwxrwx 1 root root 26 Jun 15 15:49 vol01 ->
> /dev/mapper/VolGrp01-vol01
>
> ls -lL /dev/VolGrp01 shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00 vol01
>
> 3) THE SYBMOLIC LINKS CREATED BY THE DBA FOR USE WITH onspaces MUST
> POINT DIRECTLY TO THESE OBJECTS:
>
> ls -l /dev/mapper shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
> VolGrp01-vol01
>
> ls -lL /dev/mapper shows:
>@@NL@
I believe when RedHat went from the 2.4 to 2.6 kernel, the links had to be
setup with the /dev/udev/ 'process' or they disappeared on reboot. It's been a
while. Yes, learned the hard way.
Bob
----- Original Message -----
From: "Art Kagel" <art.kagel@gmail.com>
To: ids@iiug.org
Sent: Tuesday, June 21, 2011 1:14:21 PM
Subject: Re: is there a way to find out the physical de.... [24103]
Thanks Jim. Your pain will be everyone's gain.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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, Jun 21, 2011 at 1:06 PM, jim-cramer@uiowa.edu
<jim-cramer@uiowa.edu>wrote:
> Art, and anyone who wants to install IDS on Enterprise SuSE 11,
> please read on:
>
> The permissions and ownership of the sym links pointing to the
> logical volume device files for my IDS Chunks was not causing
> the problem and errno 2 that happened when trying to start up IDS.
>
> It turns out that I had the sym links that I created pointing at
> the sym links created by the Device Mapper feature of Enterprise
> SuSE 11. The Mapper's sym links in turn point at the actual
> device files for the Logical Volumes which live in /dev/mapper.
> Apparently this does not work. The sym links that I create
> must point directly to the device files in /dev/mapper.
>
> This probably sounds a bit nebulous and anyone installing IDS
> on a Linux system using Device Mapper should know what to do,
> so I will give an example of what I mean:
>
> For my rootdbs, I created a Logical Volume using the SuSE 11
> "Partitioner" and called it "vol01".
>
> Instead of finding the device file for it, that the LVM created,
> in /dev/<volume_group_name> with the name "vol01", I
> found it in the dir /etc/mapper with the name "<volume_group_name>-vol01".
>
> In /dev/<volume_group_name> I found a symbolic link created by
> either the LVM or Device Mapper called "vol01" that points to the
> actual device file /etc/mapper/<vol_grp_name>-vol01.
>
> 1) for my rootdbs chunk, I created the symbolic link /dev/rootdbs:
>
> ls -l /dev listing shows:
>
> lrwxrwxrwx 1 root root 26 Jun 20 15:20 rootdbs ->
> /dev/mapper/VolGrp01-vol01
>
> ls -lL /dev listing shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
> rootdbs
>
> 2) Originally, I had my link from (1) pointing straight to the device file
> shown in (3), as the
>
> "ls -l" in (1) shows. After rebooting the system and discovering that
> all of the links that
>
> I created in /dev were removed by the reboot and that the reboot had
> also undone the
>
> permissions and ownership changes that I gave the device files in (3).
>
> So, when I recreated my sym links that I use with onspaces to create the
> IDS Chunks, I was
>
> not sure what was going on so I tried pointing the links that I created
> in (1) at the links
>
> in (2), which in turn point to the device files. Note that the "ls -lL"
> listing in (1) even
>
> shows the correct permissions and ownership of the link's target which
> is accessed via a
>
> double-link hop.
>
> BUT THIS DOES NOT WORK.
>
> ls -l /dev/VolGrp01 shows:
>
> lrwxrwxrwx 1 root root 26 Jun 15 15:49 vol01 ->
> /dev/mapper/VolGrp01-vol01
>
> ls -lL /dev/VolGrp01 shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00 vol01
>
> 3) THE SYBMOLIC LINKS CREATED BY THE DBA FOR USE WITH onspaces MUST POINT
> DIRECTLY TO THESE OBJECTS:
>
> ls -l /dev/mapper shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
> VolGrp01-vol01
>
> ls -lL /dev/mapper shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
> VolGrp01-vol01
>
> What is really irritating is that the nowhere in the IDS 11 Information
> Center, IDS Installation
> Guide, Administrator Manuals, Release Notes for the 11.70.xC1 IDS Version,
> and Machine Notes for
> the port was there any mention or warning about symbolic links in /dev
> being
> removed &
> permissions and ownership customizations of logical volume device files
> used
> as chunks being undone
> when the system is rebooted, or how to deal with it. In fact, when I called
> it in to Informix Tech
> Support under my contract, the engineer had apparently never heard about
> this scenario that occurs
> when installing IDS on some flavors of Linux.
>
> What is doubly annoying is that, apparently, when using IDS on Linux, the
> DBA needs to
> refer to manuals or notes in manuals that are specific for "Unix", as
> opposed to Windows,
> and there is no documentation or notes in documentation regarding
> Linux-specific issues
> such as what happened to me. Certainly there are many more Linux-specific
> instructions,
> notes, etc. that would not apply to the commercial Unix systems.
>
> Regards,
>
> Jim
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
> Kagel
> Sent: Thursday, June 16, 2011 5:59 PM
> To: ids@iiug.org
> Subject: Re: is there a way to find out the physical de.... [24068]
>
> Errno 2 is permissions (EPERM). Make sure that all of the low level chunk
> devices are informix:informix with 0660 privileges and make sure that the
> links themselves are 777 (owner of the links doesn't really matter, but I
> usually make them informix:informix also).
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Thu, Jun 16, 2011 at 5:17 PM, jim-cramer@uiowa.edu
> <jim-cramer@uiowa.edu>wrote:
>
> > Hi Art,
> >
> > Well, no doubt about it, you are THE MAN! I *almost* have the server
> > back up (see below). Good news and bad news.
> >
> > Thanks very much for the clever way of recreating lost symbolic links
> > used originally to create chunks and pointing these links at the actual
> > chunk device file paths/names. This method is based upon your expert
> > knowledge
> > of chunk storage internals.
> >
> > I used your method to get the chunk number for each chunk/block device
> > file (using RAW chunks), looked for that number in the oncfg file's
> > "Chunks" section, got the name of the
Thanks Bob. SLES has a /dev/udev process and I will check that
out. That would take care of one of the 2 problems, the links
disappearing. But that would still leave the 2nd problem,
the customization of permissions and ownership on the device
files for the Informix chunks disappearing on reboot.
I like the looks of the method that Jonathon Wyza posted earlier
today on this thread. I am going to look into that.
Thanks again,
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
rroussey@comcast.net
Sent: Tuesday, June 21, 2011 5:05 PM
To: ids@iiug.org
Subject: Re: is there a way to find out the physical de.... [24107]
I believe when RedHat went from the 2.4 to 2.6 kernel, the links had to be
setup with the /dev/udev/ 'process' or they disappeared on reboot. It's been
a
while. Yes, learned the hard way.
Bob
----- Original Message -----
From: "Art Kagel" <art.kagel@gmail.com>
To: ids@iiug.org
Sent: Tuesday, June 21, 2011 1:14:21 PM
Subject: Re: is there a way to find out the physical de.... [24103]
Thanks Jim. Your pain will be everyone's gain.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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, Jun 21, 2011 at 1:06 PM, jim-cramer@uiowa.edu
<jim-cramer@uiowa.edu>wrote:
> Art, and anyone who wants to install IDS on Enterprise SuSE 11,
> please read on:
>
> The permissions and ownership of the sym links pointing to the
> logical volume device files for my IDS Chunks was not causing
> the problem and errno 2 that happened when trying to start up IDS.
>
> It turns out that I had the sym links that I created pointing at
> the sym links created by the Device Mapper feature of Enterprise
> SuSE 11. The Mapper's sym links in turn point at the actual
> device files for the Logical Volumes which live in /dev/mapper.
> Apparently this does not work. The sym links that I create
> must point directly to the device files in /dev/mapper.
>
> This probably sounds a bit nebulous and anyone installing IDS
> on a Linux system using Device Mapper should know what to do,
> so I will give an example of what I mean:
>
> For my rootdbs, I created a Logical Volume using the SuSE 11
> "Partitioner" and called it "vol01".
>
> Instead of finding the device file for it, that the LVM created,
> in /dev/<volume_group_name> with the name "vol01", I
> found it in the dir /etc/mapper with the name "<volume_group_name>-vol01".
>
> In /dev/<volume_group_name> I found a symbolic link created by
> either the LVM or Device Mapper called "vol01" that points to the
> actual device file /etc/mapper/<vol_grp_name>-vol01.
>
> 1) for my rootdbs chunk, I created the symbolic link /dev/rootdbs:
>
> ls -l /dev listing shows:
>
> lrwxrwxrwx 1 root root 26 Jun 20 15:20 rootdbs ->
> /dev/mapper/VolGrp01-vol01
>
> ls -lL /dev listing shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
> rootdbs
>
> 2) Originally, I had my link from (1) pointing straight to the device file
> shown in (3), as the
>
> "ls -l" in (1) shows. After rebooting the system and discovering that
> all of the links that
>
> I created in /dev were removed by the reboot and that the reboot had
> also undone the
>
> permissions and ownership changes that I gave the device files in (3).
>
> So, when I recreated my sym links that I use with onspaces to create the
> IDS Chunks, I was
>
> not sure what was going on so I tried pointing the links that I created
> in (1) at the links
>
> in (2), which in turn point to the device files. Note that the "ls -lL"
> listing in (1) even
>
> shows the correct permissions and ownership of the link's target which
> is accessed via a
>
> double-link hop.
>
> BUT THIS DOES NOT WORK.
>
> ls -l /dev/VolGrp01 shows:
>
> lrwxrwxrwx 1 root root 26 Jun 15 15:49 vol01 ->
> /dev/mapper/VolGrp01-vol01
>
> ls -lL /dev/VolGrp01 shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00 vol01
>
> 3) THE SYBMOLIC LINKS CREATED BY THE DBA FOR USE WITH onspaces MUST POINT
> DIRECTLY TO THESE OBJECTS:
>
> ls -l /dev/mapper shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
> VolGrp01-vol01
>
> ls -lL /dev/mapper shows:
>
> brw-rw---- 1 informix informix 253, 5 Jun 21 01:00
> VolGrp01-vol01
>
> What is really irritating is that the nowhere in the IDS 11 Information
> Center, IDS Installation
> Guide, Administrator Manuals, Release Notes for the 11.70.xC1 IDS Version,
> and Machine Notes for
> the port was there any mention or warning about symbolic links in /dev
> being
> removed &
> permissions and ownership customizations of logical volume device files
> used
> as chunks being undone
> when the system is rebooted, or how to deal with it. In fact, when I
called
> it in to Informix Tech
> Support under my contract, the engineer had apparently never heard about
> this scenario that occurs
> when installing IDS on some flavors of Linux.
>
> What is doubly annoying is that, apparently, when using IDS on Linux, the
> DBA needs to
> refer to manuals or notes in manuals that are specific for "Unix", as
> opposed to Windows,
> and there is no documentation or notes in documentation regarding
> Linux-specific issues
> such as what happened to me. Certainly there are many more Linux-specific
> instructions,
> notes, etc. that would not apply to the commercial Unix systems.
>
> Regards,
>
> Jim
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
> Kagel
> Sent: Thursday, June 16, 2011 5:59 PM
> To: ids@iiug.org
> Subject: Re: is there a way to find out the physical de.... [24068]
>
> Errno 2 is permissions (EPERM). Make sure that all of the low level chunk
> devices are informix:informix with 0660 privileges and make sure that the
> links themselves are 777 (owner of the links doesn't really matter, but I
> usually make them informix:informix also).
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 th