所帯持ちだが、心はいつも毒男であり続けるオレとしては、素直にムカつきつつも感動した。
電話をしながら2chスレに書き込んだ「めしどこかたのむ」という言葉はすばらしい。

phk@FreeBSD.orgさんにPayPalで寄付した奴の領収書がPDFで来たよ。律儀だね。
そしてこのurlが書かれていた。

実績の少ないプロトコル（AFP over TCP/IP）の限界を試すような使い方は避ける

って酷ぇなぁ。こういうのは100% Pureな「FUD」って言うんだよな。
問題なのは駄馬ッファローのLinkStation開発者のnetatalkセッティングがちょっとアレなんじゃねぇか。
AFP over TCPの限界実績だったらいくらでも有るよ。うちのスタジオは1日に4Gbyteぐらいレンダリング用の連番ファイルやら3Dシーンファイルをやり取りしてたし。ちなみにその当時のサーバーはPentium2 233MHzで3comのNICだったよ。
まるでAFP over TCPが弱いファイル転送プロトコルみたいな悪印象を平気でばら撒くのは本気で止めて欲しい。「悪いのはLinkStationのnetatalk設定」だよ。
まぁCFDグループの製品だから、smb.confでoplocks=yesとnetatalkを同居させてファイルロックの危険を考えて居なかったりとか考えられるが。今回のトラブルとは無関係かも。
※追記
なんかUNIX系じゃないところからもリンクされて誤読される可能性が出てきたので、CFDという営利企業に対する無根拠な誹謗中傷にならないように追記します。
簡単に結論だけ書くと「そういう不具合が出るのは決して商品として良いことではないが、BUFFALOだけが特に低品質だという訳でもない。(LinkStationユーザーの一人として、ずはぬけて高品質とも感じないが)。それに原因はAppleのiTuneにも有りそう」ということ。
LinkStationは兄弟製品である 「玄箱」_ を見る限りだと、PowerPC用にコンパイルしたLinux-2.4.17カーネルに Samba_ と netatalk_ をインストールしたものだと推測されます。
詳細はリンク先を参照。簡単に言うとSambaがWindowsファイル共有を。netatalkはAppleファイル共有を行っています。そして後者のnetatalkはafpovertcpというポート番号548番を使ったプロトコルで通信します。
この記事で江島健太郎さんは「AFP over TCP/IPに実績が無い」と書いています。
その後の コメント欄_ を見ると、afpovertcpだけの問題ではなくMac OS XのAFPクライアントとiTuneと、netatalkの包括的な問題である。と言いなおしています。
オレの個人的な経験から、Mac OS 9およびMac OS Xをクライアントに使ってLinuxでnetatalkで構築されたファイルサーバーを 何も調整しない で使うと、いくつかの不具合が出る可能性があることは否定しません。
たとえば過去にPhotoshopのアップデートをしたときの話です。Macでネットワークマウントされたボリュームがあると、共有ディスク先までアップデート対象の旧バージョンがあるかどうか検索で探しにいってしまい、何十分も反応が返ってこないことがありました。
親切にもマウントされている全ボリュームを検索して、アップデートする対象を指定できるようにしているがための不具合でした。(バッドノウハウとして、アップデートをするさいはネットワークマウントを解除する。という方法で対処しました)
江島氏の記事は「そんな風にユーザーが工夫しなくても、ちゃんとキャンセルできるように設計しろ」「変換の途中でキャンセルされても、ファイルシステムを壊さないように設計しろ」というリクエストが半分。そして「現状の設計では、ユーザーの行動で復旧に47万円かかるほどのダメージを与えることが意外に簡単に出来てしまう。だから万が一の為にデータは別に取っておきましょう」という主張が半分だと受け取れました。
AppleのiTuneの設計も悪い。Linuxカーネル2.4.17のext3ファイルシステムの設計も悪い。netatalkも悪……くは無いと思う。(netatalkは設定できるパラメーターがそれほど無いので、仕様とバグを把握していれば十分使えるサーバーソフトだと思う)。sambaも同じく。(ただしnetatalkとsambaを同居させてMacとWinで同時アクセスする場合はoplocks=yesに注意する必要アリ)
そしてそれらを踏まえてLinkStationのファイルシステム堅牢性と、Appleのサポート外であろうiTune使用法をした江島氏が悪い。と、思います。
江島氏の言う「AFP over TCP/IPは実績が無い」というのは、色々有る原因のうち、最も罪の無いであろうプロトコル単体を指しているので「間違っている」……いや「誤解を与える危険がある」のだとオレは考えます。
記事で書くべきは「AppleのiTuneのライブラリがネットワーク先に置かれている場合の挙動」「AFPクライアントの挙動」「LinkStationのファイルシステムの挙動」に付いてです。
afpovertcpは間に入っているだけで不具合とは無関係です。
「実績の少ないAFP over TCP/IPを使用したMac OSのネットワークマウントの限界を試すような使い方は避ける」と書かれているのが正解か?
たかが大量のファイル読み書きでファイルシステムのi-nodeまで破壊できるLinkStationの設定に問題はあるとは思いますが。欠陥品であるかといえば、それはNoだと思います。
普通のパソコンにLinuxをインストールしてnetatalkとSambaをインストールして公開したサーバーが、同様の不具合を起こすかどうかは分かりません。しかし、起きる場合も十分予想できます。
駄馬ッファローのLinkStationだけが特別にオカシイ訳ではなく、そもそもそういう不具合が有って当然のレベル。それを設定で回避するのが開発者の腕の見せ所です。
LinkStationはCPUパワーもメモリ容量もパソコンや専用サーバーより厳しいから、特に想定外の負荷で不具合が顕在化しやすいのかもしれません。
※追記終わり
あと、その後はとりあえずオレだったら。

• LinkStationからHDDを取り出す
• これDo台TWINなどがあれば新品HDDにイメージコピーする。以後コピーしたHDDでサルベージ作業をする
• Linuxをインストールするか、KNOPPIXで起動するパソコンに接続
• イメージコピーをしていない場合はhdparmでUltraDMAが有効かどうか確認してddでコピーする
• LinkStationが使っているファイルシステムは多分ext3なので、まずはfsck
• それでも多分ダメだろうからhttp://www.imasy.or.jp/~mistral/products/のsalvage-1.0を試す

と言うかんじかな。
47万円かける前にダータで出来ることはいくらでも有ります。

ミラーリング(リダンダント)とバックアップ(アーカイヴ)は違う概念:

メールマガジンのバックナンバー

立川ビックP-Kanに。
上井草T社用のHDD。

「鶏肉の間に野菜を入れている焼き鳥の呼称」のカレンダーについての打ち合わせ。
サイズが(非表示)なのに、何故か解像度指定が「400dpi程度」という曖昧かつ不必要に大きいものだった。
それは音楽出版社とかが良くやる「本当は350dpiだけど、400dpiとして発注しておけばイザと言うときに解像度不足にならないから、安全マージンとして高めに」という悪慣習だと思われた。とりあえず「原寸350dpiで作業をするつもりなので、確認を取って置いてください」と。
作画は(非表示)さんだけど、大き目の動画用紙よりも小さめに描くほうが線が綺麗に描けるということなので、A3用紙にセル分けで。
スキャン時に拡大スキャンして、その後工程では等倍350dpiに。

BフレッツとFreeBSDサーバーが設置済みなので、そこにHDDを追加して国分寺とデータのやり取りが出来るように。
筐体を開けてみたら5インチベイしか空いておらず、マウンターがないとダメっぽい。
ということで環八に出てヤマダ電気でパーツ購入。
HDDマウンターとHDD冷却ファンとIDEスリムコード。

ついでにnetatalkとdnscacheなどを設定:

飯食って送ってもらう: