できるものです．
範囲指定したデータの MD5 を計算して表示してくれる機能があり，ハッシュ
値計算にそのまま利用でき，作業が簡略化できました．
今回は，大変お騒がせしました．
# zfs とかだと，こうはいかないんだろうなぁ
2012年12月13日 17:07 Yoshiharu ITO yochy4...@gmail.com:
いとうといいます．
たびたびすいません．
メタデータの格納位置と構造がおおよそわかったので，時間がとれたときに
チャレンジしてみようかと思います．
が，ちょっと先になりそうですので，もしこれよりもまっとうな方法をご存知の
方がいらっ
と 3 通りあるようだ
- それを見分けるのは md_version である
- ディスクの状態を示すのは md_dflags である
- これの G_RAID3_DISK_FLAG_BROKEN が立っているのだろう
- メタデータの有効性を確認するためのハッシュ値も格納されているからメタ
データをいじったらハッシュ値も更新しておかないとダメ
2012年12月13日 13:42 Yoshiharu ITO yochy4...@gmail.com:
いとうといいます．
大変申し訳ありませんが，お知恵を拝借できないでしょうか．
当方 HDD 5 台で graid3 を運用しており
いとうといいます．
D510MO あたりをお使いでしょうか．
あまり参考にならないと思いますが，当方 BIOS で AHCI を有効にして使っています．
ahci_load=YES
8.1-RELEASE - 8.2-RELEASE 移行時にトラブルはありませんでしたよ．
下調べしていたときに，
http://lists.freebsd.org/pipermail/freebsd-stable/2011-February/061470.html
なんてのもあって，ハラハラしながら移行させましたけれども．
Copyright (c) 1992-2011 The
いとうといいます。
長文になります、すいません。
FreeBSD/amd64 7.0-RELEASE において、mpfr-2.3.1 の挙動に悩んでおります。
具体的には make check でいくつかのテストが SIGSEGV になってしまう、と
いうものです。
例として tzeta.core ファイルを読み込ませてバックトレースを見てみると、
0 番地ジャンプしているように見えます。
(gdb) bt
#0 0x in ?? ()
#1 0x000800781954 in mpfr_cache
いとうといいます。
2008年 3月 20日（木）00:06 に Yoshiharu ITO さんは書きました：
- BBWC の有無でライトパフォーマンスに差が出るようだ
- BBWC 無しでライトパフォーマンスが低い(10MB/sec 程度)のは
実力のようだ(それにしても Fast Narrow SCSI と同じくらいっ
てのはあんまりな)
ということになるでしょうか。メーカーの営業には BBWC の追加を
提案されていたのですが、そうしてみるのが良さそうだということ
が見えてきました。
メーカーの営業から 512MB
いとうといいます。
情報ありがとうございます。
当方の環境で記述が足りない部分がありましたね。
2008年 3月 18日（火）16:52 に Ei-ichi Imamura さんは書きました：
DL380G5/SA-P400モデルは標準ではリードキャッシュのみで
Writeキャッシュが無いようですが、その影響ということは無い
でしょうか。(たんなる憶測です(^^;;))
おっしゃる通り当方の P400 は BBWC は無し(256MB)になります。
DL320G5p+HP SmartArray E200/128BBWC
いとうといいます。
少々前に HP SmartArray E200 のパフォーマンスの件が話題になったと
思います。
当方では DL380 G5 + SmartArray P400 で少々困ったことになっています。
- FreeBSD/amd64 7.0-RELEASE をインストールしている
- HDD は SAS 146GB を 8 本装着している
- DISK 1 と DISK 2 で RAID 1 の論理ボリュームを
- DISK 3 〜 DISK 8 で RAID 5 の論理ボリュームを作っている
という環境下で、
- dd if=/dev/zero
