2012年1月22日 (日)

他力本願

私の仕事は成形と施釉までで、窯焚きは人まかせです。口出しできるほどの経験も無いので、手の届かないことは黙って見守りましょう。


軸ブレ作品2回目の窯出しです。

P1000398 それぞれ異なる角度に中心軸を移動して凹凸を付けましたが、立体感がチタンマット釉の質感に埋もれてしまいました。

滑り止めの効果だけはありますが。

 

P1000399 で、180°回転すると。

窯の主曰く、還元の時間が足りなかったとのことですが、釉薬の攪拌不足で成分にムラがあったのかもしれません。

 

P1000396 余計なひねりを加えた取っ手も無事に生還しました。

厚く掛けた白萩釉に黒の化粧土をのせましたが、少し流れ過ぎたようです。取っ手を流れた釉薬がその下に溜まっています。

 

P1000397 当然ながら上下で中心軸が異なりますが、丸い形のおかげで見た目によく分かりません。

もう少し細身に成形して、変化を付けるべきでした。

 

5作目は乾燥中で、現在6作目を成形中です。これは少しテーマを変えて、「座屈」です。材料の破壊試験の映像がヒントですが、結果は土だけが知っています。


P.S. 0309のファームで復活したC400は元気に稼働中です。現在の"Power On Hours"は5419時間で、発症より200時間加算されました。

| | コメント (0) | トラックバック (0)

2012年1月14日 (土)

収束宣言?

エアカウンターの示す数値は全く下がる気配を見せません。放射性物質が定着してしまったのか、放出が続いているのか私には判断できませんが。

ちなみに、eneloop liteの残量表示も下がる気配がありません。(3ヶ月目に突入)


crucialが引き起こした事象は予定よりも早く収束しそうです。先日、S.M.A.R.T.の使用時間に関する障害のために使用不能になったC400ですが、0309のファームウェアがリリースされたことで復活しました。

リリースノートによれば5184時間で発生するとありますが、私の場合は5219時間でした。サイトにあるPDFを読む限りは、前例と変わらずISOファイルから作成したCD起動で、データも保全されます。(ただし、失敗しなければ) UNetbootinを用いてUSBメモリからも更新を実行できますが、MacではDOS起動できない機種が大半なので、素直に内蔵DVDを使いましょう。

P1000393 SSDに限らずファームウェアの更新は、再起動ではなくシャットダウンしてから始めたほうが安全です。

CDから起動すると自動的にターゲットのSSDが検出されて、更新実行の確認待機となります。表示されたC400の現バージョンを確認して"yes"と入力します。

 

P1000394 10秒ほどで書き換えは完了しました。

0309と表示されて、コマンドプロンプトの入力状態となったら、電源ボタンを使ってシャットダウンします。

 

何事もなくSnow Leopardが起動しました。今回の障害の検証のために、私は2回強制終了しましたが、"fsck -fy"のチェックでも何もエラーは発生していません。デバイス停止となった際も、無反応になるアプリケーションが多発しましたがOS自体の動作は続行、iTunesのネットラジオは再生が続いていました。(ログアウトやシステム終了は不可能でしたが...)


C400_fw0309_01 更新直後のS.M.A.R.T.情報。

今回は使用時間の内部カウンターを修正しただけなので、表面上は何も変化無し。

 

C400_fw0309_02 土と格闘中に、起動したままで12時間放置。

使用時間もきっちり12時間カウントが進んでいるので、今回の呆れるようなトラブルも解消されたようです。

 

私の場合はおよそ24時間の空白で事態は収束(終息?)しましたが、これから気付かれるユーザーが大半かと思われます。メーカーおよび代理店には情報の告知を徹底して頂くように願います。


P.S. 動作検証中に成形した軸ブレ作品第五弾。

P1000395 (時間に追われて撮影失敗)

1作目のリファインで、だるま落としにも見えます。実は、削りの工程でろくろから落下して、歪みの修正に苦労しました。(完全には戻らず)

| | コメント (0) | トラックバック (0)

2012年1月12日 (木)

ロスタイム突入

ここからは未知の世界です。行く末を知るのは創造主であるcrucialのみ。


C400_5200hr 前回の記事でC400のS.M.A.R.T.の障害を報告しましたが、我が家の256GBが5200時間に到達しました。いまだ、カーネルパニックなどのトラブルは発生せず、デバイス停止の正確な時間までに誤差があると思われます。

 

今後、この記事を逐次更新しながら、発症するまでレポートを続けたいと思います。


(追記:5212時間)

C400_5212hr 依然、健在です。

"Power On Hours"のRawデータは、Macの表示時刻と正確にリンクしてカウントされています。

本当に止まるのでしょうか。


(追記:5219時間)

C400_5219hr 発症しました。ただし、カーネルパニックは起きず。

気付くとiTunesの音が止まり、Firefoxも無反応。なぜか、アクティビティモニタだけは動作中で、確認するとディスクアクセスが全く無し。メニューバーやDockは反応しますが、このままではログアウトもできないので電源ボタンによる強制終了。

S.M.A.R.T.の画像は再起動後のものです。この時間に相当するTime Machineのバックアップも確認されたので、ここで停止したのは間違いありません。


(追記:5221時間)

C400_5221hr 再起動して間もなくカウントが5220時間となり、その後約1時間で再発。再々起動後数分で5221時間となりました。

これ以上の無駄な検証は中止して、USBからLionの起動に切り替えました。

 

外付けのC300を使うことでOSは連続稼働していますが、内蔵のC400は沈黙したままです。(ディスクユーティリティからも消失)

来週に予定されたファームウェアのアップデートに期待しましょう。


(1/14追記) バージョン0309のリリースにより、約24時間の沈黙から復帰しました。詳細は後ほど新規の記事で報告します。

| | コメント (0) | トラックバック (0)

2012年1月 8日 (日)

タイムリミットまで100時間

新年のカウントダウンはJ-WAVEを聞いていましたが、今回のような事例では遠慮したいものです。

ちなみに、GROOVE LINE Zに影響され、「JADOES」のベスト盤がiTunesのライブラリに加わりました。


新年早々、事件です。年始の記事に余計なことを書いたバチが当たったのかもしれません。

crucialのフォーラムによると、C400またの名をm4のS.M.A.R.T.での使用時間が5200時間を超えるとデバイスが停止し、ブルースクリーン(Macならカーネルパニック、ただし未確認)になるそうです。シャットダウンで復帰するようですが、S.M.A.R.T.のカウントが進むごとに(1時間)再発するというので、事実上の機能停止です。

C400_limit01 で、私のC400 (256GB 0009)はいうと、すでに5100時間。ブログの神様でもいるのか、狙ったようなタイミングです。もっとも、現時点でこのような使用時間に到達するのは、初期ファーム(0001)の出荷で購入し、しかも24時間連続稼働させてしまった愚か者だけです。

発症が全数なのか一部なのか(おそらく前者)、環境依存なのか、さらに正確な時間など不明な点が多いので、私はこのまま使用を続けて、発症を見届けたらUSB接続したC300 (256GB 0007)のLionのテスト環境に一時退避することにします。

早晩に改修ファームがリリースされるそうですが、私の場合はとても間に合いそうもありません。USBで起動し、内蔵のC400はマウントを解除してアイドル時間を稼げば、なんとか使用に耐えるでしょう。


C400_limit02 一時的にLionを使うにしても、Firefoxで開いたままのタブをそのまま移行させたいので、"sessionstore.js"をコピーしました。ファイルの場所は画像を参照して下さい。

これには動作中のFirefoxのセッション情報が格納されているので、強制終了などで失われたタブの復元に使われます。

 

C400_limit03 ただし、そのままコピーしても復元出来ず、エディタで1ヶ所書き換える必要があります。

データ末尾の記述で

"state":"stopped" → "state":"running"

とします。これで強制終了されたことになるので、起動時にタブの復元の確認表示がされます。例えば、Time Mechineから起動中だった"sessionstore.js"を掘り出したときは、すでにrunningとなっていることもあるでしょう。


C400_limit04 Lionに移行すると、GUI対応のsmartctlは常駐アプリがPowerPCバイナリなので使えません。

そこで、以前に取り出したsmartctl本体(5.41)をターミナルから起動することになります。いつもはメニューバーからワンクリックなので少々面倒ですが。

 

S.M.A.R.T.の使用時間は一般的に現実の日数とは一致しないものですが、私の場合は4日ほどで結論が出ることでしょう。C400が止まったらDiablo IIはしばしおあずけです。

| | コメント (0) | トラックバック (0)

2012年1月 1日 (日)

命数尽きず

10月末に導入したエアカウンターは、いまだeneloop liteが初回の充電のみで頑張っています。同じバッテリーを使うBluetoothマウス(M-BT2BRBK)のほうが先に消耗しました。ここまで長持ちすると、むしろ過放電が心配になります。とは言っても、単4形2本なら安いので限界までチャレンジしますが。


寿命が尽きる気配すら見せない、我が家のSSD達の新年の挨拶です。

Jmon12_jan01 TS32GSSD25-M

奇跡(?)の復活を遂げたX31にて24時間営業中。Average Erase Countの増加が71、12月の平均が約70GB/dayのブロック消去です。修理以前のペースに戻りました。

50nm世代のNANDの寿命を1万回と仮定しても、ようやく人生半ばに差し掛かった頃です。

 

Jmon12_jan02 FTM28GL25H

こちらはウルトラベイ2000でXPの起動、およびバックアップ用。AECが6増加したので、平均25GB/dayのブロック消去。

実は、このSSDはAECをサバ読みしています。MacBookにて行った最初のファームアップでリセットされたので、200〜300ほど少ない数値を示しています。

 

Jmon12_jan03 C400 256GB (0009)

smartctl 5.41を使用。1fillで100GBを無駄にしたにもかかわらず、AEC (#173)の上昇は5で収まりました。Write Amplification改善の効果が大きいようです。

あと1カウントでNANDの消耗が2%となります。(3千回が100%)

 

Jmon12_jan04 C300 256GB (0007)

Lion関連のアップデートは無く、iTunesやOffice 2011などいくつかのアプリを更新しただけです。

こちらは0006時代にTRIMが消耗を加速させたおかげで、すでに2%です。(5千回が100%)

 

SSDの故障が無いのは良いことですが、それに反し我が家の本体や外付けケースの故障が頻発しました。(ストレージ交換の作業に比して損害は軽微ですが...)

さて、今年はどのような事件が起こるでしょうか。


P.S. radiko.jpにてCOUNTDOWN Z拝聴中。

| | コメント (0) | トラックバック (0)

2011年12月24日 (土)

23度26分

今回の試みは、地軸の傾きやポールシフトに関するドキュメンタリーを見ていたときの、単純な思いつきです。

先日の皆既月食は、わずかに雲に陰るだけできれいに見られました。


本焼き後の冷却が終わり、陶芸によるポールシフトの結果が出ました。

P1000392 これが第1号。

水平方向にカットして、10mmほど移動しました。見た目の変化に乏しく、2段ではなく3段にすべきだったかもしれません。

金彩釉の光沢は、今回は程よく仕上がりました。(以前はつや消しに)

 

P1000391 そして第2号。

切断面に角度を付けて、180°回転させて接合しました。心配された取っ手も無事でした。

チタンマット釉で白一色になるはずが、どう見てもカフェ・オ・レ状態に。釉薬が厚かったようで、下に流れてしまいました。偶然ですが、これも悪くないと思います。

 

P1000389 3作目は乾燥中で、これが成形4作目。

これも上下で回転軸の位置が異なります。軸の移動と逆方向に取っ手を付けました。

180°ロールさせた取っ手が乾燥中に外れないことを祈りましょう。

 

このような重心のずれた成形をすると、本焼きで歪みを生じる危険が大きくなりますが、今回は最小限に収まりました。(私の腕では円いものでも歪みますが...)

また、別の思いつきもあるので、それは来年の記事でご報告したいと思います。

| | コメント (0) | トラックバック (0)

2011年12月16日 (金)

ベンチ晴朗なれども浪高し

「本日天気晴朗ナレドモ浪高シ」

これはNHKで放映中のドラマ「坂の上の雲」の主人公である秋山真之が起草し、日本海海戦に先立ち大本営に送られた電文です。以前に紹介した「日本海大海戦」や「二百三高地」と似通った演出の場面が見受けられましたが、同じ題材の作品なのでやむを得ないでしょう。日清戦争における北洋艦隊との海戦が軽視されていた点が、個人的には不満でしたが。


月初の報告で懸念されたC400 (256GB 0009)のWrite Amplificationがさらに悪化しました。TRIMは有効ですが、Average Erase Countの上昇間隔が110GBまで降下し、WAの計算が2を超えています。そこで、劣化状況の確認と回復を図ることにしました。

C400_trim_1fill_01 C400_trim_1fill_02 まずはベンチマーク。

これには劣化の影響は見られません。逆説的ですが、通常の使用では劣化に気付かない理由でもあります。

 

C400_trim_1fill_06 50GBの空き領域にRubyスクリプトで1fillを敢行。(前回の実験で書き換え済みだったので、¥xFFのまま実行しただけです。) ちなみに、Snow Leopard標準搭載のRubyは1.8.7でした。

 

C400_trim_1fill_03 1fill開始直後の様子。2GBほどは速度が維持されていますが、その後は低下が見られます。

 

C400_trim_1fill_04 残り20GB付近。速度は1/3、波形も荒れ放題です。書き込みは遅々として進みません。

 

C400_trim_1fill_05 スクリプト終了時。

...改めて、言及することもないでしょう。

 

C400_trim_1fill_07 2回目開始。180MB/s以上で書き込みが進行しています。

 

C400_trim_1fill_08 同じく、残り20GB通過。150MB/s前後に低下しましたが、1回目とは雲泥の差です。終了時までこの速度が維持されていました。

書き込み進行が予想以上に速く、油断して終了時のスクリーンショットを逃しました。


0009のファームでは、TRIM発行だけでは回復効果が弱く、今回のような形でガベージコレクションを促す必要がありそうです。ただ、数GB分の速度は常にピーク状態に保たれているので、一般的には気にして処置することはないと思います。


(12/24追記) AECの上昇間隔が150GB(1fill分含む)、210GBと増加しました。1fillにより約100GBを犠牲にしましたが、ここまで回復すれば十分でしょう。

| | コメント (0) | トラックバック (0)

2011年12月 8日 (木)

負荷の連鎖

不幸な事故が続きます...


外付けHDDの1基が認識不能に。BUFFALOのケースの流用ですが、通電はしてもUSB接続で無反応。USBハブも疑いましたが、MacBook Pro直結でも変わらず。ケース内のHDDもスピンアップしません。幸い、先月復旧させたばかりのTime Machineには影響無いので、さっそく分解へ。(解体図はこちらに

P1000388 電源内蔵タイプなので、ユニットの基板がケース上部に見えます。(この位置だとHDDの放熱にさらされる心配も...)

10mm径のコンデンサが4個、左の列の1個が...

 

P1000387 お約束の膨張。破裂や液漏れには至らず、周囲の部品は無事なようです。先月はX31のタンタルコンデンサが壊れ、今度は電解コンデンサと悪いことは一度に襲ってきます。

HDD自体は全く健康なので(全域のクラスタチェックをしたばかり)、今回は予備のケースに移し、コンデンサ交換は部品を調達してからゆっくり行うとしましょう。

一つ謎なのは、BUFFALOの同系列のケースでもS.M.A.R.T.取得の可能なものと、そうでないものが存在します。元がHD-HC160U2だった2基のうち、片方のみが取得不可能です。今回使ったHD-HC320U2もダメでした。


続いて、陶芸のお話。ここ最近の取っ手破損率が7割に達します。

P1000385 軸ブレ作品第一弾の釉掛け完了。

冷却ファンの軸ブレは遠慮したいですが、こちらはわざと中心軸の角度を変えたり、水平方向にシフトさせたものです。無機的な質感を狙ってチタンマットと金彩釉を使いました。あとは本焼き次第です。

 

P1000386 これは、それぞれ異なった方向に軸を動かし、こてを当てて膨らみを付けました。

膨れたコンデンサに半田ごてを使うのは、また先のお話で。

| | コメント (0) | トラックバック (0)

2011年12月 1日 (木)

プチ改造

Smartctl541 MacBook Proに内蔵したSSDのS.M.A.R.T.取得には、こちらのGUIで起動可能なsmartctlを使っています。中身は本家のSmartmontoolsそのものですが、5.38と少々古いバージョンなのでバイナリを差し替えました。

Smartctl538 パッケージの中のsmartctlを本家のファイルと置き換えるだけですが、なぜかSmartmontoolsのインストールができず、smartctlを取り出せません。(私の知識不足でしょう) そこで、同じバイナリ(バージョンは5.41)を流用した他のアプリから失敬してコピーしました。

 

道具も新しくなったので、いつもの月例報告を。

Jmon11_dec01 TS32GSSD25-M X31内蔵

沈黙の1週間より復活しました。Average Erase Countの上昇がちょうど100、11月の平均は約110GB/dayのブロック消去です。

放置された分だけ減少するかと思いましたが、むしろ増えました。修理の前後で起動を繰り返した影響でしょう。

 

Jmon11_dec02 FTM28GL25H ウルトラベース X3にマウント

AECが10増加、平均40GB/dayのブロック消去。前回の報告より倍増しました。前述の再起動や修理後のバックアップ、小細工したmicroSDHC(後日報告します)の起動確認などで負担が増えました。

寿命全体から見れば、どうでもいい数字ですが。

 

Jmon11_dec03 C400 256GB (0009)

我が家の主戦力。smartctlを更新したので各IDの属性が訂正されることを期待しましたが、crucialはサポートされなかったようで、依然間違った名称が表示されます。

AEC (#173)の増加が6、10月分と変わらず。ただ、最近の上昇間隔は2回連続で130GBと、悪化傾向にあります。(以前は160〜230GB)

ファーム0009でのTRIMの限界なのか、空き容量を25GBまで追い詰めたためか、まだ確認はしていませんが劣化も進んだかもしれません。(確認しなければ気付かない程度のことです。)

 

Jmon11_dec04 C300 256GB (0007)

USBで外付けに。Lionの実験中。

X31の修理やTime Machineの復旧、その他いろいろあったおかげで、ほぼ手付かず。当然ですが、変化無し。

 

修理後のX31は元気に24時間稼働中。ただ、FTM28GL25HのXPでSecurity Essentialsの定義更新中に一度だけブルースクリーンとなりました。OpenFlashFireの弊害かもしれませんが、とくにファイル破損も見当たらず、再起動後は無事に更新も完了しました。

| | コメント (0) | トラックバック (0)

2011年11月26日 (土)

Back to the Previous

「バック・トゥ・ザ・フューチャー」に登場するデロリアン改造のタイムマシンは、完成当初の動力源がプルトニウムでした。核物質に対して無頓着な国民性を痛感させられました。

先日、10年前の「CSI:」Season 1を見たところ、凶器であった陶器の人形にウランを含む釉薬が使われていた描写がありました。私自身もそれを見た当時は気にも留めていませんでした。捜査官が過度に警戒する演出となっていましたが、時代は変わるものです。


Time Machineのイメージが検証に失敗したとお約束の警告が... AirMac Extremeのファームウェアを7.6にアップデートして以降、どうにも挙動不審です。AirMac ディスクとしてマウントしても、突然接続が解除されるようなこともしばしば。Time Machineに設定した2TBのHDDをMacBook ProにUSBで接続して調べてみると、いくつかのフォルダに読み出しのみのアクセス権が勝手に設定されていました。確信は持てませんが、ディスクの検証やS.M.A.R.T.にも異常は見られないので、ファームを戻すことにしました。

Airmac742 AirMac ユーティリティにファームのリストが残っているので、7.4.2を選択するだけです。ちなみに7.5.2は、再起動に失敗する、設定変更が保存されない、などのトラブルがあったのでパス。

 

AirMacの再起動後、2TBをマウントして次はTime Machineの再構築です。

Tm_image02 ディスクユーティリティで空のディスクイメージを作成します。

 

Tm_image03 上の名前は自分のMacのコンピュータ名、下の名前はマウントしたイメージのボリューム名です。気になる人は、Time Machineを自動作成してからコピーして下さい。

ここで容量を設定することで、Time Machineのバックアップに上限を設けることができます。私は256GBのSSD (C400 0009)に対して400GBで設定しています。

 

Tm_image01 正常なイメージから、パッケージの内容を表示してcom.apple.TimeMachine.MachineID.plistを新たなイメージにコピーします。

さらに、Info.plistの"情報を見る"から、"ロック"にチェックを入れます。これをしないと、Time Machineが勝手に容量制限を解除してしまいます。

 

このイメージをTime Machineに設定したHDDにコピーすれば終了。実際には空のイメージ(空と言いつつなぜか400MB以上もあります)を作成済みだったので、バックアップ不能になったイメージと入れ換えただけです。

今回は初回バックアップを無線LANで敢行(いつもはUSBやFireWireで直結)、220GBの転送に16時間でした。(バックアップ中も本体使用を続行)


今月はトラブル続きで疲れました。(ブログのネタには事欠きませんが...)

| | コメント (0) | トラックバック (0)

«Seven Days Repair