- Community Home
- >
- HPE Community, Taiwan
- >
- Tru64 Unix & OpenVMS
- >
- Tru64 Unix
- >
- 关于磁盘状态的疑问
類別
Company
Local Language
論壇
討論平台
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
論壇
部落格
- 訂閱此主題的RSS 提要
- 將此主題標記為未讀
- 將主題標記為已讀
- 將主題在本帳號置頂
- 標示為書籤
- 訂閱此主題
- 列印此頁
- 將文章標記為未讀
- 標示為書籤
- 訂閱此主題
- 靜音
- 訂閱此主題的RSS 提要
- 高亮顯示此文章
- 列印此文章
- 提報不當內容
在 10-15-2005 09:51 AM
在 10-15-2005 09:51 AM
关于磁盘状态的疑问
我的一台机器,操作系统为4.0F,下面有几块磁盘,盘都是好的。状态如下,请帮助我解释一下可以吗
/dev/rrz139c:character special (8/281602) SCSI #17 BD018635 disk #1112 (SCSI ID #3) (SCSI LUN #0) offline
(这个offline表示这块盘现在没有用还是没有数据读写呢?这块盘不在dg里面)
/dev/rrz16c:character special (8/32770) SCSI #2 BD018645 disk #128 (SCSI ID #0) (SCSI LUN #0)
(这个状态是否表示这块盘现在正在使用呢,或者是空闲状态,这块盘在dg里面)
/dev/rrz2c:character special (8/2050) SCSI #0 AD018323 disk #16 (SCSI ID #2) (SCSI LUN #0) errors = 12/3
(这个状态是否表示我的这块盘有问题吗?我的系统盘也是这样,但对于数据读写也没有问题呀!)
请大家有时间的时候帮助我解释一下,先谢谢了!
- 將文章標記為未讀
- 標示為書籤
- 訂閱此主題
- 靜音
- 訂閱此主題的RSS 提要
- 高亮顯示此文章
- 列印此文章
- 提報不當內容
在 10-15-2005 10:47 AM
在 10-15-2005 10:47 AM
关于磁盘状态的疑问
還能正常運作嗎???
出現offline 應該disk 已經不在了
你可以試著rescan bus again
#scu scan edt
or remove the device name ,then use MAKEDEV make the new device name
and try again
dev/rrz139c:character special (8/281602) SCSI #17 BD018635 disk #1112 (SCSI ID #3) (SCSI LUN #0) offline
*********************************
dev/rrz16c:character special (8/32770) SCSI #2 BD018645 disk #128 (SCSI ID #0) (SCSI LUN #0)
這才是正常的訊息
it mean disk is online,與是否空閑無關
假設這顆disk並沒有加入file domain,他的狀態仍是一樣
*********************************
dev/rrz2c:character special (8/2050) SCSI #0 AD018323 disk #16 (SCSI ID #2) (SCSI LUN #0) errors = 12/3
表示i/o已經出現錯誤了,建議還是換硬碟
可以由其他log 判斷是否有問題
uerr -R or syslog
- 將文章標記為未讀
- 標示為書籤
- 訂閱此主題
- 靜音
- 訂閱此主題的RSS 提要
- 高亮顯示此文章
- 列印此文章
- 提報不當內容
在 10-15-2005 10:48 AM
在 10-15-2005 10:48 AM
关于磁盘状态的疑问
是uerf -R
- 將文章標記為未讀
- 標示為書籤
- 訂閱此主題
- 靜音
- 訂閱此主題的RSS 提要
- 高亮顯示此文章
- 列印此文章
- 提報不當內容
在 10-15-2005 12:38 PM
在 10-15-2005 12:38 PM
关于磁盘状态的疑问
我刚才使用voldisk list看了一下
rz139 sliced - - offline
rz16a simple rz16a rootdg online
rz2 sliced rz2 rootdg online
其中139系统好像真没有用!rz16系统在用着的!而rz2是刚刚换上去的一块新盘,并且换了几块都是这个状态!
使用scu show edt查看换的状态为:
Device: BD018635C4 Bus: 17, Target: 3, Lun: 0, Type: Direct Access ->rz139
Device: ST318203LC Bus: 0, Target: 2, Lun: 0, Type: Direct Access ->rz2
因为rz2是属于rootdg里面的一块dm,当rz2坏后我更换rz2以
修复rootdg的状态,但出现如下错误,观察rootdg的状态如下
smp003:/dev>volrecover -sb -g rootdg
smp003:/dev>fsgen/volplex: Plex swapvol02-01 in volume swapvol02 is locked by another utility
#volprint -g rootdg -ht
v swapvol02 fsgen ENABLED ACTIVE 16776176 SELECT -
pl swapvol02-01 swapvol02 DISABLED RECOVER 16776176 CONCAT - WO
sd rz2a-01 swapvol02-01 0 0 16776176 rz2a rz2a
pl swapvol02-02 swapvol02 ENABLED ACTIVE 16776176 CONCAT - RW
sd rz18a-01 swapvol02-02 0 0 16776176 rz18a rz18a
- 將文章標記為未讀
- 標示為書籤
- 訂閱此主題
- 靜音
- 訂閱此主題的RSS 提要
- 高亮顯示此文章
- 列印此文章
- 提報不當內容
在 10-15-2005 02:30 PM
在 10-15-2005 02:30 PM
关于磁盘状态的疑问
> /dev/rrz2c:character special (8/2050) SCSI #0 AD018323 disk #16 (SCSI ID #2) (SCSI LU N #0) errors = 12/3
The number 12 is indicated a software correctable error.
The other "3" indicated a hardware error (maybe ignore if it gets from SCSI bus reset). Please analyze it via "uerf" or "dia" if DECevent had installed.
> #volprint -g rootdg -ht
>
> v swapvol02 fsgen ENABLED ACTIVE 16776176 SELECT -
> pl swapvol02-01 swapvol02 DISABLED RECOVER 16776176 CONCAT - WO
> sd rz2a-01 swapvol02-01 0 0 16776176 rz2a rz2a
> pl swapvol02-02 swapvol02 ENABLED ACTIVE 16776176 CONCAT - RW
> sd rz18a-01 swapvol02-02 0 0 16776176 rz18a rz18a
From the rz2a-1 shown a recover status within WO (write_only) that seems to process the command "volrecover" right now.
Please waiting it finish, otherwise the LSM recovery and bad disk replacement need to call HP to fix ASAP!
Best regards,
Richard.
- 將文章標記為未讀
- 標示為書籤
- 訂閱此主題
- 靜音
- 訂閱此主題的RSS 提要
- 高亮顯示此文章
- 列印此文章
- 提報不當內容
在 10-15-2005 02:32 PM
在 10-15-2005 02:32 PM
关于磁盘状态的疑问
> /dev/rrz2c:character special (8/2050) SCSI #0 AD018323 disk #16 (SCSI ID #2) (SCSI LU N #0) errors = 12/3
The error information "12/3" will be clear until system restarting.
Best regards,
Richard.
- 將文章標記為未讀
- 標示為書籤
- 訂閱此主題
- 靜音
- 訂閱此主題的RSS 提要
- 高亮顯示此文章
- 列印此文章
- 提報不當內容
在 10-15-2005 11:49 PM
在 10-15-2005 11:49 PM
关于磁盘状态的疑问
谢谢你的回复!
我在使用volrecover的时候出现如下错误:
#volrecover -sb -g rootdg
fsgen/volplex: Plex swapvol02-01 in volume swapvol02 is locked by another utility
请问这是怎么回事呢?
另外,可否再多贴一点关于磁盘报错,例如上面的error=12/3之类的信息出来吗?以供学习!
先谢谢你!
- 將文章標記為未讀
- 標示為書籤
- 訂閱此主題
- 靜音
- 訂閱此主題的RSS 提要
- 高亮顯示此文章
- 列印此文章
- 提報不當內容
在 10-18-2005 10:40 AM
在 10-18-2005 10:40 AM
关于磁盘状态的疑问
> 我在使用volrecover的时候出现如下错误:
> #volrecover -sb -g rootdg
> fsgen/volplex: Plex swapvol02-01 in volume swapvol02 is locked by another utility
The rz2 is still worked and don't run the command "volrecover". And it gets a error due to it locked by the swap usage.
PS: It needs to replace and running the command "volrecover" while it gets a "offline" or "error" from "voldisk list". Currently, please restarting this problem system and verify again.
> 可否再多贴一点关于磁盘报错,例如上面的error=12/3之类的信息出来吗?
I think this 12/3 (soft/hard) errors are a correctable on rz2.
And it should be encountered more than 15 (12+3) SCSI CAM events from "uerf -R". Please analysis this errors via command "uerf -R -o full" or "dia -R" if DECevent has installed or "wsea x trans" if it's a DS/ES40 (EV6 CPU) systems.
Best regards,
Richard.