ソースの表示以前のリビジョンバックリンク全て展開する／折り畳む文書の先頭へ Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit Teams最近の変更Send via e-Mail印刷パーマリンク × 色々な電化製品の消費電力を測ってみる 激安中華DMMで電流を測って100Vを乗算しただけなので、値は皮相電力かつ参考程度に…。 Mac Pro 待機8 スリープ12 アイドル137〜138(105) Prim95312〜316(267.50) Prim95 + dd321〜325(288.25〜293.25) ProLiant MicroServer 待機3 PC（電流変動しまくり） 待機3.5 アイドル20〜30 Prime9570〜74〜79 PC低電圧 アイドル19〜24〜29 Prime9556〜61 PC FreeBSD アイドル50〜53 ubench -c69〜72〜76Ubench CPU: 1342148 ubench -m62〜64〜67Ubench MEM: 311924 bonnie59〜77|非常に目まぐるしく変化するが50〜60W台が多い| ^bonnie60〜9170後半〜80中盤を行き来する事が多い 81〜99 Technics SB-6のネットワークに使われている部品 5.60uF 8.2uF 18.0uF 50V 39uF両極性 SA102J SA152J SA331J SA561J 抵抗器（値失念） Emacsのウィンドウ自動分割機能を抑制する Emacsのウィンドウは、2つに縦分割（C-x 3を1回）した状態で使うのがデフォな私。 編集中のバッファで補完機能を使うと、候補がもう一方のバッファに現れ、入力が終われば消えて元のバッファの状態に戻るので実に使い勝手が良かった。 ところが、フォントサイズを小さくしたら、片方のバッファを更に横分割する形で候補ウィンドウが出るようになってしまった。 つまり、[ | ] の右バッファで補完呼び出しすると [-| ] な感じに分割されてしまう。そして最悪な事に横分割された左バッファは元に戻らない！これは具合がよろしくないので、自動横分割を抑制することにした。 init.elに以下の1文を付け加える。 (setq split-height-threshold nil) heightをwidthにすれば、縦分割の抑制になる。 Emacs 23.3.1で動作する事を確認。 FreeBSD 8.2-R + Marvell SATA + AHCI + ZFSはヤバいかも？ この記事は嘘、大げさ、紛らわしい情報を含んでいる可能性が多分にあります。 先日遭遇したZFSのチェックサムエラー、どうもFreeBSD 8.2-RELEASEとMarvellのSATAチップの組み合わせがヤバそうな気がする。 こんな情報も発見 → ahci(4) + zfs chksum error with Marvell SATA controller チップはちょっと違うが（うちは88SE9128、投稿は88SE9172）、8.2-RでAHCIでZFSでチェックサムエラーというのは、まさにうちと同症状。 投稿者の方に連絡を取ってみたところ、この組み合わせでもFSがUFSだと問題がなく、またSATAコントローラがIntel/AMDのものだとZFSでも問題がないとのこと。うーん、様々な要因が複合的に絡み合ってバグってるぽいなぁ……。 一方で気になるのは、この現象の報告が殆ど無い事。探し方が悪い可能性は否めないが、まとまった情報は↑の投稿くらいしかヒットしない。いやマジで。Marvellチップなんて、SATA、とりわけSATA 3.0ではかなりメジャーなチップな訳で、同症状の人がもうちょい居てもおかしくないと思うのに。 とりあえず、SATAコンを88SE9123、SATAケーブルも3.0対応を謳いシールドもしっかりしてそうなものに替え、FreeBSD 9-BETA 3で環境を再構築した。 今のところチェックサムエラーは出ていない。もっとも、まだ1週間しか経ってないので今後発生する可能性は大いにある。 現象の原因を未確定の状態で不確かな情報を流すのは躊躇われるが、FS絡みの不具合は遭遇した時の精神ダメージが半端ないため、注意喚起という意味で流したいと思う。8.2-Rでは、AHCIを有効にするとMarvellのSATAコン経由でZFS Bootが出来なくなるなど、不安定な点があるのは事実なので。 まとめ FreeBSD 8.2-RELEASE、MarvellのSATAコントローラ、AHCI、ZFSの組み合わせでチェックサムエラーが発生するっぽい。 ZFSでミラーリング構成していても全く同一のブロックでエラーになっているのか、修復は不可能。 エラー数は、（プール全体のエラー数）× 2 ＝（構成HDD1台毎のエラー数）という関係になるっぽい（多少ふらつきがある場合がある）。 cp: Input/output errorを無理やりコピーする UNIX系のOSでファイルコピーをした際cp: Input/output errorが発生することがマレにある。 ストレージの不具合や突然の電源断でファイルシステムに不整合が発生し、データの読み書きに失敗した場合に発生するエラーである。これが発生した時点コピー処理は打ち切られ、残りのデータは一切コピーされなくなってしまう。 たとえファイルの完全復元が難しいと分かってはいても、吸えるデータは可能な限り吸っておきたいのが人情というもの。残りの正常かもしれないデータをみすみす棄ててしまうのは勿体ない。動画や音声なんかだと壊れたブロックの前後が欠落するだけで、全体としてみれば実用上問題ない事が殆どだし。 そんな時はcpioコマンドで、次のようにすると無理やりコピーができる。 find . -depth -print0 | cpio --null -pvd dstdir 本来の用途はファイルストリームを単一のファイルにアーカイブする事らしいんだけど、理屈はどうあれInput/output errorに負けずにディレクトリを丸々コピー出来る。 < Newer Posts 1 2 ... 63 64 65 66 67 68 69 ... 83 84 Older Posts > start.txt 最終更新: 2022-07-27 15:26by Decomo