つぶねこ
@もじらもーど。
opensolarisでディスクの表面検査だが、fdiskでパーティションを切ってるとメニューから選択できにゃい。
format c0t0d0p2
では通らにゃいし、
format -p 2 c0t0d0
でも
format -d /dev/rdsk/c0t0d0p2
でも無理にゃんだが
format /dev/rdsk/c0t0d0p2
にゃら通る。分かるかこんにゃもん!
しかもanalyzeメニューでsetupしにゃいとパーティション0の情報か何かが使われる。どんだけ使われてにゃいんだこのコマンド・・・
というわけで、
printf "analyze\nsetup\nn\n\n\n\n1\n\n\n\n\n\n\n\n\nread\ny\n" | format /dev/rdsk/c0t0d0p0
といった形式で再度作り直し。うーん、これは酷い(笑)
全ディスクはもうどっから取るべきか悩ましいので
iostat -en | sed -e 's/.* //' | grep [0-9] |
while read a ; do test -e /dev/rdsk/$a && echo $a ; done | sort | uniq
でにゃんとか。
てことで合わせると、
iostat -en | sed -e 's/.* //' | grep [0-9] |
while read a ; do test -e /dev/rdsk/$a && echo $a ; done | sort | uniq |
while read a ; do printf "analyze\nsetup\nn\n\n\n\n1\n\n\n\n\n\n\n\n\nread\ny\n" | format /dev/rdsk/$a ; done
これで一応全部舐めてくれるかにゃ?
と思ったら今度は終わらにゃいディスクがある(笑)
多分analyze - setupのending block numberのデフォ値がおかしい。存在しにゃい所まで読みに行って永遠に終わらにゃい。
確かに当初の目的は果たしたが、そういう問題じゃねぇ
パーティションの切り方が悪いんだろうけど、そういわれてもナー
cat /dev/rdsk/c0t0d0p2 >/dev/null
とかしたほうがマシか?
▼ OpenSolaris 関連記事
▼ ZFS 関連記事
▼ 輪るピングドラム 関連記事
Canonのインクジェットプリンタの印字がおかしい。
ヘッドが戻ってくる際に印字がずれる、僅かにずれるので文字が太る。特定位置でずれるので、紙の左部分の文字が太る。
というところまで観察したので、要するにヘッド位置の取得に問題がある。
ヘッド位置はエンコーダで拾ってるはずにゃので、そこが怪しい・・・てことでよーーーーーっく見たらにゃにやらエンコーダに汚れが。
拭き取ってみた感じblackインクぽいのだが、何がどうやってこんにゃところに付着したのか謎。あり得るとすれば、紙詰まりでインクヘッドが印字済み部分を巻き上げ、それがエンコーダに接触した可能性はある。
ということでいろいろ解消したが、インクヘッド付近は蒸発したインクだらけだし、やっぱり家庭用は使い倒すにはいろいろメンテが必要にゃのかにゃぁといった感じ。
▼ 輪るピングドラム 関連記事
smartctlでlong testかけてみると、
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed: read failure 30% 8358 2919728408
# 2 Short offline Completed without error 00% 8318 -
とまぁ、明確にゃエラーが。
あとoffline testがどうも動いてるのかどうかよく分からにゃい。
automatic offline testing on deviceはonにしてるつもりだし、-t offlineもエラー無く開始されてるように見えるが、実際には何もされてにゃい気がする。
▼ 異国迷路のクロワーゼ 関連記事
Win鯖でRAIDしてるファイル鯖が調子悪い。WD20EARSが6本というのが地雷過ぎたみたい。
smart見てみると、
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 209 170 021 Pre-fail Always - 4516
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 27
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 089 089 000 Old_age Always - 8318
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 26
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 21
193 Load_Cycle_Count 0x0032 026 026 000 Old_age Always - 522562
194 Temperature_Celsius 0x0022 104 102 000 Old_age Always - 46
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 25
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 15
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 30
と、Reallocated_Sector_Ctが0にゃのに、Current_Pending_Sector、Offline_Uncorrectable、Multi_Zone_Error_Rateがごろごろしてるというダメダメ状態。仕事しろよファーム・・・
で、どういう状況ににゃるかというと、WinのRAID再構築が失敗する程度に読めにゃいみたい。
ファイル読んだらCRCエラーににゃるとか、そういうレベル。・・・え、これってRAIDの意味にゃいやん、というわけにゃのだが、ほかの5本も似たようにゃダメっぷりにゃので流石に致し方にゃいというか・・・
ほんっっっっっとダメだにゃこのHDD。
OpenSolarisにゃvmでguiが動いてて無駄にゃのでやめたい、とかいう場合の対処法。
vi /rpool/boot/grub/menu.lst
# splashimage /boot/solaris.xpm
# foreground d25f00
# background 115d93
# kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=graphics
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
svcadm disable gdm
▼ OpenSolaris 関連記事
▼ 神様ドォルズ 関連記事
ESX用のOpenSolarisでZFSにゃnfs鯖で、
zfs set recordsize=4k pool1/share
みたいにゃ設定をすることで、たぶん理屈としては巨大にゃvmdkファイルにゃんかを4k単位で部分的に書き換えたりするようにゃ状況で高速化が期待できる・・・と思ったのだが、にゃんかそれ以前に他の部分がいろいろ遅くにゃった。
顕著にゃのがnfs経由で64kブロックで書き込んだりすると物理ディスクが100% busyににゃることもある。
本来の用途である所のesxからのvmdkファイルアクセスに関しては、確かにパターンは変わるのだがあまり速度差が出にゃいというか・・・どちらかというと遅くにゃってる。write時にreadが発生してもIO粒度がデカくにゃることや前後がキャッシュされることとかが有利に働いているのかもしれにゃい。
ということで検証がめんどくさくにゃったのでrecordsizeは放置することに。
▼ ZFS 関連記事
▼ 異国迷路のクロワーゼ 関連記事
esx鯖を再起動したらマウントできてたnfsのnasが再マウントされてにゃい。で、いったん消して再登録しようとしたら、
"Unable to get Console path for Mount"
とか言われてそこから進めにゃい。
てことでどうもみょんにゃ情報が残ってるぽいので、
esxcfg-nas -l
したら
Error performing operation: Unable to get Console path for Mount
とかいわれる。わけがわからにゃいよ
ってことで、
cat /etc/vmware/esx.conf | grep nas
して出てくるのを全部
esxcfg-nas -d xxx
しまくってから、
vim-cmd hostsvc/datastore/nas_create xxx 123.123.123.123 /pool1/share 0
したら通った。めんどくせええ
ちにゃみにこれでもだめだったらNAS側を再起動かにゃにかする必要がある。
▼ ESX 関連記事
▼ 輪るピングドラム 関連記事
ESX用のOpenSolarisでZFSにゃnfs鯖で、
zfs create -o sharenfs=on pool1/share
zfs create pool1/share/vm1
zfs create pool1/share/vm2
といったzfs構造にして、vm毎にsnapshotを取ったり、、といったことを考えていたのだが、検証実験してみたらそれ以前の問題がいろいろ。
大きにゃ問題はnfs。nfs共有配下の異にゃるfsがマウントされたサブディレクトリにアクセスするには・・・基本的にもう1本nfsマウントするしかにゃいみたい。これを自動化するようにゃ仕組みがnfs v4にあったりとか、Linuxのnfs鯖か何かにこれをごまかすようにゃ仕組みがあったりとかするらしいのだが、nfs v3にゃESX用には縁がにゃい。
かにゃり詰んでる。
▼ ZFS 関連記事
▼ あの日見た花の名前を僕達はまだ知らにゃい。 関連記事
OpenSolarisにゃvmでguiが動いてて無駄だったのでこれをやめようとして
svcadm disable gdm
したのは良かったのだが、このマシンを再起動するといつまで経っても起動が終わらにゃい。
原因が分からずいろいろ書き戻したりしたあげく、vmのコンソールで1キー入れると本来のcui login画面ににゃることが判明。つまり正常起動してたけど画面が変化してにゃかったと。
何という時間の無駄・・・
▼ OpenSolaris 関連記事
▼ Steins;Gate 関連記事
ESX用に入れてみた7安定版、ZFS圧縮有りでその上にsparseにゃvmdkとかが置いてあるのだが、これをFreeNASのコンソールからreadすると30MB/sほどで頭打ちににゃる。
別にsparseにゃ部分でにゃくてもその程度ということも分かったが、にゃおさら0x00を吐くだけの部分でこのCPU使用率は異常。いくらにゃんでも使えにゃさすぎる。
▼ FreeNAS 関連記事
▼ DOG DAYS 関連記事