2013/08/17
KAICHO: s_naray[at]yahoo[dot]co[dot]jp
※SPAM防止中
ケイジバン

HDL2-A4.0で遊ぶ

■はじめに

本書では、I-O DATAの NAS「HDL2-A4.0」の情報を細々と掲載する。ここでは 基本的にRAID1(ミラーリング)構成 のみを対象とし、RAID0などその他のモードは試していないことに注意。ちうか その他の構成で使ってる人居るのかしらん。怖くてRAID1以外は使えんわ! ファームウェアは1.07で確認している。

購入のキッカケは、なんとなくNASが欲しくなったこと。 ShuttleのKD21と 散々悩んだんだけど、購入決定時にKD21は発売まであと一週間あったこと、KD20の 時にShuttleはファームウェア周りで色々やらかしてくれてるのを鑑み、安定動作こそ我が命! ということで、既に枯れ枯れに枯れちゃってるはず(※発売日は2011/10)の コレを選択したわけで。最新ファームウェアのリリース日が2013/07/31というごく最近なのも、 「長いことサポートしまっせダンナ」的な姿勢が見えて好印象。ついでに、2.0TBの ハードディスクx2付属でAmaz○nで22500円とかで入手できるのもお買い得感高い。 前面USBが2.0なのはちょっとマイナス評価だが、それが何だというのだ! もうコレしかない!…というような頭悪い葛藤があって、入手したのですよ HDL2-A4.0を。I-O DATAさんありがとう!なんか楽しいよコレ!

なお、本ページは我輩所有のHDL2-A4.0についてのみ述べていて、HDL2-A2.0とか HDL2-A6.0とかは対象外なので注意。HDD容量以外は全部同じだろうけれど。

■おやくそく

このページの情報は一切無保証で、誤っている可能性もあることを 先に了承すること。このページを見て操作した挙句、アナタに何か不利益な ことが起こったとしても、我輩は一切それに関知しない。何もかも自己責任だし、 I-O DATAの保証の範囲を超える可能性が極めて高いので注意。 何かあったときに間違っても(我輩はもとより)I-O DATAにご迷惑をかけないこと! 我々ユーザはメーカーの手のひらの上で踊る卑しい哀れな孫悟空だと自認し、 孫悟空は孫悟空らしく、世界のすみっこでちっちゃく楽しむのが吉。

■内部情報

●概要

本機は、ARM Linux(kernel-2.6ベース)を採用している。恐ろしいことに、 内部にフラッシュメモリなどのOS起動用の領域は存在しない。 OS起動領域は全てHDD上に格納されており、従って、二つのHDDが両方破損した場合、 これを復旧する手段は無い。実に男らしい。 I-O DATAに元のHDDごと送れば、実費で交換してくれることはあるらしい。 だけど、面倒だし結構お金かかるしI-O DATAにもお手間取らせてしまうので、 ユーザの皆様におかれましては、両方破損しないようにご注意を。 後述する方法で、予めシステム部分のバックアップをとっておくもよし。

なお、HDDが片方だけ破損しても、OS領域はミラーリングされているので 復旧は可能(ただしRAID0の場合はデータ部分は消えてなくなる)。

ちなみに、初期状態(RAID1でフォーマット)でのCrystalDiskMarkの結果はこんな。 安物HUB経由してるのに頑張ってるじゃぁないの。さすが高速を謳うだけある! (100MB/sは言いすぎな気がするけど)。

…ところで、起動に三分もかかるのはどうにかなりませんかのぅ。 Embeded Linuxで三分て。

●起動時情報

ここの 61〜の情報によると、以下みたい。

そっか、Debianかー…。我輩あんま使ってないんだよなー…。 コンパイルした人がsekiya@devsrvとなっているということは、これは自前でコンパイル して作ったということだろう。ニホンジンっぽいお名前が見えてなんか嬉しい。

●ディスク構成概要

HDL2-A4.0の初期状態では、ディスクのパーティションは以下のように構成されていた。 最初からGPTとは剛毅なことよ!(3TB HDDモデルがあるから当然か)。 ちなみに、RAID0でもRAID1でもこの構成は同じだし、左右のHDDいずれも同じ状態 (後述するが、中身は左右でほんの少し違うみたい)。 RAID0/RAID1の切り替え時には、/dev/sda6だけをLinuxのSoftraid(MD...Multiple DisksのRAID0 or RAID1)でストライピング・ミラーリング構成する。

# parted -s /dev/sda print
Model: ATA ST2000DM001-1CH1 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      20.5kB  537MB   537MB   ext3         primary       
 2      537MB   1611MB  1074MB               primary       
 3      1611MB  3758MB  2147MB  linux-swap   primary       
 4      3758MB  3892MB  134MB                primary       
 5      3892MB  4429MB  537MB                primary       
 6      4429MB  2000GB  1996GB               primary       

セクタ単位で表示するとこんなカンジ。この方が正確にわかるよね。4KB/Sectorの 場合どうなるのかなぁと思ってたけど、スタートセクタは全て8で割り切れるので、 ちゃんと4KB/SectorのHDDにもコピーできそうな予感。

# parted -s /dev/sda u s print
Model: ATA ST2000DM001-1CH1 (scsi)
Disk /dev/sda: 3907029167s
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start     End          Size         File system  Name     Flags
 1      40s       1048623s     1048584s     ext3         primary       
 2      1048624s  3145783s     2097160s                  primary       
 3      3145784s  7340095s     4194312s     linux-swap   primary       
 4      7340096s  7602247s     262152s                   primary       
 5      7602248s  8650831s     1048584s                  primary       
 6      8650832s  3907029127s  3898378296s               primary     

このうち、先頭から5個目までのパーティションには、HDL2-Aが起動するために必要な システム(ARM Linux本体)が入っているので、変更してはならない。最後の でっかいパーティションがデータ用のもの。

●ディレクトリ構成

フォーマット直後、6番目のデータパーティションを別のLinuxシステム上で /mnt/hddにmountして、 ls-alR /mnt/hdd した時の実行結果をこちらに。 結構単純。

●ディスク構成詳細...データパーティション

上で述べたように、データパーティションは6番目のでっかいパーティション。 ここは、LinuxのSoftwareRAID(md ... Linux Multi-Disk)でRAID0またはRAID1を 構成した上でxfsでフォーマットされている。このmd+xfsという構成に注意。 単純にxfsだけではなくmdが間に挟まっているのが曲者。なんか別のLinuxで mdなしでxfsフォーマットして使おうとすると、「このディスク壊れてるー!」といって HDL2-A自体がエラー吐いて起動を停止するという。そこまでしなくてもいいやん…。

具体的には、md version 0.90が利用されており、パーティション末尾にこんな データがある(xxはUUIDなので削除)。

# dd if=/dev/sda bs=512 skip=$((3907029128-128*(1024/512))) | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00009000  fc 4e 2b a9 00 00 00 00  5a 00 00 00 00 00 00 00  |.N+.....Z.......|
00009010  00 00 00 00 xx xx xx xx  88 a0 08 52 01 00 00 00  |...........R....|
00009020  c0 43 2e 74 02 00 00 00  02 00 00 00 06 00 00 00  |.C.t............|
00009030  00 00 00 00 xx xx xx xx  xx xx xx xx xx xx xx xx  |................|
00009040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
(snip)

あー、この"fc 4e 2b a9"って並び、見たことあるわー、と思った人は結構なLinux 使い。これは、mdのマジックナンバーなのでした。これが発見できたので、 6番目のファイルシステムはmd version 0.90でフォーマットされていることが 確定した。詳細知りたい人は RAID superblock formats参照。ここはホントよく書いてあって助かる。

このmdマジックナンバーは「パーティション末尾」に存在する。ということは、 パーティション先頭からは実はxfsでそのままフォーマットされているということ。 従って、RAID1の場合、mdを間に挟まなくても、このパーティションは外部Linuxで そのままxfsとしてmount可能。データサルベージの時は何も考えずにmountできるので とても楽。

この領域のxfs_infoの結果を以下に示す。agcountあたり、 性能を期待してか小さく設定されてるようだけど、それ以外はまぁ…普通かな。

# xfs_info /xfs-mntpoint
meta-data=/dev/sdb6              isize=256    agcount=4, agsize=121824316 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=487297264, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=32768, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0

あとはおまけ、この領域のmdadm --detailの結果も以下に。 一個だけで使ったからdegradedになってるけどまぁ参考までに。

/dev/md0:
        Version : 0.90
  Creation Time : Mon Aug 12 17:44:56 2013
     Raid Level : raid1
     Array Size : 1949189056 (1858.89 GiB 1995.97 GB)
  Used Dev Size : 1949189056 (1858.89 GiB 1995.97 GB)
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Wed Aug 21 20:02:20 2013
          State : clean, degraded 
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           UUID : xxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx
         Events : 0.22

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8       22        1      active sync   /dev/sdb6

●システム部分のバックアップ方法

上にpartedの出力があるので、判る人にはすぐわかる、HDL2-Aシステムのバックアップ 方法。単体だと無理なので、HDDを引っこ抜いて何かLinuxマシンに接続して、 システム部分(5番目のパーティションまで)をddで読み出せばよい。 HDL2-Aのディスクが/dev/sda、バックアップ先を/mnt/backup/HDL2-A40-system.img だとすると、以下のようなコマンドでバックアップ可能。非圧縮で4.2GB。 bzip2を使うのは単なる趣味。これで800MB程度(ファームウェア1.07の場合。1.05だと 550MB程度だった)の大きさのファイルが出来た。

# dd if=/dev/sda bs=512 count=8650832 | bzip2 -c > /mnt/backup/HDL2-A40-system.img.bz2

あとは、mdのメタデータも一応バックアップしておこう。md 0.90の場合、メタデータは RAIDデバイスの末尾128KB〜のどこか(デバイスサイズを64KBアラインしたところ)に 格納されている4KBのデータなので、以下の操作でバックアップ可能。 RAID0の時は二つのデバイス両方取得しておくこと。

# dd if=/dev/sda bs=512 skip=$((3907029128-128*(1024/512))) | bzip2 -c > /mnt/backup/HDL2-A40-md-metadata.img.bz2

リストアする時は、以下手順で。 データ部分は別途バックアップしといてくれたまえよ。 以下の手順でもデータ部分はなくならないけど、ユーザ設定とかはバックアップ時の 状態に戻ってしまうため、アクセスできないファイルができちゃうかも。 だから、よくわかってないならデータ部分もバックアップ時のものに戻すのが無難。 メタデータは、サイズが異なるHDDにはリストアできないことに注意(理由が わからん人は、こういうことしちゃダメ!)。

# bzip2 -dc /mnt/backup/HDL2-A40-system.img.bz2 > /dev/sda
# partprobe /dev/sda
# bzip2 -dc /mnt/backup/HDL2-A40-md-metadata.img.bz2 | dd of=/dev/sda bs=512 seek=$((3907029128-128*(1024/512)))

実は、システム部分はHDD1とHDD2とで微妙に内容が異なる (バックアップ後のバイナリで確認)。中が見えない(し見る気もない)のでなんとも いえないけれど、異なる以上は両方バックアップを取っておいた方がいいと思う。 一応HDD2のシステムをHDD1にリストアしてHDD1側から起動できることは確認したけど。

●データ部分のバックアップ方法

まぁ…NASなんだから、NASとして使用しつつ ネットワーク経由でどっかに保存するのが簡単だろう。普通はそれでO.K.。

それとは別に、ファイルシステムとしてなんとかしたいなら、 別途用意したLinuxマシンにHDL2-AのHDDを接続して、6番目のパーティションを xfs_copyコマンドでどっかに 全コピー。xfs_copyコマンドで作るバックアップ(=コピー先)ファイルは sparseになるらしいので、sparse機能が有効なファイルシステム上であれば、 実際のディスク容量は少なくて済む。 ただし、xfs_copyコマンドでは、コピー先にコピー元と全く同じファイルシステムが 作成されるため、パーティション上にコピーする時も パーティションサイズに合わせてファイルシステムサイズを変えては くれないことに注意。コピー後 xfs_growfsすればいいけど。 あとはxfsdumpかなぁ…。 こっちのほうが汎用性は高そうな気が。

いずれにしても、これはRAID1のみの話。RAID0だと、外部Linux上でバックアップ 取ろうとすると、二つのディスクを同時にLinuxに接続してmd有効にした上で 云々しないといけなくて面倒。

●どうしても起動しない時のファイルサルベージ方法

システムもHDDも壊れてHDL2-Aが全然起動できなーい!しかしデータサルベージ したーい!というときは、RAID1構成であれば、そのHDDを外部Linuxに接続した上で 以下のように操作することで、 xfs部分が壊滅的に壊れていなければ、外部のLinuxからmountして参照可能。 以下では自作1CDLinuxとknoppixを使ったので/dev/sdaで認識されたとする。

# mount -t xfs -r /dev/sda6 /mnt/hdd
# (mountできた)

XFSのWikipediaの 「欠点」に書いてあるように、ARM Linuxでのxfsジャーナルはx86 or x86_64 Linux 上では復旧できないので、上のコマンドでmountできない場合は、潔くジャーナルを 諦める。

# mount -t xfs -r /dev/sda6 /mnt/hdd
mount: Structure needs cleaning
(mountできなかった)
# xfs_repair -Lv /dev/sda6
(多分エラーが出て/lost+foundにいくつかファイルが移動するが男らしく諦める)
# mount -t xfs -r /dev/sda6 /mnt/hdd
# (mountできた)

RAID0の場合は、以下のようにすればmountできるかもしれない(が、未検証)。

# mdadm --assemble /dev/md0 /dev/sda6 /dev/sdb6
# mount -t xfs -r /dev/md0 /mnt/hdd

●バルクHDDへの換装方法

以下の条件を満たせば、I-O Dataが提供している純正のものではなくても換装可能。

  1. 追加するHDDのパーティションを全て削除しておくこと
    → 削除してないと、うまく認識されないことがある
  2. 今まで使ってきたHDDと併用する(つまり一本だけ変える)こと
    → システム領域(上の4番目のパーティションまで)をミラーする必要があるため、RAID組み終わるまでは必ず併用しなければならない
  3. もう一方のディスクと、ディスクサイズが同じか大きいこと
    → もう少し詳しく言うと、換装するHDDの総セクタ数が、必ず元のHDDの総セクタ数以上(同一でもよい)であること。ただし、大きいものに換装しても、HDL2-Aで使用できる容量は増えず、大きいほうは差分が完全に無駄になることに注意

これらさえ守れば、片方抜いて新しいHDDを挿してフォーマットすればいい。 RAID1ならそれで換装は完了する。RAID0ならデータ部分のフォーマットが必要。

上の条件、特に三番目を書いたのには理由があって、 同じHDD容量が表示(たとえば2TBとか)されていても、 実際にはメーカーによって?微妙に総セクタ数が異なるHDDが存在しているからだ。 なに?「本当か?」だって?よしわかった、証拠見せてやる!

サイズ型名サイズ(byte)セクタ数
(512byte/sector換算)
1TB ST31000520AS 1000204886016 1953525168
WD10EADS
WDH1CS10000N
HDT72101
2TB WD20EARS-00MVWB0(WD Green) 2000398934016 3907029168
WD20EZRX(WD Green)
ST2000DL001
ST2000DL003
DT01ABA200V
HDS722020ALA330(0F10311)
SAMSUNG HD203WI
3TB ST33000651AS 3000592982016 5860533168
HDS5C3030ALA630
WD30EFRX(WD RED)
DT01ACA300
4TB ST4000DM000 4000787030016 7814037168
HMS5C4040ALE640(0S03361)

…あ、あれ?全部同じ…? おっかしーな、前調べた時はSeagateだけちょっと(8セクタくらい)でかい、みたいなことがあったと思ったけど…。どのデータだっけ…。

●サイズの異なるHDDへの換装方法

サイズが同じHDDへの換装方法は、上に述べたとおり。この方法を使うことで、 元のHDDより大きいHDDへは換装できる。しかし、それだと、 たとえ大きなサイズのHDDを挿しても、元から挿さってたHDDより 大きい容量を認識させることができない。元から挿さってたのより大きいHDDを 挿して、しかも容量全部認識させることはできないか?

端的に言えば、可能。

「ファームウェアに換装対策あり」という情報もあるようだが、我輩は1.07へ アップグレード後、以下の手順で換装を実施し、可能であることを確認した。 今のところ不都合はない。REGZAは持ってないのでDLNA/DTCP-IPがち ゃんと動くかどうかは未確認。そもそも3TB HDDx2にしちゃうとHDL2-A6.0相当だから I-O DATAオフィシャルには「未対応」になるのかな。

我輩は別にLinuxシステムを持っていたので、 以下のように操作して3TBに換装してみた。 以下、コピー元の2TB HDD(Seagate ST2000DM001)を「元HDD」、 コピー先の3TB HDD(Toshiba DT01ACA300)を「先HDD」と呼ぶ。
あ、以下の手順ではデータ領域は移行できないので注意。

  1. まずHDL2-A本体から元HDDを二本とも抜く

  2. 別途用意したLinuxシステムに元HDD(のうち一本)と先HDD(のうち一本)を接続

  3. 前述の「システム部分のバックアップ方法」で述べた方法で元HDDから システムをバックアップし、先HDDにリストア
    別方法として、ddでHDDをベタコピー(dd if=/dev/元HDD of=/dev/先HDD bs=1024M など)してもよい。ただ、コレだと元・先HDDを両方6GbpsのSATAポート接続しても、 実測でコピー速度は98.8MB/s、2TBのコピーに6時間かかった。それよりは、 システム部分だけ(4.5GB)をコピーした方が早い。

  4. 先HDDのgptを修正(元HDDと先HDDの容量が異なる場合だけ)
    この時点で先HDDのgptは元HDDのgptそのまま。なので、元HDDと先HDDのサイズが 全く同一でなければ、gptそのものが壊れている。

    このいずれかの作業を実行しないと、先HDDをHDL2-Aに挿入して起動したときに NAS OSが起動途中で停止する。 しばらく頑張って起動しているように見えるし、(HDDが無い側のNASのHDD エラーランプは付くが)挿した側のエラーランプは付かないけれど、いつまで たってもIPアドレスが割り振られないらしく、外からアクセス不能。

  5. 先HDDの6番目の領域(データ領域)を削除し、最大サイズで再作成
    この時点での6番目の領域はHDDサイズに合っていないので、 partedで削除し、mkpartで適当なサイズのものを作るだけ。 ファイルシステムまで作る必要はない。
    # parted /dev/sda
    (snip)
    (parted) remove 6
    (parted) u s
    (parted) mkpart primary 8650832 -1  ※-1は最終セクタを表す
    (parted) quit
    

  6. 先HDDの6番目の領域の上に、適当にmdデバイスを作成
    ここでは6番目の領域を/dev/sda6とした。 2TB以上の大きさの場合もあるので一応metadataを1.0(※0.90と同じ位置に するため1.1などを使わない)とした。
    # mdadm --create /dev/md0 --level=raid1 --raid-devices=2 --metadata=1.0 missing /dev/sda6
    この方法でmetadataを作ると、後に空HDD挿入してRAID再構築させた場合も、 再構築後の空HDDのmetadataも1.0になる。 普通mdadmにおまかせで--addするとそうなるからかな。助かる。

  7. 先HDDを(一台だけ)HDL2-Aに接続して、起動することを確認
    存在しないHDD側でエラーランプが付くが、NASとしては起動する。IPもちゃんと 割り振られ、外部からアクセス可能。ただし、ディスクは壊れていると表示される

  8. Webの管理ツール経由でディスクを再フォーマット
    これの操作で、データ領域にDLNAやらのディレクトリも作成される。

  9. HDL2-Aを再起動
    再起動後、Web管理ツール上は、(一個HDDないのでディスクエラーとなるが) ディスクサイズなども正しく表示され、共有などは可能となる。

  10. HDL2-Aにもう一つの先HDDを挿入し、自動的に再構築させる
    3TB HDDの場合、10時間くらいかかる…。
    でも、それよりも、ホットスワップで再構築始まるのかと思ったら始まらず、 一度HDL2-Aの電源切って新しいHDD挿入する必要があることに驚いた。 電源投入後再構築が始まる。なんだそれ。

これで我輩は換装できた。換装後の3TB HDDのpartedの表示結果(セクタ単位)を以下に。 IDがTOSHIBA DT01ACA3で、Physical Sector Sizeが4096B、6番目の パーティションだけが元より大きくなっていることが判るだろうか。

Model: ATA TOSHIBA DT01ACA3 (scsi)
Disk /dev/sdd: 5860533168s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start     End          Size         File system     Name     Flags
 1      40s       1048623s     1048584s     ext3            primary
 2      1048624s  3145783s     2097160s                     primary
 3      3145784s  7340095s     4194312s     linux-swap(v1)  primary
 4      7340096s  7602247s     262152s                      primary
 5      7602248s  8650831s     1048584s                     primary
 6      8650832s  5860533134s  5851882303s  xfs             primary

ついでにこの領域のmdadm --detailの結果も以下に。 一個だけで使ったからdegradedになってるけどまぁ参考までに。md metadata 1.0で フォーマットされていることがわかる。

/dev/md0:
        Version : 1.0
  Creation Time : Fri Aug 16 22:01:30 2013
     Raid Level : raid1
     Array Size : 2925940992 (2790.39 GiB 2996.16 GB)
  Used Dev Size : 2925940992 (2790.39 GiB 2996.16 GB)
   Raid Devices : 2
  Total Devices : 1
    Persistence : Superblock is persistent

    Update Time : Wed Aug 21 20:06:16 2013
          State : clean, degraded 
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           Name : 
           UUID : xxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx
         Events : 15037

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       2       8       22        1      active sync   /dev/sdb6

あとは、念の為xfs_infoの結果も貼っとこう。projid32bit=0が増えてるが気にしない。 lazy-count=0なのがちょい気になる。 普通にmkfs.xfsするとlazy-count=1になるんだよね…。

# xfs_info /xfs-mntpoint
meta-data=/dev/sde6              isize=256    agcount=7, agsize=121824316 blks
         =                       sectsz=512   attr=2, projid32bit=0
data     =                       bsize=4096   blocks=731485248, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=32768, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0

換装手順は、4TB HDDでも8TB HDD(まだ無いけど)でも同じ。 4TB HDDx2へ換装テスト(ただしRAID1のみ)してみたら、問題なくできた。 誰か6TB HDDx2寄付してくれたら、我輩喜んで試すよー!(厚顔)。

なんでこんな複雑な手順が必要なのかというと、先述の通り、データパーティションが md+xfsでフォーマットされているため。このため、HDL2-Aでは 単純な「データパーティションの拡大」は不可能。mdのメタデータが パーティション末尾に存在するので、単純にパーティションを拡大しちゃうと メタデータが参照できなくなってしまうから。失敗している人はこれをちゃんと 把握してなかったんじゃないかなぁ。あ、メタデータにはそのパーティションを /dev/md#使った時のパーティションサイズとかも入っているので、単純に メタデータ位置を動かせばO.K.というワケでもない。結局、(メタデータの UUIDは変わるけど)mdadm --createで作り直した方が楽。

換装後のCrystalDiskMarkは以下の通り。 大きな変化はないが、ランダムアクセスの性能がちょっと 上がってる。HDDごとの傾向が出てて面白い。

「安定動作こそ我が命!」とかページ頭で書いておきながらこんなことすんなよという そしりはあえて全身で受け止める所存ナリ。全く仰るとおりで。

■超絶危険な管理用スクリプト(for Linux Only)

HDD換装やデータコピーの手順を、Linux上で動作するbashスクリプト化してみた。 これらを使えば、サイズが異なるHDDへの換装やデータコピー(RAID1のみ)とかが簡単に できるようになる。つってもまぁキケンなのはその通りなので、 中を参考にするだけにしといた方がいいかもよ?

フツーのシステムでも1CDLinuxでもなんでもいいから、とにかく rootになれるLinux上で動作するはずなんだが…udev周りで「デバイスを動的に 認識して勝手にmdadm --assembleでスタートしちゃう」という行儀の悪い ディストリビューション(コレやられるとコピー元のHDDのmdのctimeも変更されるので、 RAID崩壊しちゃうんだよね…)では、実行時エラーになることもしばしば。 そういうのでは、事前に「udevadm control --stop-exec-queue」とかでudevを 一時停止しておくと吉。Knoppix 7.0.2 では、udev 止めちゃうと /dev/md* が 自動作成されなくなるので、事前に cd /dev; ./MAKEDEV md とか実行して デバイス作っとかなきゃいけないとか、ディストリビューションごとにそういう 細かい不具合がもりもり。

我輩は、CentOS6(とソレを元にした自作の1CDLinux)上で、上で述べたのコマンドで udevを止めた上で動作確認した。しかし 正直、我輩に聞かれても再現環境がないとなんともできないかもしれないため、 うまいこと動かなくても自分でなんとかするくらいの気概は欲しいところ。 なお、Ubuntuでは動かなかったとの情報を頂きました。ダメじゃん! あと、使ってアナタのシステムが破損しても我輩は一切責任取らないのであしからず。

問題あるなら runlevel 1で実行するか頻繁にOSを再起動してくだされ。 おススメはrunlevel 1か、USB経由で接続してなんかするごとに抜き挿しする、かなぁ。

●HDL2-Aで利用できるようにHDDをクリアする「clear-hdl2-a-disk.sh

使用方法は以下の通り。

# sh clear-hdl2-a-disk.sh  /dev/クリアするHDDデバイス

HDL2-Aで使用するために、ディスクを真っ白にするスクリプト。 中のデータを全部消すのではなくて、HDL2-Aで再利用するときのために 最小限のクリアを行う (だから、実行時間は短い。input待ちを除けば一分以内に終わるはず)。 具体的には実行するのは以下の二つ。

  1. HDL2-Aで利用する各パーティションの先頭・末尾(=MDとファイルシステムのシグネチャ)を128KBずつクリアする(※パーティションが存在しなくても、きめうちでクリアする)
  2. 全てのパーティションを削除する(GPTになる)

HDD上に要らんゴミが残っていると後述のスクリプトでエラーになったりするので、 そういうのを防ぐために、後のスクリプトを使う前には対象HDDをこのスクリプトで 真っ白にしておくことをお勧めする。
また別の用途として、HDL2-AのRAID崩壊時に復旧させるために新たにHDDを挿す時、 そのHDDが新品でない(=中にゴミが残っている)のであれば、 そのゴミが悪さするのを防ぐために、 事前にこのスクリプトを使って新たに挿すHDDを真っ白にする、なんてことにも使用可能。

当然、指定したHDDは真っ白になり、中のデータにはアクセスできなくなるので要注意。 一応大部分のデータは残ってはいるが、アクセスできるようにするのは現実的には無理。 間違ってクリアしちゃったら諦めるが吉。 オマエやれっていわれたら1億円積まれたら考えなくもないレベル。

●HDL2-A用のHDDを作成する「build-hdl2-a-disk.sh

使用方法は以下の通り。

# sh build-hdl2-a-disk.sh  /dev/作成対象HDDデバイス  システムイメージ

データを移行するのではなくて、単純に新しいHDDを買ってきて、そのHDDを HDL2-Aに載せたいなー(データは空でいいから)、という時のために使用する。事前に、 システムイメージ(上で取得したシステム部分のバックアップ(4.2GB、非圧縮またはgz/bz2/xz圧縮))が必要。 実行する内容は以下の通り。

  1. システム部分のバックアップを対象HDDに書き戻す
  2. 対象HDDのパーティションを適当に切りなおし、RAID1としてデータ領域を作成する(データ領域はHDDサイズに合わせて作成される)

このままではHDL2-A上で使えない。 ちょい面倒だが、HDL2-A上で使うには、以下の手順が必要。

  1. まず、作成した対象HDDを「一台だけ載せて」HDL2-Aを起動する
  2. 起動したらエラーになるがWebUIは使えるはずなので、RAID1でフォーマット(これでDTCP-IPのファイルがデータ領域に作成される)、電源Off
  3. もう一台の換装対象HDD(ブランク、またはclear-hdl2-a-disk.shで真っ白にしたもの)を載せてHDL2-Aをブート。RAID1ならこれで完了、自動リビルドが始まる
  4. RAID0にするなら、この後に再度WebUI上からRAID構成を変更してフォーマットする

●コピー元・コピー先の容量を問わず、HDL2-A用のHDDをコピーする(RAID1専用)「copy-hdl2-a-disk.sh

使用方法は以下の通り。 これだけはxfsがmountできるOSじゃないと動かないことに注意。 フツーのCentOS5(32bit)はmountできないので注意。CentOS6(64bit)以降がおススメ。

# sh copy-hdl2-a-disk.sh  /dev/コピー元HDD  /dev/コピー先HDD

(RAID1でしか使えないけど、)コピー元HDDからコピー先HDDに、HDD内容を全てコピーする。 容量がコピー元・コピー先で異なっていても、コピー先のデータ領域容量が コピー元の実際のデータ量より大きければ問題ない。すなわち、コピー先HDDがコピー元HDDより小さくても、データが入る容量があればいい。 実際のコピーはデータ量分のみ実行されるので、HDD全部ddでコピーするよりは コピー時間も短くて済む。

新しくでっかいHDD買ってきて換装するー、あるいは、バックアップ用に小さなHDD上にデータを取っとくー、とかの時にはとっても便利。 コピー元HDDは変更しない(mdも使わないのでMD headerのctimeも変更されない)ので、 コピー元HDDをそのままHDL2-Aに戻しても、RAID崩壊→再構築されたりしないのも利点。

ただし、コピー先のHDDをHDL2-A上で使用するには、一手間必要。 データ部分のMDのUUIDが異なるため、既存のディスクや同じ方法で取得したHDDとの ミラーリングはできない(違うとみなされて再構築される)からだ。 やるとRAID崩壊して再構築が走るはず(RAID1ならデータは壊れたりはしないはず)。 だから、作成したコピー先HDDをHDL2-A上で使うには、以下の手順を実行すること。 ちょい面倒。

  1. 作成したコピー先HDDと「ブランクまたはclear-hdl2-a-disk.shで真っ白にした、コピー先HDDと同じまたはより大きなサイズのHDD」を用意
  2. 二つを一緒にHDL2-Aに載せて起動
  3. 自動的にRAID再構築が始まるので終わるまで待つ(再構築中にもデータアクセスはできる)

これでDLNA/DTCP-IPで書いたデータまで引き継げるかどうかは不明。 フォーマットしない限り、引き継げないんじゃないかしらん…。 誰かがREGZAくれたら試せるんだけどなー…(チラッ)。 とはいえ、我輩はフツーにPCのデータ領域としてしか使ってない(=DLNA/DTCP-IPで データを保存していない)ので、別にDLNA/DTCP-IPで保存したデータが読めなくなっても 問題ない問題なーい。

なお、コピーにかかる時間はテキトーに(50MB/s転送できるものとして)計算しており、 あんま信じないように。

■オマケ情報

●オマケ0:HDL2-A用HDD間で手動でデータを移行するには

上の copy-hdl2-a-disk.sh 中で実行してるのは以下のような手順。 データ領域(六番目のパーティション)を、xfs_copy で全部を元HDD→先HDDへ コピーした後、先HDDの容量が違う(大きい)場合のために、xfs_growfsで パーティションをいっぱいまで広げる。

まぁしかし…これやるくらいなら、フツーにNASとして動かしつつ、 ネットワーク経由でコピーした方がいいと思うけどねぇ。

# xfs_copy /dev/sdb6(=元HDD) /dev/sda6(=先HDD)
# mdadm --assemble --run /dev/md0 /dev/sda6(=先HDD)
# mount -t xfs /dev/md0 /mnt
# xfs_growfs /mnt
# umount /mnt
# mdadm --stop /dev/md0

●オマケ1:md metadata 0.90のちょっと怖い話

md metadata 0.90だと、普通kernel-2.6では認識できる上限が2TBのはず。 3TB HDDを乗せるとおかしなことになっちゃう気がするのだが、 HDL2-A6.0は大丈夫なんだろうか。 だから上では強制的に1.0を使うようにしているのだけれど。

md ver 0.90で一デバイスあたり最大4TBまでチェック可能なパッチは こちらにある。 問題点は、sb->size(対象パーティションのセクタ数(512byte単位))が_u32なのに、 それを*2して比較・代入してるために、パーティションが2TBを超える(=セクタ数が 31bitを超える)と計算中に32bit超えちゃうというところ。 上のパッチは、計算元を32bitからsector_t (CONFIG_LBDAF=yなら64bit)にキャストしてから計算することで、 桁あふれを回避するパッチだ。ただし、元々sb->sizeは_u32で固定なので、 だからmd metadata 0.90では1デバイスあたり4TBまでしか認識できない。 md metadata 1.x ではそのあたり改善されて、色々64bit化 されているので大丈夫。バグはあるかもしらんけど。

ファームウェア1.07のkernelは2.6.31.8らしく、 kerne.orgの2.6.31.8のソースコード では上のパッチは適用されていなかったので、I-O DATAが独自に対応したので なければ未対応なんじゃ…?現物ソースコード見ないとわかんないけれど。ちうか ソースコード要求するのめんどくさいからこれ以上は見ない! 一方、 3TBのパーティションを元にmd ver 0.90でRAIDを組むと、フツーに組めるけど 使ってるうちに壊れちゃう、みたいな話もある。オーバーフローして 先頭から書き始めてしまって云々みたいな。そりゃそうだろう。コエー!

HDL2-A6.0を持ってる人は、是非mdのメタデータがどうなってるか教えて下さい。 「mdadm --detail /dev/md0」とかやると出てくるから。加えて、RAID1で2TBを 超えたデータを既に持っている人は、問題なく動いているかどうかも是非。 RAID0なら4TB越えかな?

ちなみに、 こういう方法で既に存在するmetadata 0.90を1.0に変更することは可能。 0.90と1.0のmetadata位置が同じことを利用する裏技だけど(だから1.1などへは変換できない)。

●オマケ2:外向けに開いてるポート

HDL2-Aを普通に動かしつつ、別のマシンから、HDL2-Aが外向けにサービスしている ポートが無いか確認してみた。まるでクラッカーみたいな所業。UDPは遅いので 1024まで。 結果見ると、TCPではtelnetもsshも使えないですな。アタリマエか。 なんかUDPは、FW 1.07では開いてるポートが多かったが、 1.09になってから随分減ったね。よもやこのページ監視されてる!?

# nc -z 192.168.1.7 1-9999
Connection to 192.168.1.7 21 port [tcp/ftp] succeeded!
Connection to 192.168.1.7 80 port [tcp/http] succeeded!
Connection to 192.168.1.7 139 port [tcp/netbios-ssn] succeeded!
Connection to 192.168.1.7 427 port [tcp/svrloc] succeeded!
Connection to 192.168.1.7 445 port [tcp/microsoft-ds] succeeded!
Connection to 192.168.1.7 548 port [tcp/afpovertcp] succeeded!
Connection to 192.168.1.7 3689 port [tcp/daap] succeeded!

# nc -u -z 192.168.1.7 1-1024
Connection to 192.168.1.7 137 port [udp/netbios-ns] succeeded!
Connection to 192.168.1.7 138 port [udp/netbios-dgm] succeeded!
Connection to 192.168.1.7 427 port [udp/svrloc] succeeded!

■マメ知識

■リンク

■おわりに

「全部自己責任」という原則において、皆様からの質問には基本答えない。 でも、ご意見や情報、誤情報訂正要求(根拠つき)などは募集中。 掲示板経由でも メール経由でも構わないのでどうぞ。

暗号化されてる所を云々という話は、アレな上に興味ないから本ページでは扱わないのであしからず。

あー、上で述べた手順やスクリプトで移行したデータが、DLNA/DTCP-IPで使えるかどうかのテストもしたいなぁ。誰かソレがテスト可能なREGZAを恵んでくれまいか。4TB以上のHDD載ってるヤツ。

■追記

その後、運用中にファームウェアを1.08→1.09とupdateしたが、特に問題なし。 誰か上で述べた方法でDLNA/DTCP-IPが問題なく動くかどうかテストしてくんない かしら。ああ、REGZAを我輩に買ってくれてもいいよ!?