errpt报错（困惑中）

jlttt
errpt报错（困惑中）

机型：P570
CPU：2个
Memory：3G

errpt -a

LABEL:          DMPCHK_NOSPACE
IDENTIFIER:     F89FB899

Date/Time:       Mon Feb 25 15:00:01 BEIST 2008
Sequence Number: 676
Machine Id:      00******
Node Id:         ****
Class:           O
Type:            PEND
Resource Name:   dumpcheck      

Description
The copy directory is too small.

Probable Causes
There is not enough free space in the file system containing the copy directory to accommodate the dump.

        Recommended Actions
        Increase the size of that file system.

Detail Data
File system name
/var/adm/ras                                                                                                                    
Current free space in kb
      114520
Current estimated dump size in kb
      118169
++++++++++++++++++++++++++++++++++++=
df -k
# df -k
Filesystem    1024-blocks      Free %Used    Iused %Iused Mounted on
/dev/hd4           131072     89868   32%     1984     9% /
/dev/hd2          6291456   4700528   26%    29141     3% /usr
/dev/hd9var        131072    114516   13%      427     2% /var
/dev/hd3          6291456   5638956   11%     3335     1% /tmp
/dev/fwdump        393216    392828    1%        4     1% /var/adm/ras/platform
/dev/hd1           131072    130652    1%       16     1% /home
/proc                   -         -    -         -     -  /proc
/dev/hd10opt       131072         0  100%     2423   100% /opt
/dev/fslv01     314572800  27979792   92%    65321     2% /vg2
/dev/fslv00      66322432  12896856   81%     6449     1% /vg1
+++++++++++++++++++++++++++++++++++
我不明白是errpt报/var/adm/ras空间太小，可是没有/var/adm/ras这个文件系统啊，只有 /var/adm/ras/platform，/也没满，甚是困惑，给IBM打电话，说硬件没过保，软件过保了，不给提供服务。
小弟肯请各位兄弟帮忙分析一下。

[[i] 本帖最后由 jlttt 于 2008-2-25 16:55 编辑 [/i]]

yddll
不是说没满，就放得下

There is not enough free space in the file system containing the copy directory to accommodate the dump.

man sysdumpdev

jlttt
# sysdumpdev
primary              /dev/hd6
secondary            /dev/sysdumpnull
copy directory       /var/adm/ras
forced copy flag     TRUE
always allow dump    FALSE
dump compression     ON
#

jnwwww
copy下

不是说没满，就放得下

There is not enough free space in the file system containing the copy directory to accommodate the dump.

man sysdumpdev。

shakesky
系统要定时检测宕机时产生dump文件的大小，之后将此文件转存到/var/adm/ras下，如果空间不足它就会把这个错！
所需要的空间大小可以通过sysdumpdev -e来评估。
/dev/hd9var        131072    114516   13%      427     2% /var
把这个文件系统加大就OK了

jlttt
小弟AIX水平较浅，有点愚钝，还请yddll  给予耐心解答。

jlttt
# sysdumpdev -e
0453-041 Estimated dump size in bytes: 126038835
#

jlttt
shakesky  ，这个copy目录对应的默认文件系统是不是/var？
可我的/var
/dev/hd9var        131072    114516   13%      427     2% /var
仅仅利用了13％呢。
愿闻详解

jlttt
lsfs -q
/dev/hd9var     --         /var                   jfs2  262144  --         yes  no
  (lv size: 262144, fs size: 262144, block size: 4096, sparse files: yes, inline log: no, inline log size: 0, EAformat: v1, Quota: no, DMAPI: no)
这个lv已全部划给文件系统了，并且vg中已没有空闲空间，请问shakesky 该如何增大/var这个文件系统？

meilixueshan
你用了虽然只有13%，但是本身只有130M，就算使用率是0%也容不下dump文件
扩吧:mrgreen:

jlttt
# lslv hd9var
LOGICAL VOLUME:     hd9var                 VOLUME GROUP:   rootvg
LV IDENTIFIER:      00000107571069de.6 PERMISSION:     read/write
VG STATE:           active/complete        LV STATE:       opened/syncd
TYPE:               jfs2                   WRITE VERIFY:   off
MAX LPs:            512                    PP SIZE:        128 megabyte(s)
COPIES:             2                      SCHED POLICY:   parallel
LPs:                1                      PPs:            2
STALE PPs:          0                      BB POLICY:      relocatable
INTER-POLICY:       minimum                RELOCATABLE:    yes
INTRA-POLICY:       center                 UPPER BOUND:    32
MOUNT POINT:        /var                   LABEL:          /var
MIRROR WRITE CONSISTENCY: on/ACTIVE                              
EACH LP COPY ON A SEPARATE PV ?: yes                                    
Serialize IO ?:     NO                        
从这看这个lv是256M,是不是说明这个文件系统可以扩，
但
/dev/hd9var     --         /var                   jfs2  262144  --         yes  no
  (lv size: 262144, fs size: 262144, block size: 4096, sparse files: yes, inline log: no, inline log size: 0, EAformat: v1, Quota: no, DMAPI: no)
这里的lv size: 262144，仅为128M，怎么前后lv大小不一致？

还有个疑问，系统运行2年来都没有报过这个错误，昨天停过电，今天怎么就说空间不够了？

[[i] 本帖最后由 jlttt 于 2008-2-25 21:08 编辑 [/i]]

yanbing
我看这帖子就觉得乐，楼主居然还知道把SN ****掉，看来潜水时日不少。

有空多发发言，讨论讨论问题，仔细琢磨琢磨，别到了出了问题才说话，别的倒不怕，就是怕影响了恢复时间。

yddll
不知道你咋看出来的是256M

估计是你看到copies是2，就2×128M了吧，这个lvm的知识得补补

文件系统能不能扩，光看现在多大是不够的，还要看你有多少free的磁盘空间可以加进来

yanbing
政府机关的设备没关系的，只要正常运行不停就好了，dumpcheck有报错就让他报好了。

实在不行了把集成商的工程师喊过来搞定，，，如果楼主你自己就是集成商的工程师，那我只能建议你加强学习和交流了。

本来没空琢磨的，非要给个*****引起我兴趣，哈，sorry啦！

jlttt
版主真是厉害，居然能查到我的机器。佩服，我之所以****有2个原因：1。是还得注意保护隐私是不？2。这些信息也没有用。
我主要是搞ORACLE的，对AIX不是很熟，以后一定会加强学习，不再出来现眼了。

jlttt
不过请问yanbing，我看到这个错误的Type:            PEND
PEND－设备或组件的可用性损失是急迫的。
就是说这个问题很严重喽，‘只要正常运行不停就好了，dumpcheck有报错就让他报好了。’这句话实在不明白。
您的意思是dumpcheck报错产生的影响不大，可以忽略不计？

jlttt
yddll  ，还有一个疑问。看lv的大小难道不是PP SIZE× PPs＝128M×2＝256M？
我看见ibm的视频课程上那位老师就是这么讲的。

yanbing
别介意，只是在沉闷的PD过程中找点让人动动脑筋的事情，关于尺度你放心，绝对不会说不该说的，也绝对不会泄露任何人的机密。

看你楼上的发言，我很抱歉，本意不在于此，我一直是想鼓励大家多交流的。

也希望你能加入进来，在能做好自己本职的同时了解更多，俗话说，走四方，艺不压身的。

再别提现眼这样的字眼了，这让我感觉很不舒服，觉得自己偶尔想轻松一下论坛的气氛结果伤了人。再次抱歉！

jlttt
版主，你太多虑了，能跟你交流我已经很高兴了，呵呵～～～
我只是想明白其中的道理，解决当中的问题。这个问题解决后，我还有一个问题，待会贴出来。

yanbing
回答：

dump是指AIX中用于保留crash时系统kernal关键信息的文件。一旦发生down机同时dump成功的话，可以使用工具找到为什么会发生down机的真实原因。

dumpcheck是系统自动运行检查dump转储设备大小的功能，一旦你当前系统dump的估算大小超过了dump存储设备的大小，那么就会提示你增加dump存储设备的尺寸。

否则dump在crash之后由于没有足够的存储空间会失败掉，从而无法分析出down机的真实原因。

至于这些设备的维护标准，通常分为几种，1，只要能跑，业务不停，哪怕是有设备已经损坏都不处理；

                                      2，业务不停，系统告警，无设备损坏，但缺乏发生问题后的数据采集必要条件；

                                      3，业务不停，系统无告警，无设备损坏，软硬件微码补丁级别合适。

                                      4，业务不停，系统无告警，无设备损坏，软硬件微码补丁级别合适。performance良好且有实时监控和记录。

你这种情况只属于第2种，还算是比较好的状态，所以我说不要紧。

由于你们可能没有盘阵，建议你做好日常的DB exp备份就好。这样数据无忧就OK了。