在sun上面启动之后 进入root用户 用fsck /dev/rdsk/c2t2d1s2 fix之后 出现这个提示fsck:operation not applicable to FSType nfs 就不能进入系统

在sun上面启动之后 进入root用户 用fsck /dev/rdsk/c2t2d1s2 fix之后 出现这个提示fsck:operation not applicable to FSType nfs 就不能进入系统
在sun上面启动之后 进入root用户 用fsck /dev/rdsk/c2t2d1s2 fix之后 出现这个提示fsck:operation not applicable to FSType nfs 就不能进入系统

在sun上面启动之后 进入root用户 用fsck /dev/rdsk/c2t2d1s2 fix之后 出现这个提示fsck:operation not applicable to FSType nfs 就不能进入系统
我曾经也有过这种问题：有很久了,最近还体验了一把：
经过分析：得出结论：
一开始可能原因有下列几种：
1、VXFS加入了log功能,在进行写操作的时候会在log日志中反映写数据的情况,在提高安全性的同时性能会有一点下降,但是不会造成下降幅度很大,这个原因可能性不大.
2、RAID 5由于要进行奇偶校验,进行写操作的时候效率不高,考虑到系统割接前同样也是RAID 5,而性能却相差很多,也可以基本排除这种可能.
3、碎片(fragmentation)对VXFS文件系统的影响比较大,UFS相对来说碎片造成的影响不是很明显.执行 /opt/VRTS/bin/fsadm -d -e ;进行碎片整理,这个过程时间很长.通过df -os可以查看VXFS文件系统的碎片信息,df -os输出意义是这样,1,2,4,8...表示不同的block size,VXFS默认block size是1K bytes,extent包括几个block,是VXFS的读写单位,free extents by size表示文件系统内不同块大小(block size)的可用空间(extents)数量.一般认为,糟糕的VXFS文件系统会有以下一个或多个特征:
(1)小于8 blocks的extent数量占全部extent的百分比超过5%
(2)小于64 blocks的extent数量占全部extent的百分比超过50%
(3)等于或大于64 blocks的extent数量占全部extent的百分比小于5%
VXFS读写时采用了比UFS大的block size,如果太多可用空间是很小的block size,就会造成寻找空间的时间加大,性能下降.
这是一台主机上几天以来在不同时间采集到的数据：
# df -os
df: operation not applicable for FSType fd
df: operation not applicable for FSType nfs
df: operation not applicable for FSType proc
df: operation not applicable for FSType tmpfs
ufs usage: df [generic options] [-o i] [directory | special]
UX:vxfs df: ERROR: bmap failure: iau inode 64 fileset 999
/m0 (/dev/vx/dsk/mail0/vol04): 49714165 blocks 0 files
Free Extents by Size
1: 230409 2: 144350 4: 137936
8: 24944 16: 4675 32: 1494
64: 712 128: 227 256: 79
512: 24 1024: 12 2048: 0
4096: 0 8192: 0 16384: 0
32768: 1 65536: 1 131072: 1
262144: 1 524288: 1 1048576: 1
2097152: 2 4194304: 0 8388608: 1
16777216: 0 33554432: 1 67108864: 0
134217728: 0 268435456: 0 536870912: 0
1073741824: 0 2147483648: 0
# date
Mon Sep 22 20:22:34 CST 2003
# df -os
df: operation not applicable for FSType fd
df: operation not applicable for FSType nfs
df: operation not applicable for FSType proc
df: operation not applicable for FSType tmpfs
ufs usage: df [generic options] [-o i] [directory | special]
UX:vxfs df: ERROR: bmap failure: iau inode 64 fileset 999
/m0 (/dev/vx/dsk/mail0/vol04): 49584410 blocks 0 files
Free Extents by Size
1: 215210 2: 127470 4: 119951
8: 50909 16: 18105 32: 6411
64: 2632 128: 699 256: 191
512: 36 1024: 16 2048: 0
4096: 0 8192: 1 16384: 0
32768: 0 65536: 1 131072: 1
262144: 0 524288: 0 1048576: 1
2097152: 2 4194304: 0 8388608: 1
16777216: 0 33554432: 1 67108864: 0
134217728: 0 268435456: 0 536870912: 0
1073741824: 0 2147483648: 0
# date
Tue Sep 23 08:58:50 CST 2003
/m0 (/dev/vx/dsk/mail0/vol04): 61925116 blocks 0 files
Free Extents by Size
1: 351822 2: 315051 4: 200420
8: 132035 16: 86031 32: 53162
64: 31470 128: 13378 256: 7061
512: 2659 1024: 915 2048: 323
4096: 44 8192: 6 16384: 0
32768: 1 65536: 1 131072: 0
262144: 0 524288: 0 1048576: 1
2097152: 2 4194304: 0 8388608: 1
16777216: 0 33554432: 1 67108864: 0
134217728: 0 268435456: 0 536870912: 0
1073741824: 0 2147483648: 0
# date
Wed Sep 24 13:32:31 CST 2003
/m0 (/dev/vx/dsk/mail0/vol04): 70733929 blocks 0 files
Free Extents by Size
1: 367139 2: 367255 4: 224724
8: 140551 16: 97633 32: 69176
64: 48438 128: 24406 256: 13992
512: 5464 1024: 1967 2048: 667
4096: 96 8192: 15 16384: 3
32768: 1 65536: 1 131072: 0
262144: 0 524288: 0 1048576: 1
2097152: 2 4194304: 0 8388608: 1
16777216: 0 33554432: 1 67108864: 0
134217728: 0 268435456: 0 536870912: 0
1073741824: 0 2147483648: 0
# date
Thu Sep 25 08:51:00 CST 2003
/m0 (/dev/vx/dsk/mail0/vol04): 70818649 blocks 0 files
Free Extents by Size
1: 218269 2: 234972 4: 154453
8: 119622 16: 89136 32: 67478
64: 50207 128: 27160 256: 14904
512: 5883 1024: 2155 2048: 674
4096: 96 8192: 17 16384: 3
32768: 1 65536: 1 131072: 0
262144: 0 524288: 0 1048576: 1
2097152: 2 4194304: 0 8388608: 1
16777216: 0 33554432: 1 67108864: 0
134217728: 0 268435456: 0 536870912: 0
1073741824: 0 2147483648: 0
# date
Fri Sep 26 08:44:17 CST 2003
/m0 (/dev/vx/dsk/mail0/vol04): 70890654 blocks 0 files
Free Extents by Size
1: 111822 2: 113660 4: 101418
8: 101504 16: 82087 32: 65544
64: 53053 128: 32133 256: 15890
512: 5914 1024: 2022 2048: 651
4096: 100 8192: 21 16384: 3
32768: 1 65536: 1 131072: 0
262144: 0 524288: 0 1048576: 1
2097152: 2 4194304: 0 8388608: 1
16777216: 0 33554432: 1 67108864: 0
134217728: 0 268435456: 0 536870912: 0
1073741824: 0 2147483648: 0
# date
Sat Sep 27 08:56:28 CST 2003
/m0 (/dev/vx/dsk/mail0/vol04): 70941186 blocks 0 files
Free Extents by Size
1: 48528 2: 47115 4: 47433
8: 55637 16: 51259 32: 45997
64: 45147 128: 31921 256: 17742
512: 7119 1024: 2568 2048: 807
4096: 167 8192: 36 16384: 6
32768: 1 65536: 2 131072: 0
262144: 0 524288: 0 1048576: 1
2097152: 2 4194304: 0 8388608: 1
16777216: 0 33554432: 1 67108864: 0
134217728: 0 268435456: 0 536870912: 0
1073741824: 0 2147483648: 0
# date
Sun Sep 28 08:51:47 CST 2003
从以上数据比较可以看出,VXFS没有进行碎片整理之前状况很差,因为割接的时候用cp命令,不会自动重新组织文件系统空间,如果采用tar的方式,会重 新组织系统空间,不会产生文件碎片,而原来割接前采用UFS,一直没有整理过,割接后大量的碎片也随文件转移到VXFS上来.进行碎片整理后,可以看出小 于8的extent所占比例在逐渐下降,而实际数据表明iowait时间也在减少,到9月28日碎片整理结束,性能恢复正常.可以用iostat查看磁盘 IO情况：
# iostat 5
tty sd6 ssd0 ssd1 ssd2 cpu
tin tout kps tps serv kps tps serv kps tps serv kps tps serv us sy wt id
0 8 0 0 0 32 3 41 1 0 8 0 0 0 4 20 44 33
0 47 0 0 0 73 2 18 1 0 10 0 0 0 2 4 2 92
0 16 0 0 0 127 17 189 2 0 4 0 0 0 2 3 3 91
0 16 0 0 0 0 0 0 0 0 0 0 0 0 2 3 0 94
0 16 0 0 0 2 1 10 0 0 0 0 0 0 1 2 2 95
0 16 0 0 0 1 0 8 0 0 0 0 0 0 1 4 1 94
0 16 0 0 0 3 1 11 0 0 0 0 0 0 2 5 1 92
0 16 0 0 0 19 4 9 2 0 5 0 0 0 6 4 4 86
主要观察CPU的几列,单位用百分比表示,us表示用户进程,sy表示系统进程,wt表示等待IO进程,id表示CPU空闲.从中可以看出,wt即等待 IO这一列百分比平均在10以下,说明很少存在等待IO的进程,id即CPU空闲时间很多,系统性能状况良好.
以下是从另一台状况良好的主机上采集的df -os数据：
/m1 (/dev/vx/dsk/mail1/vol01): 180047197 blocks 0 files
Free Extents by Size
1: 8089 2: 6190 4: 5044
8: 10213 16: 24527 32: 28672
64: 28704 128: 22789 256: 16120
512: 7480 1024: 2340 2048: 130
4096: 8 8192: 5 16384: 3
32768: 10 65536: 2 131072: 1
262144: 0 524288: 0 1048576: 1
2097152: 1 4194304: 2 8388608: 0
16777216: 1 33554432: 0 67108864: 2
134217728: 0 268435456: 0 536870912: 0
1073741824: 0 2147483648: 0
# date
Thu Sep 25 17:26:13 CST 2003
从中可以看出,小于8 block的extent比例很小,文件系统碎片很少,性能正常.
根据以上分析,可以判断IO等待时间过长是由于VXFS文件系统碎片太多引起的性能下降.
建议：每周对VXFS文件系统做一次碎片整理(Defragmentaion).