Visit Our UNIX and Linux User Community


AIX dump device not showing accurate size


 
Thread Tools Search this Thread
Operating Systems AIX AIX dump device not showing accurate size
# 1  
Old 11-14-2018
AIX dump device not showing accurate size

I am trying to configure dump devices on my AIX server. Running 7100-03-04-1441. My dump device needs to be about 2GB in size. My PP Size is 1024MB, so I create the device with 2 PPs. When I run lslv on the dump device, it shows the 2 PPs, and a PP Size of 1024 megabytes. However, a dumpcheck -p shows that my dump device is only 256MB in size. dumpcheck seems to think my PP Size is only 128MB. Here you can see the output of lslv dump2lv showing the PP Size and PPs:

Code:
LOGICAL VOLUME:     dump2lv                VOLUME GROUP:   rootvg
LV IDENTIFIER:      00c1077000004b0000000166fa6a2f10.11 PERMISSION:     read/write
VG STATE:           active/complete        LV STATE:       opened/syncd
TYPE:               sysdump                WRITE VERIFY:   off
MAX LPs:            512                    PP SIZE:        1024 megabyte(s)
COPIES:             1                      SCHED POLICY:   parallel
LPs:                2                      PPs:            2
STALE PPs:          0                      BB POLICY:      non-relocatable
INTER-POLICY:       minimum                RELOCATABLE:    yes
INTRA-POLICY:       middle                 UPPER BOUND:    8
MOUNT POINT:        N/A                    LABEL:          None
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON A SEPARATE PV ?: yes
Serialize IO ?:     NO
INFINITE RETRY:     no                     PREFERRED READ: 0


And here you can see dumpcheck showing the size being only 262144 kb:

Code:
# /usr/lib/ras/dumpcheck -p
The largest dump device is too small.

Largest dump device
         dump2lv
Largest dump device size in kb
         262144
Current estimated dump size in kb
         1955880

My rootvg does show that the size used is indeed 2GB. So where is this extra space going, and why is dumpcheck not reporting all the size for my dump device?

Thanks in advance!

Moderator's Comments:
Mod Comment edit by bakunin: please use CODE-tags for data and terminal output too, thank you.

Last edited by bakunin; 11-15-2018 at 01:48 AM..
# 2  
Old 11-15-2018
Quote:
Originally Posted by paqman
I am trying to configure dump devices on my AIX server. Running 7100-03-04-1441. My dump device needs to be about 2GB in size. My PP Size is 1024MB, so I create the device with 2 PPs. When I run lslv on the dump device, it shows the 2 PPs, and a PP Size of 1024 megabytes. However, a dumpcheck -p shows that my dump device is only 256MB in size. dumpcheck seems to think my PP Size is only 128MB.

My rootvg does show that the size used is indeed 2GB. So where is this extra space going, and why is dumpcheck not reporting all the size for my dump device?
Just because you create a logical volume of type "dump" doesn't mean it is used as dump. Use the sysdumpdev to find out which dump device is actually in use. You can also use this command to find out how big the dump device has to be (-e, estimate) and to set the dump device (-Pp <device>).

On another note, you seem to have doctored with the rootvg because it is quite unusual to have a 1GB PP-size. Usual PP-sizes in rootvgs are indeed 64MB and 128MB. I don't know what exactly you did, but: might it be that this has something to do with it?

I hope this helps.

bakunin
This User Gave Thanks to bakunin For This Post:
# 3  
Old 11-15-2018
Quote:
Originally Posted by bakunin
Just because you create a logical volume of type "dump" doesn't mean it is used as dump. Use the sysdumpdev to find out which dump device is actually in use. You can also use this command to find out how big the dump device has to be (-e, estimate) and to set the dump device (-Pp <device>).

On another note, you seem to have doctored with the rootvg because it is quite unusual to have a 1GB PP-size. Usual PP-sizes in rootvgs are indeed 64MB and 128MB. I don't know what exactly you did, but: might it be that this has something to do with it?

I hope this helps.

bakunin
I figured out the problem. Yes I had already used sysdumpdev to verify that I was actually using the devices in question. The rootvg is fine, the reason it has a 1GB PP size is because the disks it was installed on are 4TB disks. So I believe it defaulted to 1GB PP size.

The problem was with the dumpcheck script. I ran it with debug on and found that it was reporting the block size for the dump device as 512 bytes. When I knew in fact that the block size was 4k. I found that it was an old version from 2010 that was missing a lot that the version on on most of our other servers were using. I copied the later version of the script, which correctly specified the block size of the dump device, and voila. So really, the dump device was fine, just the dumpcheck script was reporting the wrong size.

Thanks for your reply!
This User Gave Thanks to paqman For This Post:
# 4  
Old 11-16-2018
Quote:
Originally Posted by paqman
The rootvg is fine, the reason it has a 1GB PP size is because the disks it was installed on are 4TB disks. So I believe it defaulted to 1GB PP size.
OK, this is a valid explanation. Still, i suggest you use smaller disks for your rootvg. In my experience it is best to put only filesystems really really belonging to the system (not the application, not the data, not anything else) into the rootvg. First, when you take a system backup you back up the rootvg, aka mksysb. Guess, how long that takes on a multi-terabyte rootvg and, bonus question, how big of a size the resulting mksysb-image will be. For reference, my largest database server (700G memory, ~80TB database) has a (2x, mirrored) 120GB rootvg - and this is only because the customers insisted on swap space that will never be used. Otherwise i would have gone with our 2x60GB-standard-rootvg.

Second, modern systems are usually virtual and the disks are too. There is a big difference in moving around system disks (controlled by VIOS) and non-system disks because these can be unmounted/varyoffed easily while the system is under load. Therefore it is a good idea to separate system- and non-system-disks into seaparate VGs.

Quote:
Originally Posted by paqman
The problem was with the dumpcheck script. I ran it with debug on and found that it was reporting the block size for the dump device as 512 bytes. When I knew in fact that the block size was 4k. I found that it was an old version from 2010 that was missing a lot that the version on on most of our other servers were using. I copied the later version of the script, which correctly specified the block size of the dump device, and voila.
First off: thank you for telling us that! I perhaps never would have had that idea at all and so i (and all the others reading this thread) learned something from here too. Absolutely commendable! A word of caution too: you shouldn't just overwrite parts of the system. AIX has a great packaging system and i suggest you use it to your advantage:

- check which package the file came from with
Code:
lslpp -w </path/to/file>

then replace this package with a newer version.

- if you are interested in which else files the package contains issue
Code:
lslpp -f <packagename>

to get a list of files/directories belonging to this package.

I hope this helps.

bakunin

Last edited by bakunin; 11-16-2018 at 06:56 AM..
This User Gave Thanks to bakunin For This Post:
# 5  
Old 11-16-2018
Quote:
Originally Posted by bakunin
OK, this is a valid explanation. Still, i suggest you use smaller disks for your rootvg. In my experience it is best to put only filesystems really really belonging to the system (not the application, not the data, not anything else) into the rootvg. First, when you take a system backup you back up the rootvg, aka mksysb. Guess, how long that takes on a multi-terabyte rootvg and, bonus question, how big of a size the resulting mksysb-image will be. For reference, my largest database server (700G memory, ~80TB database) has a (2x, mirrored) 120GB rootvg - and this is only because the customers insisted on swap space that will never be used. Otherwise i would have gone with our 2x60GB-standard-rootvg.

Second, modern systems are usually virtual and the disks are too. There is a big difference in moving around system disks (controlled by VIOS) and non-system disks because these can be unmounted/varyoffed easily while the system is under load. Therefore it is a good idea to separate system- and non-system-disks into seaparate VGs.



First off: thank you for telling us that! I perhaps never would have had that idea at all and so i (and all the others reading this thread) learned something from here too. Absolutely commendable! A word of caution too: you shouldn't just overwrite parts of the system. AIX has a great packaging system and i suggest you use it to your advantage:

- check which package the file came from with
Code:
lslpp -w </path/to/file>

then replace this package with a newer version.

- if you are interested in which else files the package contains issue
Code:
lslpp -f <packagename>

to get a list of files/directories belonging to this package.

I hope this helps.

bakunin
Thanks! Yes, I agree this system should not have been installed on such large disks. There are a couple of 300GB disks in there that I think the rootvg should go on. I am new to this company and wasn't involved in installing the makesysb image. However, it is new and not in production yet, I may make the recommendation we move it to the other disks. Most of our systems do use virtual disk, however I think due to the particular function of this server they decided to install locally.

Thanks for the info about the packages, I will look into that! I have been a Unix/Linux SA for 15 years, but am very new to AIX, so I appreciate the advice.

------ Post updated at 10:06 AM ------

Just for some additional information, it looks like this problem existed on all the servers we had running AIX 7100-03-04-1441. The fileset for the dumpcheck script was bos.sysmgt.serv_aid 7.1.2.0.

Previous Thread | Next Thread
Test Your Knowledge in Computers #101
Difficulty: Easy
Linux is fundamentally a UNIX clone written from scratch by Linus Torvalds with the help of many coders across the globe.
True or False?

10 More Discussions You Might Find Interesting

1. Solaris

Showing strange size in df output

Hi, This is Solaris-10 box and in few of file-system (root file-system of non global zones), usage/available is not showing correct size. I am not able to figure out, what is eating up this space. Global Server - bdrpod01 Non Global zone - bdrpod01-zputq01 root@bdrpod01:/root# df -h... (2 Replies)
Discussion started by: solaris_1977
2 Replies

2. Solaris

dedicated crash dump device

Hello Guys, I need a little help here. I have been studying crash dump and per what I am reading, you can dedicate a slice to use as a dump device. Now when you dedicate this slice, do you have to : 1) create a mount point? 2) add entry in /etc/vfstab? 3) is this slice wu or wm? 4) should... (3 Replies)
Discussion started by: cjashu
3 Replies

3. AIX

Dump device

Hi all I have a query about dump device in aix, i asked this question on interview. what is dump device, how to add dump device & its work. kindly give this answer, thanks in advance. :confused: (1 Reply)
Discussion started by: reply.ravi
1 Replies

4. AIX

change the primary dump device of a vio server

Hi how to change the primary dump device in a vio server ? $ ioslevel 2.2.0.11-FP-24 SP-01 $ oem_setup_env # sysdumpdev -l primary /dev/sysdumpnull secondary /dev/hd6 copy directory /var/adm/ras forced copy flag TRUE always allow dump TRUE dump... (1 Reply)
Discussion started by: newtoaixos
1 Replies

5. AIX

The largest dump device is too small.

E87EF1BE 0605150011 P O dumpcheck The largest dump device is too small. bash-3.00$ errpt -aj E87EF1BE | more --------------------------------------------------------------------------- LABEL: DMPCHK_TOOSMALL IDENTIFIER: E87EF1BE Date/Time: Sun Jun 5 15:00:01... (4 Replies)
Discussion started by: thecobra151
4 Replies

6. Solaris

iSCSI disk showing incorrect size

Hi, I have a very frustrating issue! I hope you guys can assist When a disk is presented out the iSCSI target display a lower disk capacity SOLARIS VERSION is SOLARIS 10 05/09 Kernel Patch 139555-31 ISCSI Patch 119090-31, 141878-11 Unix Commands To discover Target bash-3.00# i... (0 Replies)
Discussion started by: capitalexall
0 Replies

7. Shell Programming and Scripting

Shell Script not showing accurate Time Stamp and Size

Hey guys - I have made this script and for some reason, I dont see time stamp as "Month-Day-YYYY Hours-Mins" - all i see is Month and Day. Also, my file size is approximated. For example, if the size is 19,606KB - the script shows as 20M. Is there a way to see the exact file size? How do i... (2 Replies)
Discussion started by: DallasT
2 Replies

8. AIX

The largest dump device is too small

1.what is dump device in AIX?... 2. i m getting this error message The largest dump device is too small. when i check the paging space , it is used only 41% any help welcome (4 Replies)
Discussion started by: click007
4 Replies

9. UNIX for Advanced & Expert Users

Showing Device Does Not Exist While Taking Backup

Friends, while taking backup on /dev/rmt/0cn it is showing device does not exists. I have checked /dev/rmt 0cn is present there with link file created in /devices/pci@8,700000/scsi@5/st@5,0:cn I have checked cd /devices/pci@8,700000/scsi@5 but st@5,0:cn is not there. But I found st@3,0:cn. ... (3 Replies)
Discussion started by: ailnilanjan
3 Replies

10. UNIX for Dummies Questions & Answers

core dump file size

Hi All, is there any way to find out the optimal/would be size of the cor dump file generated by the system while a process got terminated abnormally? Basically we have been asked to provide the size of the core dump file being generated by the administrators who maintained the UNIX boxes.... (4 Replies)
Discussion started by: pushp.gahlot
4 Replies

Featured Tech Videos