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:
>
> 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/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 -x
> > 2+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 -x
> > 1+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
> >
> >
> >
>
>
****************************************************************************
>
> > ***
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
> >
> >
>
>
****************************************************************************
> ***
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --bcaec51a7e3ed80ad604a5dc379a
>
>
>
****************************************************************************
> ***
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
****************************************************************************
***
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--bcaec501c4462c7d0804a63bfb0a
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
