パソコン・インターネット

2017/10/15

NAS boxの障害の顛末

話は今をさかのぼることちょうど5年,震災の翌年にホームサーバでも立ち上げようと思い立ち(*1),ちょうどMicrosoftからWindows Home Server 2011 (Vail)が発売されて間もなかったので,低電力のCPUをMini-ITXのマザーボードに乗せ,NAS用の高耐久性を謳って発売されたWestern DigitalのHDDであるRedを2台搭載して,小さなNAS Boxを組み上げたのでした.(*2)

このNAS boxはそれなりに順調に動き,メインPCのシステム・バックアップとユーザ領域を毎晩バックアップし,アクセスがないときはスリープして電力を節約しながらも24時間連続で稼働させていました.使い勝手も悪くなかったので,私としては後継のホームサーバ用OSが出てくるのを楽しみに待っていました.

ところが,Microsoftはコアなユーザがいたにも関わらず,Windows Home Server 2011のサポートを2016年4月に打ち切ったので,そこからハードウェアはそのままで,フリーのNAS専用OSであるFreeNASに乗り換え,複数のマシンのシステムとユーザ領域のバックアップに使ってきました.このあたりの推移は過去のこの記事に書いた通りです.

FreeNASは大規模なアップデートを企んで新しい版Corralを出そうとしたものの,完成度が低くて実使用に耐えないと判断され,開発責任者が変わり,慌ててロードマップを書き直し,現在も精力的に大規模アップデートに向けて開発が続けられています.おそらく年内には,当初目論んでいたレベルの版である11.1がリリースされるだろうと思います.

てなことを考えていたある日,FreeNASのダッシュボードに赤いアラームが点滅しているではありませんか.内容を見てみると,HDDの1台に障害が発生しているとのこと.このHDDはOSによって自動的に切り離されてしまったようです.

問題の切り分けのためにNAS boxを開け,まずはマザーボードのディスク・インターフェースの障害を疑い,空いているインターフェースに切り替えて再起動させてみました.すると何の問題もなく動くではありませんか.しばらくはこのままの構成で運用しようと思ったのですが,しばらくすると再び赤いアラームが点滅しています.HDDのセクターエラーが発生しているようです.

ここでHDDの障害であることは確実になったのですが,さりとて代替のHDDを買ってきてこの古いハードウェアを延命する気にもなれません.NAS boxの構築から5年が経っているので,どうせだったらHDDも大容量のものに替え,さらにハードウェア全体を新調して,そこにFreeNAS 11.1を載せたいところです.

しかし,最近ハードウェアは値上がり気味.特にメモリが高騰してます.しかも,FreeNASの最大のウリであるZFSというファイルシステムはメモリ食いで有名で,最低でも16GB,出来ることなら32GB程度を載せるのが良いとされているので,直ちにNAS boxを換装という決断ができません.

というわけで,古いハードウェアのうち,売れるものは売り払い,メモリをはじめとするハードウェアが少し安くなるのを待っている状態です.情けない...

どうせFreeNAS 11.1がリリースされるのは年末ころなので,その完成度具合を確かめてからでも遅くありません.それまではホームサーバが無い生活が続き,寂しい気はしますが,まぁ,こういうこともあると思うしかありません.

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

2017/07/09

Refsort/Ruby v2.70 Released

辞書参照型ソーティングフィルターをスクリプト言語 Ruby で実装した Refsort/Ruby の開発を10年以上続けています(例えば新しいほうから順に *1 *2 *3 *4 *5 *6 *7 *8 *9 *10 *11 *12 *13 *14).もう仕様は落ち着いていて機能の追加をするつもりは(ほとんど)なく,細々とバグのメンテナンスを行っている状態です.

前回のリリースはつい先週2017年7月2日だったので立て続けの改訂ですが,Refsort/Ruby の改訂版である v2.70 をリリースしました.

今回の改訂内容は2点.一つは出力様式に関するものです.Refsort では,-e オプションや -t オプションを使用した場合,入力された文字列を内部で数値型や日付時刻型に変換し,それを基準にソーティングを行っていたのですが,問題はさらに -u オプションを加えた場合,型変換後のオブジェクトを出力するという,少々恥ずかしい不適切な仕様でした.このような使い方はあまり行わないので,これまで問題が顕在化することはありませんでした.しかし,最近 -t オプションを新たに実装し,テストを繰り返すうちにこの不具合が発覚.そのため,ロジックの深いところに手を入れて,どのようなオプションを使ったとしても,出力時には入力された文字列をそのままの形で出力するようにしました.

例えば,10, 20, 50, 50+, 100, 100+, 100++ という数値が一行に一つずつ書かれている入力を考えてみます.これを -e オプションでソートすると,全ての文字列は浮動小数点型の数値 10.0, 20.0, 50.0, 50.0, 100.0, 100.0 に変換され,比較・ソートされます.これを出力するときに,-u オプションがなければ,従来の仕様でも入力行をそのまま出力するので,10, 20, 50, 50+, 100, 100+, 100++ が出力されて問題なかったのですが,-u オプションを加えると,型変換後のデータ 10.0, 20.0, 50.0, 50.0, 100.0, 100.0 が出力されてしまっていました.

今回の改訂では,-u オプションを付けたとしても,10, 20, 50, 50+, 100, 100+, 100++ が出力されるようにしたものです.日付時刻のデータにしても同様です.

もう一つの改訂内容は,これは完全に内部的なものですが,出力処理を行っている部分に論理の冗長な部分があり,速度を阻害しているように見えたので,冗長な部分を取り除きスクリプトを最適化しました.これもアルゴリズムのかなり深いところに手を入れています.はるか昔に書いた部分なので思い出すのに一苦労しました.将来のためにソースコード中にコメントを残しておきました.

このところ,-M オプション,-e オプションと -t オプションに関係する部分の不具合を直してきましたが,これで一段落付いたと思いますので,Refsort 本体の改訂は一休みできると思います.

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

2017/07/02

Refsort/Ruby v2.63 Released

辞書参照型ソーティングフィルターをスクリプト言語 Ruby で実装した Refsort/Ruby の開発を10年以上続けています(例えば新しいほうから順に *1 *2 *3 *4 *5 *6 *7 *8 *9 *10 *11 *12 *13).もう仕様は落ち着いていて機能の追加をするつもりはなく,細々とバグのメンテナンスを行っている状態です.

前回のリリースはつい先週,2017年の6月25日だったのですが,今回の修正は2点.一つは,辞書を参照しないソーティングのオプションに,文字エンコーディングそのものに基づくソーティングである -a オプションと,数値の大小に基づくソーティングである -e オプションに加えて,日付時刻に基づく新たなオプション -t を設けたことです.このオプションは,日付時刻の国際標準である ISO 8601 に準拠した文字列を日付時刻と認識して,その昇順にソートするというものです.日付はグレゴリオ暦に基づいていますので,グレゴリオ暦が制定される以前の年代については少々注意が必要ですが,基本的にどのような紀元前の年代であっても,あるいははるかな未来であっても,対応は可能なはずです.

もう一つの修正は実にマイナーなもので気付くこともないと思いますが,数値の大小に基づく -e オプションにおいて,数値が整数であれば整数型のオブジェクトである Integer として扱い,その結果として,出力するときにも整数として出力し,余分な .0 付加しない洗練されたものになっています.

日付時刻の -t オプションは,私自身これまで全く使用したことがなかったので,もう一段の最適化が必要ではないかと思っていますが,とりあえずリリースしてしまいます.

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

2017/06/25

Refsort/Ruby v2.62 Released

辞書参照型ソーティングフィルターをスクリプト言語 Ruby で実装した Refsort/Ruby の開発を10年以上続けています(例えば新しいほうから順に *1 *2 *3 *4 *5 *6 *7 *8 *9 *10 *11 *12).もう仕様は落ち着いていて機能の追加をするつもりはなく,細々とバグのメンテナンスを行っている状態です.

前回のリリースはつい最近,今年2017年の6月,長年埋もれていたバグが発覚したため,慌ててその部分だけを修正したのですが,これは埋め込みマイルストーンの機能拡張でもやろうかと思って,スクリプトをいじっているうちに発見したものです.

バグの修正後,元々やろうと思っていた埋め込みマイルストーンの機能拡張を実装して未公開版としてリリースし,さらにそのスクリプトを最適化したものを v2.62 としてリリースします.

今回の機能拡張は,2点あります.まず,辞書ファイルの埋め込みマイルストーンの書式を拡張したもので,従来はレベルを表すのに,

#!m >>>>>[....]

などと書いて,レベルが5であると示していたのですが,レベルが深くなるにつれてこの書き方では煩雑になるだけでなく,レベルの視認も難しくなるため,新たに

#!m >5 [....]

という書き方も受け入れることにしました.これがまず第1点.

第2点目は,埋め込みマイルストーンを出力する際に,新たなオプション -M を設け,マイルストーンのレベルに応じてインデントを付けるようにしました.とりあえず,インデントは 半角2文字分/レベル としていますが,ソースコード1か所の修正で簡単に変更できます.出力はこんな感じになります.

[GALLIFORMES; キジ目]

 [Phasianidae; キジ科]

   [Bambusicola; コジュケイ属] # "Gould"

    コジュケイ

[ANSERIFORMES; カモ目]

 [Anatidae; カモ科]

   [Cygnus; ハクチョウ属] # "Garsault"

    コブハクチョウ

    コハクチョウ

    オオハクチョウ

   [Anas; マガモ属] # "Linnaeus"

    オカヨシガモ

    ヨシガモ

    ヒドリガモ

    マガモ

近日中にユーザーズガイドも改訂してアップする予定です.

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

2017/06/10

Refsort/Ruby v2.52 Released

辞書参照型ソーティングフィルターをスクリプト言語 Ruby で実装した Refsort/Ruby の開発を10年以上続けています(例えば新しいほうから順に *1 *2 *3 *4 *5 *6 *7 *8 *9 *10 *11).もう仕様は落ち着いていて機能の追加をするつもりはなく,細々とバグのメンテナンスを行っている状態です.

前回のリリースはつい最近,今年2017年の4月だったのですが,埋め込みマイルストーンの機能拡張でもやろうかと思ってスクリプトをいじっているうちに,私の理解不足から正規表現にバグがあることが発覚しましたので,慌てて応急処置をとったのが今回のリリースです.

幸いなことに,私がこれまでリリースした辞書ファイルを使う限りにおいては,このバグが顕在化することはなく人畜無害なのですが,とにかく明瞭なバグなので修正版をリリースします.

どういう箇所かというと,辞書ファイルを読み込んだり最終的な出力処理を行うときに,埋め込みマイルストーンを探す必要があるのですが,このときに正規表現内でキャプチャと後方参照を使います.その後方参照を文字クラスの中でも使えると誤解していたのが間違いでした.例えば以下のような表現です.

/^(#!m\s*(\S)\2*[^\\2][^#]*)/

ここで \2 というのは (\S) でキャプチャした非空白文字をそのあとで参照するためのものなのですが,これを文字クラス [...] の中でも使えると誤解していました.これは間違いなので,以下のように修正しました.

/^(#!m\s*(\S)\2*(?!\2)\S[^#]*)/

ここで,(?!\2)\S というのがミソで,これは否定先読みという表現.詳しい説明は省きますが,\2 ではない非空白文字一文字を表現したことになり,私が意図したとおりの動作をすることを確認しました.これは Ruby のユーザーズフォーラムで質問し,ある方から親切に教えていただいたので何とか修正できた次第です.

繰り返しになりますが,機能の追加は何もなく,Ruby の最新版 v2.4.1p111 で動作することを確認しています.

また近日中にユーザーズガイドを改訂してアップする予定です.

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

2017/04/30

Refsort/Ruby 2.51 Released

辞書参照型ソーティングフィルターをスクリプト言語 Ruby で実装した Refsort/Ruby の開発を10年以上続けています(例えば新しいほうから順に *1 *2 *3 *4 *5 *6 *7 *8 *9 *10).もう仕様は落ち着いていて機能の追加をするつもりはなく,細々とバグのメンテナンスを行っている状態です.

前回のリリースは昨年2016年の7月だったのですが,今回の変更は,Windows用のRuby実行環境である Rubyinstaller の更新が滞ったことに端を発しています.この Rubyinstaller に代わって,別の作者が更新を買って出て,Rubyinstaller2 なるものをリリースし始めました.

ところが,この作者の実装はエンコーディングに癖があって,Windows なのにデフォルトの外部エンコーディング Encoding.default_external を強引に UTF-8 に決め打ちしているのです.欧州のユーザ,特に Rails の開発者にとって,エンコーディングは UTF-8 しか眼中にないらしく,他のエンコーディングを使う理由は無いでしょ!と問答無用のノートが付けられています.

しかし,これは Ruby レファレンスマニュアルの記述とは食い違いますし,これまで作成してきたスクリプトの中には動かなくなるものが出てきます.そして,現に Refsort/Ruby がそうなってしまうのです.そこで,文句を言いつつも,この実行環境でも問題なく動くように修正したものが今回の Refsort/Ruby です.

繰り返しになりますが,機能の追加は何もなく,Ruby の最新版 v2.4.1p111 で動作することを確認しています.

また近日中にユーザーズガイドを改訂してアップする予定です.

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

2016/12/30

バックアップ体制を刷新

パソコンを使っていると,ごくたまにですがHDDが突然故障したり,バックアップを取っておいたつもりのフロッピーディスクやHDDが読めなくなっていたりするものです.このときは本当に泣きたい気分になるのですが,その時に泣かずに済むようにするには,普段からバックアップを取っておくしかありません.

私の自宅のPC環境のバックアップの変遷を書くと以下のようになります.

最初期
フロッピーディスクを20枚ほど用意し,バックアップ用のユーティリティソフトウェアを使ってユーザデータのみをバックアップ.システムやアプリケーションのバックアップは取らず.これが毎週日曜日夕方のルーチンワークだった.

MO期
大容量(最初は128MB/枚,最終的には1.3GB/枚)の光磁気ディスク数枚を使って,ユーザデータのみをバックアップ.ここでもシステムやアプリケーションのバックアップは取らず.光磁気ディスクの書き込みの遅さにイライラした.

リムーバブルHDD期
最初のころは40GB程度,現在では1TB程度のリムーバブルHDDを使って,主としてユーザデータをバックアップ.可能であればシステムやアプリケーションの設定のバックアップも取る.速度の問題はなかったが,毎回USBケーブルを持ち出してつないだり外したりが億劫.これは今も続く.

試行錯誤期
様々なデバイスと接続方法を試行錯誤していた時期.最初はWindows Home Server 2011を主なバックアップ先として,システムとユーザデータをすべてバックアップ.さらに大事をとって,ユーザーデータは300GB程度のリムーバブルHDDにすべてバックアップ.

ところが,WHS 2011のサポートが2016年4月で終了したため,サーバーに使っていたマシンにFreeNASをインストールし,バックアップ用のNASとして使い始めるも,効率的な使い方は今も試行錯誤中.

さらに,内臓HDDを2台追加して,Windowsに備わっている仮想プロビジョニング対応の記憶域プールを双方向ミラーで構成し,これを自動Scrubbing対応のReFSでフォーマット.そしてこれをファイル履歴用のドライブとして運用開始.これでユーザデータを履歴も含めて自動的にバックアップ.MacOSのタイムマシン相当の機能.

さらにさらに,余っていた5インチベイに,SATA接続の2.5インチと3.5インチの2台のHDDを着脱可能なアダプタを取り付け,現在は2.5インチのHDD 1台を接続し,毎週1回,深夜に自動で全ユーザデータとアプリケーションの設定,さらにWindowsのシステムイメージをバックアップ中.

現状
上記の記憶域プールへファイル履歴を常時取得.Scrubbingも自動なので非常に楽.ただしごく稀にバックアップできないファイルがあり,万能ではない.

FreeNASへ全ユーザデータとシステムイメージを定期的に手動でバックアップ.手動なので面倒.自動化したい.

USB接続のリムーバブルHDDへ,全ユーザのデータとシステムイメージを定期的に手動でバックアップ.これも面倒なので,出来るだけ廃止したいが,非常時にサッと持ち出せるバックアップも必要なので,悩みどころ.

5インチベイに常時取り付けてあるリムーバブルHDDに,全ユーザーデータとシステムイメージを自動でバックアップ.これが上記の悩みを解決してほしいと期待している.

こうやって整理してみると,まあ,いろいろと試行錯誤してきたことがわかります.しかも,この試行錯誤はまだまだ続きます.もっと手間を省き,しかも確実にバックアップが取れるようにしたいからです.現在は,安全のためにかなり冗長なバックアップ体制を取っています.これをどこまで自動バックアップに任せても大丈夫かを検証していく必要があります.現在週末ごとに手動で行っているバックアップをできるだけ早く廃止するのが次の目標です.

現在では2.5インチのHDDも非常に安くなり,1TBが6,000円程度で買えるようになったので,USBインターフェース付きのケースに入れても8,000円でおつりがくるほどになりました.20年ほど前にフロッピーディスクをとっかえひっかえドライブに入れていた頃からは想像もできない容量をバックアップしているのですが,本質的には問題は解決していません.バックアップの悩みはコンピュータの歴史が始まると同時に発生したはずで,きっと将来も悩み続けることでしょう.

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

2016/08/17

メインマシンのバックアップ体制を刷新しました

今から2週間ちょっと前にWindowsのファイル履歴の稼働を開始したことをポストしましたが,実は,問題含みで運用を開始していました.正確には知りませんが,Windows は 8.1 の頃から新しいファイルシステム ReFS をクライアント OS にも載せるようになっていました.これは NTFS の後継ではないものの,信頼性や耐久性が要求されるサーバー OS のために開発された新しいファイルシステムで,自動修復や,ビット腐敗や書き込まれて時間が経ったセクターを自動的に書き直して鮮度を保つ機能(Scrub)など,高信頼のバックアップを求める向きには魅力的な機能を持っています.

このファイルシステムが,クライアント OS に対しても,記憶域プールであれば使用可能になっているのです.Windows 10 にアップデートした時点で早速手を出してみたのは言うまでもありません.ところが,wbadmin コマンドを用いてシステムイメージのバックアップを取ろうと思っても,ReFS への書き込みが許されていないのです.これでは一体何のためのファイルシステムなのだろう?と憤慨してみたものの,当分はそのままの仕様で運用するしかありません.

ほどなく Anniversary Update をインストールして,念のため再度確認しましたが,やはりシステムイメージを書き込むことはできません.そこで,方針を転換し,以下のようなバックアップ体制を取ることにしました.

  1. 記憶域プール(双方向ミラー)は ReFS でフォーマットし,ファイル履歴専用とする.自動修復などが可能なため,長期間の差分履歴をとるのに最も適したファイルシステムであることを生かす.
  2. システムイメージのバックアップは,NTFS でフォーマットしたリムーバブル HDD に定期的にバックアップする.
  3. ユーザのファイルも,同様にリムーバブル HDD に定期的にバックアップする.
  4. ユーザが独自にインストールしたフリーソフトなど,ローカルなアプリケーションも,同様にリムーバブル HDD に定期的にバックアップする.

そして,(2)(3)(4)はバッチファイルを組んで自動化し,それらをタスクスケジューラに登録して深夜に自動実行させる,という具合にしました.元々 (1) はバックグラウンドで自動実行されているので手間はかかりませんし,(2)-(4)も寝る前にリムーバブル HDD をスロットに突っ込んでシステムをスリープにしておけばあとは自動です.

この体制でしばらく運用してみるつもりです.ReFS については,NTFS との互換性はないので,途中で何か不都合が出てくるのかもしれませんが,まだまだ発展途上のファイルシステムなので,今後の改良も期待できると思います.

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

2016/08/15

Windows 10 をクリーンインストールし直しました

一週間ほど前に Windows 10 の Anniversary Update をインストールしたことを報告しましたが,どうも調子が悪いところが何点か見つかったので,夏休みで時間に余裕があることもあり,まっさらな状態からクリーンインストールし直しました.完全なクリーンインストールなので,種々のアプリケーションもすべてインストールし直さなければならず,非常に手間がかかる作業なのですが,アップデートでいろいろなゴミがファイルシステムの中に発生しているのは気持ち悪いし,ディスク容量もその分減るので,思い切ってやってしまいました.

一連の作業で元の環境を取り戻すにはには少なくとも丸一日,余裕を見ると2日間は必要です.そのため,部屋に閉じこもって黙々と作業を続けました.一通り完成した後でもいろいろな設定を試したりしていると時間がかかるものです.何か所か動作不審なところがあったので,とっておきのコマンド

dism /online /cleanup-image /restorehealth
sfc /scannow
を実行して修復すると,一応まともに動くようになりました.やれやれ.

インストール後に Windows Update が走ったので,ビルド番号を確認してみると,Anniversary Update 直後の 14393.10 から 14393.51 に上がっていました.へぇ?

今回のアップデートの収穫の一つは,実はコマンド・コンソールです.これまで,このコンソールのスクロールがあまりに遅くてイライラしていたのですが,今回のアップデートでは Linux のコンソールとまでは行きませんが,それに次ぐ程度に速くなりました.例えば,3万行を超えるテキストファイルをコンソールに出力させると,以前はスクロールに10秒以上もかかっていたのですが,今回のアップデート後は2秒以内で終わるようになりました.これは精神衛生上非常に好ましい変化です.派手な機能だけではなく,こういう一見地味で遺物のようなツールであっても,プログラマーにとっては重要なツールが強化されるのは大歓迎です.

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

2016/08/07

Windows 10 version 1607 build 14393.10 にアップデートしました

昨年秋の version 1511 から約10か月ぶりのアップデートで, Windows 10 が少し新しくなりました.Windows Update でダウンロードし,何度か再起動を繰り返して30分ほどで化粧直しが終わりました.

これからも Windows 10 はこのような “ちょこちょこ直し” を繰り返して変化していくことが宣言されており,まあ,これが厳密には On-Premises でありながらも SaaS (Software as a Service) に近いソフトウェアの提供形態なのでしょう.Adobe の Photoshop などはすでに数年前からこのようになっていますし,Microsoft の Office はすでに狭い意味での SaaS に移行済みですので,Microsoft の OS 系も遅ればせながらビジネスモデルを修正しつつあるということのようです.

化粧直ししたといっても,私は今回の目玉機能である Ink などを全く使っていないので,あまりご利益を感じられないのですが,しかし今後のアップデートの土台となるバージョンなので,これにしておかないわけにはいかないのです.

早速一つ不具合を発見したのですが,まだ解決策が見つかっていません.記憶域スペースに双方向ミラーのボリュームを作って,そこにファイル履歴をため込むように指定したのですが,こちらは順調のようです.

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

より以前の記事一覧