Apple IIのハイレゾグラフィック

Woz様の回路、電車でぼけーっと考えてたら理解できたので忘れないうちにメモ。

よくある説明がこれ。柴田さんのApple II本（ブログエントリの末尾参照）より引用。VRAMから1バイトデータを取り出した時、最上位ビットが色セット切り替え、残りの7ビットで7ピクセル分の色を表現。ビットが0なら黒だけど、1だった時にはピクセルの位置によって決まった2色のうちの1色が表示される。連続して表示すると混ざって白く見えます、的な。

実はこの説明は厳密じゃなくて色は0/1のデータで表現しているわけじゃなくて、隣り合うピクセルの0→1、1→0というビットの立ち上がりと立ち下がりに反応して発色される。0か1かというのは本質的ではない。連続するビットに関しても、紫緑の場合と緑紫の場合だと色の滲み方が変わるはず。

で、原理の説明。まず色副搬送波の周波数が3.58MHz、それに対してドット・クロックが2倍の7.16MHzになっているのがミソ。適当な場所で1ピクセルだけビットが立ってる場合を考えるとドット・クロック2倍という事で色副搬送波と半周期だけ同期するパタン①と、同じく半周期だけど位相が180度ずれて同期する（値が反転している）パタン②の2種類が起きうる。ドット・クロックは2倍だけど、フリップした時に出てくる周波数成分はきっかり3.58MHz。これがそのまま色副搬送波の位相のずれとしてデコーダに検出される。

2ピクセル連続でビットが立った場合はどうかというと③と④で微妙に違う現象が起きる。③の場合は最初のビットの立ち上がりで色副搬送波と位相が一致、立ち下がりで反転。という事で連続するピクセルの左端が0度に相当する色に滲み、右端は180度に相当する色で滲む。で中間部分については色が打ち消し合ってるわけではなく、単に3.58MHzの周波数成分がほぼ0になってるため、彩度が0と判定されて白が発色される（位相差が色相、振幅が彩度に相当）。④の場合は逆で左端に180度、右端に0度の滲みがでるはず。

で、さらにApple IIでは最上位ビットを使って2つの色パレットを切り替えられる。これは14.32MHzの入ったFFを通して90度遅らせた信号を作り、遅延なしの2つの信号と合わせてセレクタに入力、最上位ビットでどちらか一方を選ぶことで実現できる。遅延付きが選ばれた場合は90度と270度、遅延無しが選ばれた場合は0度と180度の色相が取り出せるという仕組み。実際にはここで説明した位相差に加えて45度程度のずれがあり、それによって橙（45度）、紫（135度）、青（225度）、緑（315度）の4色が発色されるようです。周辺回路の遅延差がそのまま見えちゃってる感じなのかな？

という事で、本来は4割くらいの出力でカラーバースト出した上で、なだらかな輝度変化に3.58MHzに変調した色情報を載せるというのが正しいわけですが、手抜き回路では全力でカラーバースト出してやって、白黒デジタルなパタパタ出力のタイミングをちょっと前後に振ってあげるだけで独特のデジタルカラーが再現できるっぽい。これって実はマイコンでApple IIのビデオ回路を再現するのも夢じゃないって事ですね。14.32MHz-14bitのSPIが使えれば簡単に実現できる。VRAM1画面4KBって事を考えるとLPC1114あたりが適任。ビデオ専任のサブブロセッサとして任せてVRAM読み書きはメインプロセッサからI2C経由で。もしかしたらMegaZ-80Kで文字表示してたのよりタイミング的に楽かも。

Getting ARM OABI environment after such a long time :-/

Background

Unfortunately, I need to use very very old ARM OABI Linux environment to salvage data from XFS used by broken NAS. XFS is designed to be compatible between platforms, but for some reasons, it was incompatible only with ARM OABI environment. As you may know, OABI used a curious middle endian and struct layout. It's a very old story around Linux kernel 2.6.1x, or so. But, it affects my HDL-GT1.0 actually. Linux box can not show any file entries even if the disk can be mounted, and xfs_repair has no power to solve the problem.
FYI, the first KURO BOX that was sold in Japan also used ARM OABI, but later versions used ARM EABI, AFAIK.

Basic Strategy

Install debian 4.0 (etch) onto QEMU. Etch was already out of maintenance, but this is the best choice since HDL-GT1.0 looks using the Linux that was based on it. Also there is enough information to install it onto QEMU, e.g. this site (*1). Debian 5.0 (lenny) provided two versions, OABI and EABI for ARM, but the next 6.0 (squeeze) had only EABI. Anyway these all were out of maintenance. There were no benefit to choose others.

How to Install

I used Ubuntu 14.04.1 with QEMU that is installed by "apt-get install qemu". Basically, I just followed the way described at (*1). But some tricks were needed since the information was already out of date, and meanwhile, etch was removed from the official place.

Boot files

Two mandatory files distributed at (*1) were also removed. I found them from web.archive.org. I can download them, but it seems that the server sometimes return 404 against them. Anyway, if you were lucky enough, you will be able to get them.

• vmlinuz-2.6.18-6-versatile
• initrd.img-2.6.18-6-versatile

 Also, etch's initrd.gz was fetched from archive.debian.org/. The first initrd.img-2.6.18-6-versatile was used after installation, and the second initrd.gz was used on installation.

Use a manually chosen mirror site

Since etch was removed from the original place, I should specify an archive site manually. Mirror site name was archive.debian.org, and the path was default, /debian/. Here are some screen shots.

If you chosen one of default mirror sites, the installer will ask you to pick up a version of debian distributions from recent two or three choices that must use EABI.

Other Notices

In the page (*1),  that picture for the question "Continue without installing a kernel?" looks like the answer should be "<No>". But "<Yes>" is the right answer here.
Also, there is a critical issue to me. The provided kernel did not enable xfs support. So, even I install xfsprogs package and so on, xfs can not be mounted. According to the article, I can build kernel by myself. So, I'll try it next.
FYI, xfs_repair seems not working fine, but anyway it does not crash. Here, QEMU is launched with additional flags "-hdb HDL-GT-md13.img" here.

# apt-get install xfsdump  # it will install dependent xfs related packages including xfsprogs
# xfs_repair /dev/sdb  # it works somehow?

Kernel build

Let's build a kernel to support XFS. The system contains minimum set of packages. So, we need following packages to build the kernel at least. There are two choices, 2.6.18 and 2.6.24, but choose 2.6.18 that the original installation bases on.

# apt-get install make gcc linux-source-2.6.18 kernel-package build-essential libncurses5-dev initrd-tools

Then, prepare source files.

# cd /usr/src
# tar jxf linux-source-2.6.18.tar.bz2
# cd linux-source-2.6.18

Kernel 2.6.18 has a config template file for versatile. Here, we use it as a baseline, then enable XFS support in addition.

# make versatile_defconfig
# make menuconfig

In the menu, enable a following items. I'm not sure if this is the exactly necessary and sufficient condition. But at least, it is sufficient:)

• Bus support ---> PCI support [built-in]
• Device drivers ---> SCSI device support ---> SCSI device support [module]
• Device drivers ---> SCSI device support ---> SCSI disk support [module]
• Device drivers ---> SCSI device support ---> SCSI tape support [module]
• Device drivers ---> SCSI device support ---> SCSI generic support [module]
• Device drivers ---> SCSI device support ---> SCSI low-level drivers ---> SYM53C8XX Version 2 SCSI support [module]
• File systems ---> Ext3 journalling file system support [module]
• File systems ---> XFS filesystem support [module]
• File systems ---> XFS Quota support [built-in]
• File systems ---> XFS Security Level support [built-in]
• File systems ---> XFS POSIX ACL support [built-in]
• File systems ---> XFS Realtime subvolume support [built-in]
• File systems ---> Filesystems in Userspace support [module]
• File systems ---> Pseudo filesystems ---> Virtual memory file system support (former shm fs) [built-in]
• File systems ---> Pseudo filesystems ---> Tmpfs POSIX Access Control Lists [built-in]
• File systems ---> Pseudo filesystems ---> Userspace-driven configuration filesystem (EXPERIMENTAL) [module]
• File systems ---> Native language support --> Japanese charsets (Shift-JIS, EUC-JP) [module]
• File systems ---> Native language support ---> NLS UTF-8 [module]

then save and exit the menuconfig. Let's build the kernel.

# make dep
# make modules && make zImage && make modules_install && make install
# mkinitrd -o /boot/initrd-2.6.18.img 2.6.18

Now dependent modules should be installed into the internal file system, and kernel and initrd images that can be specified on launching QEMU are created. The kernel image should be placed at arch/arm/boot/zImage, and initrd image is /boot/initrd-2.6.18.img as you specified at the last command. I copied them to the host machine via scp. After shutting down the emulated ARM system, launch the system again with these new images, as

# qemu-system-arm -M versatilepb -kernel zImage -initrd initrd-2.6.18.img -hda hda.img -hdb want-to-read-fs-in-xfs.img -append "root=/dev/sda1"

The resolution of the boot console is finer than the original, and linux logo is not used. But anyway, it boots. Once you login the system, it will support XFS correctly, and it is exactly the XFS that is not compatible with current XFS. In my case, I launched QEMU with "-hdb HDL-GT-md13.img", then it can mount the image correctly.

# mount /dev/sdb /mnt
# ls -l /mnt
drwxr-xr-x 6 root  root  88 May 16  2012 share
drwxr-xr-x 6 root  root  88 May 16  2012 spool

Yep!

Lennyは新しすぎた

Etchでkernelの設定を変えて色々試してる間にLennyのイメージを見つけたので試してみた。XFSがデフォルトでオンになってたので期待したんだけど、互換性問題が修正された後のバージョンのようだ＝Etch/OABI XFSは読めなかった、という残念な日記。

https://web.archive.org/web/20130605075901/http://people.debian.org/~aurel32/qemu/arm/

web.archive.orgにLennyのARM OABIイメージが残ってた。README.txt通りに起動すればXFSが有効になったカーネルで起動できるので、-hdbでイメージを渡せば普通にマウント可能。ただ、xfs_repairとかインストールされてないので、ちょっと作業が必要。

ちなみに運が良ければ、

# mount /dev/sdb /mnt
# ls -l /mnt

でメタ情報含めて正しく見えれば勝利。駄目だったらツール使ってfile systemの修復。まずは、このままだとaptが使えないので、/etc/apt/sources.listを編集。

deb http://archive.debian.org/debian/ lenny main

を追加すればOK。

# apt-get update
# apt-get install xfsprogs

あとは程度次第だとは思うんだけど、

# xfs_repair /dev/sdb

これで駄目なら

# xfs_repair -L /dev/sdb

あたりをマウント解除した状態で実施。で、僕の場合は最初から最後まで治らず。例のページにあったように shareというディレクトリ名は出てくるけど、メタデータが壊れて見えてる状況。xfs_repairはエラーなしで綺麗に終わったんだけど。

HDL-GTはEtchらしいのでバージョン揃えて試す作業を継続してみる。こっちは配布されてたイメージでXFSがONになってないので、kernelとinitrd.imgを作り直して見てるんだけど、boot中にpanicが出て、少しずつ修正しながらもうちょいでinitが走り出しそうなとこまで来たとこ。QEMU内でのkernel buildに時間かかってTATが……。

追記：HDL-GTのkernelは2.6.12.6ベースで予想通りOABIを使用、XFSまわりのkernel configは以下の通り。

CONFIG_XFS_FS=y
CONFIG_XFS_RT=y
CONFIG_XFS_QUOTA=y
# CONFIG_XFS_SECURITY is not set
CONFIG_XFS_POSIX_ACL=y

12月の読書

12月は14冊。読み終わらなかったもの、全巻読み終えてないものとかあるけど、わりと面白い本が見つかった。ちなみに年間通算では141冊。

娯楽

Apple II本は参考になるかな、と思って読んでみたんだけど、思いの外面白かった。同僚がAppleの歴史の中で語られたりしていて、やっぱすげーなー、とか思った。

しかしWozはやっぱり凄いけど、バランス感覚はないんだろうなぁ。気持ちは凄くわかるんだけど。技術的な資料としても価値のある良い本でした。

続いて成毛さんの歌舞伎本。教養としての歌舞伎を丁寧に説明しているし、何よりも読んでいてワクワクしてくる。読み終わると同時に歌舞伎手帳とオペラグラス、そしてチケットを購入。年末に見てきましたけど面白かった。これは確かに趣味として良いかも。しかし客層に驚いた。もちろん年配の方がメインではあるんだけど、20代くらいの若者も沢山いた。クラシックコンサートなんかよりずっと活気ありますね。

教養

ファスト＆スローは認知心理学の権威による著書。
人の判断にまつわる研究の成果を詳しく記した本。ファスト＆スローと言われると脊髄反射と脳かと早とちりするけど、実際には脳を構成する２つの思考システムのこと。ファストは直感的な判断を司る自動運転プログラム群、システム１。スローはいわゆる人間的な知的決断を下すシステム２。それぞれのシステムの持つ長所と短所。問題の解決に関してそれぞれのシステムがどう関与するかが詳しく調べられている。
上巻で見られる大きな結論としては、人の脳は統計的に正しい判断を行う事が大変難しいシステムだ、という事。本質的には偏見を避けることはできず、余程の注意と教養を持ってしても是正は困難。
また、言ってみれば脳の脆弱性とも言える問題点が数多く紹介されているが、これらの弱点を突くことで印象操作や洗脳といった事がいともたやすく実践されうるし、実際マーケティングなどの分野では既に広く使われている。政治や宗教に転用されれば、戦争や虐殺にも繋がる。ある意味、核より恐ろしい研究かもしれない。
有名な平均回帰の話や、投資のプロの実力は猿以下という話も書かれていた。
しかし脳の仕組みというのは思っている以上に組織や計算機の構成法に似ている。それがこの世界の物理法則の上でやっていく最適な方法だからなのか、人の持つ先入観が計算機の設計や脳の理解に影響した結果なのかは興味深いところ。下巻は入手済みで1月に読む予定。

ギリシャ哲学の方は、哲学っていうより、ギリシア逸話集くらいの気持ちかな。結果として哲学者の話が多く出てくるってくらいで。しっかし、ソクラテスがこんなアホっぽい理由で処刑されてるとは知らなかった。巫女のお告げで一番頭の良い人間って言われて、それを信じなくて神への不遜を裁かれたのね。カッコよすぎ。あと、ドラクエIIIの巫女の元ネタってこういうとこにあったのね、とか。気軽に楽しめた一冊。

経済

資本論はGoogle Booksの安売りか何かで入手した電子書籍。マルクスの私生活の様子も含めて書かれてました。マルクスがこんなダメ人間だったとは思わなかった。働いたら負けだと思ってる、でもメイドさんは必須。そして奥さん大好きだけど、メイドさんも孕ませる。贅沢癖があって、でも同時に貧困に喘いで子供を栄養失調で亡くす。そして生涯に渡りエンゲルスにパラサイト。字が汚すぎて資本論2巻移行は本人の死後何年もかけて清書されて出版される、などなど。共産主義のイメージ変わるわー。

最後の本は半導体業界本。ところどころ筆者の私怨が見え隠れするのがマイナスポイント。素直といえば素直なんだけど。
イノベーションをただの技術革新だと勘違いしている日本の問題は同感。基本的には強い技術（シーズ）は強いマーケティングとセットにならないと機能しない。常にメリット・デメリットを併せ持つ新技術が、マーケティングの力を借りてキャズム越えを実現するのが破壊的イノベーション。
ピーターの法則については著者も独自に気づいたって点を強調してて、内容に関しては甘いな、という印象。いまや誰でも知ってることだし、その対策については色々と企業の中で実践されつつある。
成長率の話になると、少子化、高齢化問題は避けて通れない。高齢化問題に対して人道的な解を見つけるのは難しいな、とつくづく思う。特に社会の縮図として高齢化問題が濃縮された大手企業、今そこに若者が飛び込むのは自殺行為以外何者でもないな、と思わざるを得ない。大手は一度潰すのが正解なんだろうな。
あと、著者の経験談から、組織再編って局面では有能な経営者は本当に有能なんだな、と思った。けど、事業の未来を読む、という局面では、やはり誰がやってもサイコロなのかな、とも。それこそ猿より無能な一流トレーダーじゃないけど。

HDL GT（つかの間の）復旧

今後必要になる情報とも思えないけど、一応記録を。

我が家で使ってる安全なストレージは主に3種類あって

• HDL-GT（250GBx4でRAID5）：妻のデジタル原稿、家族の写真とか過去のライブ動画、あと大量の音源など。昔はこれがストレージのメインだったけど、数年前にRAID崩壊して業者に復旧してもらってからは新しいデータはほぼ置いていない。
• サーバマシン（2TBx2でRAID1）：キューブマシンにHDD詰め込みたくないしで復旧も楽なRAID1のミラー構成。サーバ上で動いてる複数のVMのイメージもこの上に置かれてる。HDL-GT復旧時のコピーもここにあるにはある。HDL-GT側をnfs serverとしてハックしてあって、autofs使ってrsyncできるようにしてあったんだけど、syncはマニュアルでごくたまに。今思えばautofsが悪さしてた可能性も。
• Google Drive：最近は写真とか勝手にクラウドにいってくれるし、データとかもドライブにぽいぽい突っ込んでる。VMイメージ置くには辛いけど、それ以外の用途ではこいつが本命。

で、HDL-GTが再びRAID崩壊を（半年ほど前に）起こして、このまま引退してもらおうと思ったら年賀状のための住所録がそこに、という話。すみなせん、今年の年賀状は例年以上に遅かった。

崩壊としてはそれほど酷い状況じゃないはずで……というのも、HDL-GTをほとんど使ってないのと、そもそも一番上のスロット1の受け側が壊れかけててディスクに異常がなくても頻繁にRAID再構成が起きてたような状況でした。今回はOSハングから強制リブートした際に、スロット1が再構成中、さらにスロット3のタイムスタンプがズレていて同期できない、というもので、おそらく物理的には破損してないはず。この辺（検討の際に色々と参考にさせてもらったページ）にディスク構成について詳しい説明がありますが、システム周りのパーティションは4台全てでミラーした4重化RAID1で、4台中3台以上が一致してないとブートしてくれなくなっちゃうという。せっかく4重化してるなら多数決で良きに計らってくれれば嬉しかったんだけど……。OSハングは具体的にはtelnetするとloginプロンプトまではいくけど、ログイン時にToo many open filesが出てbashがあがらないという状況でした。

で、目論見としてはmadamでスロット2〜4を強制的に同期させればブート可能かつデータのRAID5も再構成可能な状況になるよね、という期待。あとはバックアップしてから作業するか、適当にトライして失敗したらデータは諦めるか、なんだけど。ちょっと住所録失うのは怖かったのでバックアップする事に。3TBのディスクを1万ちょっとで購入して、作業後はサーバの定期的なバックアップに流用する事にしました（ミラーだけだと心もとないので）。

作業に使ったマシンはWindows 7と共にほぼ忘れ去られていたHP ProLiant ML115。こんなこともあろうかと、というやつですね。なぜかこういう事する人はみんな持ってる不思議なマシン。

まずはバックアップの手順。Windows 7からダウンロードしてきたUbuntu 14.04.1のイメージを焼いてパワーオフ。違いがあるかわからないけど、イメージはサーバ版を使いました。念のため。SATA1のディスクを新しい3TBのものに差し替えてDVD起動＆インストール、パワーオフ。

続けて、SATA2/3にHDL-GTのスロット1/2を追加した状態でSATA1にインストールしたUbuntuから起動。

# dd if=/dev/sdb of=/opt/backup/HDL-GT-slot1-sdd ibs=512 obs=512 conv=noerror,sync 

# dd if=/dev/sdc of=/opt/backup/HDL-GT-slot2-sda ibs=512 obs=512 conv=noerror,sync

で、終わったらSATA2/3のディスクを抜いてをスロット3/4のディスクに差し替えて

# dd if=/dev/sdd of=/opt/backup/HDL-GT-slot3-sdb ibs=512 obs=512 conv=noerror,sync 

# dd if=/dev/sde of=/opt/backup/HDL-GT-slot4-sdc ibs=512 obs=512 conv=noerror,sync

これで、うっかりしてもやり直しはきく。ちなみに各コマンドは250GBのデータをコピーしてだいたい1時間ですね。コピー元はどちらもSATA2/3を使ってるんだけど、hotplugで差し替えたらきちんと別の名前が付いてくれました。SATA1(sda)は起動に使ってるシステムのディスク。なので1回目がsdb/sdcで2回目はsdd/sdeをifで指定。ofにはHDL-GT-に続けてスロット番号-本来のデバイス名sdd/sda/sdb/sdcを指定してます。なぜかスロット2/3/4/1の順に名前が付いてたみたい。さらに、前回の崩壊からの復旧時にスロット1/2は500GBのカートリッジになってた模倣。そう言えば、在庫なかったんで500GB使いました、とか言われた気がする。当時はラッキーとか思ってたけど、今回2時間余計に時間かかっただけでメリットは何もなかった（コピー後にサイズ見て思い出した）。

で、次はRAIDの救済。ちなみにHDL-GTで検索して「RAIDの復旧」として説明しているページがいくつかあるんですが、復旧と言ってもHDL-GTを初期状態に戻してまたRAIDサーバとして使えるようにする作業の説明であって、データのサルベージではなかったりするようなので要注意です。とりあえずはHDD全部外してUbuntuのDVDから起動してお試しモードでスタート。mdadmが入ってないので

# apt-get install mdadm

でインストール。今度はSATA1-4にスロット1-4を挿します。mdadm --examineでディスク名が一致するよう、2/3/4/1の順で挿します。で、念のためにmdstatを確認……して驚く。

$ cat /proc/mdstat
Personalities : [raid1]
md5 : inactive sdd5[1](S) sdc5[3](S) sdb5[2](S)
      1590144 blocks
md10 : inactive sdd6[4](S) sdc6[3](S) sdb6[2](S)
      725768256 blocks
md1 : inactive sdd1[1](S) sdc1[3](S) sdb1[2](S)
      626304 blocks
md2 : active sdd2[1] sdc2[3] sdb2[2]
      409536 blocks

おぉ、さっそく出来上がっちゃってる！追加する順番を気にしたかったので、一度全部解除。

# mdadm --misc --stop /dev/md1
# mdadm --misc --stop /dev/md2
# mdadm --misc --stop /dev/md5
# mdadm --misc --stop /dev/md10

で、ここから比較的安定してたはずの3本を使ってRAIDを構成。

# mdadm -A --run --force /dev/md1 /dev/sda1 /dev/sdb1 /dev/sdc1
$ cat /proc/mdstat
Personalities : [raid1]
md1 : active sda1[0] sdc1[3] sdb1[2]
      208768 blocks [6/3] [U_UU__]
unused devices:

うまくいってるようなので、残りの一本も追加。

# mdadm --add /dev/md1 /dev/sdd1
$ cat /proc/mdstat
Personalities : [raid1]
md1 : active sdd1[1] sda1[0] sdc1[3] sdb1[2]
      208768 blocks [6/4] [UUUU__]
unused devices:

他のデバイスも同様に復旧。

# mdadm -A --run --force /dev/md2 /dev/sda2 /dev/sdb2 /dev/sdc2
$ cat /proc/mdstat
Personalities : [raid1]
md2 : active sda2[0] sdc2[3] sdb2[2]
      409536 blocks [6/3] [U_UU__]
md1 : active sdd1[1] sda1[0] sdc1[3] sdb1[2]
      208768 blocks [6/4] [UUUU__]
unused devices:
# mdadm --add /dev/md2 /dev/sdd2
$ cat /proc/mdstat
Personalities : [raid1]
md2 : active sdd2[6] sda2[0] sdc2[3] sdb2[2]
      409536 blocks [6/3] [U_UU__]
      [========>............] recovery = 41.5% (169984/409536) finish=0.0min speed=84992K/sec

今度は最後の一本で同期が始まったけど、この程度なら一瞬で終了。md5、md10も同様にsda5,6/sdb5,6/sdc5,6から構成して別途sdd5,6を追加、しばらく同期待ちをする事で問題なくactiveになりました。で、次が緊張の一瞬。

# mdadm -A --run /dev/md13 /dev/md10

こいつもエラーなくあっさりactiveにできました。で、ここからが問題。参考にしたサイトではこいつをxfsでマウント

# mount -t xfs /dev/md13 /somewhere

してあげれば、少なくともshareが存在することがわかる、と。あるんですが、我が家の場合はマウントするも中身は空。XFSはジャーナリングがアーキテクチャ依存なので、xfs_repair使って云々、みたいなことがあちこちで書かれてるんですが、そもそもxfs_repairかけるとxfs_repairがcrash。なんか、他の人とは根本的に違うようです。

で、結論から言うと、この段階でHDL-GTにディスクを戻せば完璧に復活しました。なのでxfsが読めなかった件は忘れるつもりでいたのですが……ここで問題発生。住所録を読み出してバックアップのrsyncをかけたら……また死亡。今度は電源が飛んで本気の死亡状態のようです。風前の灯火だったのか。

という事で、どうやらxfs問題と向き合うしかないようです。で、以下は調査と推測の入り混じった結論になるのですが、

• XFSは基本的にはプラットフォーム非依存なのだが、昔懐かしのARM OABIの環境において意図しない互換性の問題が存在していた。32-bitのmiddle endianだったり、structがpackされてたり、と癖のあるABIだったのが敗因か。
• ARM OABIからEABIの移行でXFSが飛ぶ問題があちこちで報告されている。
• HDL-GTを買ったのは2006年。まだOABIが主流だった時期。玄箱はOABI、玄箱ProはEABI。
• 推測：微妙に読めたり、xfs_repairで復旧できてる人たちはEABIに移行後の後期のHDL-GTシリーズを使っていたのではないか。
• 推測：OABI環境ならmountできるに違いない。

そんなわけで、玄箱に繋げて読もうとしたんですが、そもそもSATAポート空いてない＆玄蔵使ってUSB経由で接続すると認識されない。間に入ってるSCSI仮想レイヤあたりで3TBがうまく扱えてないのか。という事で、次は何を試そうかな、というのが昨晩くらいの状況。運のいい人にとってはここまでの情報でも役に立つかもしれないので、ひとまずpublish。