HANZUBON.jp

主にミラーの動作チェックのために 簡単なログを irc のとあるチャネルに流してたんだけど いろいろ都合が悪くなったので twitter の @debianmirrorjp へ流すように変更してみた(つもり)

最近は Western Digital の 3TB (3TiB) HDD WD30EZRX がものすごい安価(1万切って 9700 〜 9900 円くらい 下手すると特売で9000円きることも)で売っていて、手頃だしバイト単価も安くていいので これに手を出すわけです。

でも、この HDD って 4kセクタな上に単体で2TBをこえてるので いろいろあるわけですよ。

とりあえずメモ的に2点。

hanzubon.jp の mirror 用ストレージは areca の arc-1680 という SATA/SAS RAIDカードにぶら下がって構成されています。(その他のarecaのカード含めてのようですが)、最新の firmware (version 1.49)に更新してないと 3TiB な HDD を正常に認識しません。

接続されているのは、認識するんですが容量が0.0GBと表示されて まったく使えません(わら

1.49 まで上げてあるつもりで、つないだんですが 最初そんな状態になって ちょっと焦りました。

逆にいうと、1.49 にあげたところ 正常に認識され いまのところ特に問題もなく利用できています。

もう一点、いままでめんどくさいので避けてきた 4k セクタの話。

とりあえず、Linux的には周辺のブツ(fdisk とか parted)とかが すでにそのあたりを意識してくれるようになってるんで、深く考えずに Go しても大丈夫なんですね いまどきは(わら

2TB 以下の HDD であれば、DOS mbr でいけるんで fdisk でパーティションきれば 勝手に適当にアラインメントとってくれるようです。fdisk の表示上も物理セクタ/論理セクタのサイズをちゃんと認識してくれて表示してくれるようになっています、いつのまにか。

2TBを超える場合は GPT でということになりますが、こっちも parted でやってやればさくっといけます。あらかじめ mklabel gpt してある前提で


parted --align=min --script /dev/sdX mkpart primary ext2 0 100%


みたいなことをすれば、parted が「ぉい alignment できてねぇぞ その指定だと一番近い alignmentできてる開始位置はここだ」と教えてくれるので、その指示にしたがって先頭を指定するのがいいようです。

(追記)
こんなことしなくても –align=opt してパーティションきるのが正解?
おしえてエラい人(わら

以上、雑記的メモでした。

「debian mirror のストレージの構成 HDD 一本あたりの容量あげて本数減らしたいなー だれか HDD おごってくれないかなー(わら」と tweet したら、ありがたいことにほんとにnakanotにおごっていただけたので ゆうべから 構成変更作業をしてました。

データ自体は debian-cd 以下を除いて復旧/更新済です。

hanzubon.jp のマシンを ASUS P8B-E/L4 と Xeon E3-1230 にしてみました。

以下、罠的なこととか。

マニュアルには記述がありますが DDR3 unbuffered ECCでしか動作しません。non-ECC のメモリだと POST 中にハングアップしてしまって、BIOSの画面さえ出てきません。というか、beep の類もいっさい鳴らないので 最初は故障かと思いました…(気づかないで 初期不良かと思って、TSUKUMOのサポートに持ち込んでしまって数日無駄に…(わら マニュアルはちゃんと読みましょう)

Linux的には特にハマるようなデバイスは特に載ってません(オンボードのグラフィックチップがASPEEDなので、X動かすのはあれかも? まぁ、このマザボでXなんか動かさないよね)。

ファームがまだ若干バギーなのかドライバのバグなのか以下のような現象がおきています(kernel のバージョンは 2.6.38.2)

on boardのSATAをAHCIモードで使っていて、6Gbps出る 2つのport(port-1/port2)にそれぞれ、Intel X25-M G2 よく確認したら G1 でした… と crucial RealSSD C300がつながっています。この状態だと X25-M の方の probe に失敗して 1.5Gpbs でリンクしてしまいます。こんな感じ。

追記(2011/4/16) C300 をとっぱらってみたが、状況はかわらず。


[ 4.819416] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 4.819969] ata2.00: ATA-9: C300-CTFDDAC128MAG, 0006, max UDMA/100
[ 4.820218] ata2.00: 250069680 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[ 4.820722] ata2.00: configured for UDMA/100
[ 9.867447] ata1: link is slow to respond, please be patient (ready=0)
[ 14.559486] ata1: COMRESET failed (errno=-16)
[ 19.943519] ata1: link is slow to respond, please be patient (ready=0)
[ 24.584554] ata1: COMRESET failed (errno=-16)
[ 29.968591] ata1: link is slow to respond, please be patient (ready=0)
[ 59.599795] ata1: COMRESET failed (errno=-16)
[ 59.600038] ata1: limiting SATA link speed to 1.5 Gbps
[ 59.904800] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 59.905330] ata1.00: ATA-7: INTEL SSDSA2MH080G1GC, 045C8820, max UDMA/133
[ 59.905581] ata1.00: 156301488 sectors, multi 16: LBA48 NCQ (depth 31)
[ 59.906051] ata1.00: configured for UDMA/133
[ 59.906455] scsi 0:0:0:0: Direct-Access ATA INTEL SSDSA2MH08 045C PQ: 0 ANSI: 5


4つのetherをbondingしていますが(モードは802.3ad)、なぜかNICの一つだけがResetしまくります(数秒おきとかいう感じで)。ちょっと思いつきで irqbalance 入れてつついたら、おさまったので なにか irq まわりがおかしい?思い過ごしだったっぽい。なにかをトリガにおさまることはあるようだけど、irqbalance ではなかったようだ…

[ 337.166262] e1000e 0000:07:00.0: eth3: Reset adapter
[ 337.259625] bonding: bond0: link status down for interface eth3, disabling it in 200 ms.
[ 337.459610] bonding: bond0: link status definitely down for interface eth3, disabling it
[ 339.997657] e1000e: eth3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[ 340.059614] bonding: bond0: link status up for interface eth3, enabling it in 200 ms.
[ 340.259616] bonding: bond0: link status definitely up for interface eth3, 1000 Mbps full duplex.
[ 346.166012] e1000e 0000:07:00.0: eth3: Reset adapter
[ 346.260572] bonding: bond0: link status down for interface eth3, disabling it in 200 ms.
[ 346.460579] bonding: bond0: link status definitely down for interface eth3, disabling it
[ 348.976582] e1000e: eth3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[ 349.060557] bonding: bond0: link status up for interface eth3, enabling it in 200 ms.
[ 349.260555] bonding: bond0: link status definitely up for interface eth3, 1000 Mbps full duplex.
[ 355.166157] e1000e 0000:07:00.0: eth3: Reset adapter
[ 355.260477] bonding: bond0: link status down for interface eth3, disabling it in 200 ms.
[ 355.460479] bonding: bond0: link status definitely down for interface eth3, disabling it
[ 358.360549] e1000e: eth3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[ 358.460517] bonding: bond0: link status up for interface eth3, enabling it in 200 ms.
[ 358.660502] bonding: bond0: link status definitely up for interface eth3, 1000 Mbps full duplex.


(2011/5/12 追記1) kernel 2.6.39-rc7 ではこのGbEの問題は現状発生していません。

(2011/5/12 追記2) この問題以外に、ごくまれにNICの初期化自体に失敗する(? エラーは特に出ないのだけど、通信自体がいっさいできない)場合があるようです(電源投入直後かつ運が悪いと という感じ? ともかく発生したのは確かなんだけど、一度だけで再現もできないので ちょっと細かい状況まではわからないんだけども…)

HANZUBON.jp 今晩停止します 予定では20時前後から

停止中 各種mirrorの更新が止まります

mirrorに使ってるRAIDの構成変更をするので 時間かかる予定

主要mirrorは明日の昼間くらいまでにがんばる、その他は週末中には復旧するかなぁ という感じです

追記(2010/10/30 0:55):
とりあえず、主要部分は復旧したので表からアクセスできるようにしました。debian/debian-backportsは現在最新の状況にsync中(debian-volatileはdone)。その他は、まだ復旧中です。

追記(2010/10/30 10:20):
寝てる間に復旧しとりました。

とりあえず、現状やっつけで見づらいわけだけど

Debian mirror

Debian backports mirror

Debian volatile mirror

の push mirror の各サーバでの mirror にかかった時間とかミラーが
行われた時刻を集計してみることにした。

集計の更新頻度は現状30分おき。

なお、ここに出てこない国内のmirrorサーバは「push mirrorではない」
ので、ftp-master等でのtreeの更新が実際にそのmirrorサーバに伝搬する
のは、一般的に push mirror より大幅に遅れます。

ftp.jp.debian.org や cdn.debian.net は、これらの push mirror サーバをたばねた CDN に使われてるホスト名です。まとめると、現状 Debian の apt line として利用する場合は、

• 通常は ftp.jp.debian.org を使えばいい具合にしてくれる
• httpでの利用のみであれば cdn.debian.netを使うといい
• どーーーしても個別のミラーホストを指定したい人は、これらの push mirror サーバを指定する(ただし hanzubon.jp 以外を推奨)
• それ以外を指定しても、あまりいいことはない

となります(以上誤解をうみそうなので追記)

ちなみに、2010/10/11からdebian-volatileの更新がないっす。
なぜだろか…

追記1:
Ar-に「jsonでひっぱれるようなデータ用意シレ」と言われたので、

debian|debian-backports|debian-volatile

で取れるようにしました。

なんか どーも push signal こねぇな と思ってたら、ルータで塞いでいました…orz

ということで、signal くるのを確認したので復活したはず。

どーも すいません(わら

昨日は、たんきよで毎年恒例の忘年会でした。

久しぶりの参加のひともちらほら、新しく参加の人も何人か。
うかいさんのおくさんに初めて会いましたが、なかなか面白い人でした。

その後、nnnの知ってる店に だいすけ、まくつ、nnn、ならき、オレという感じで移動して二次会?で終電前に解散。

これが終わると、なんだかようやく年末が近づいてきた気がします。

Linux Software RAID (md)の onlie resizeの続編的ですが。

このmdは紆余曲折あって(?)現在は1TB HDD 5本でRAID5(スペアなし)という構成になっています。

が、なんとなく若干手狭な感じが出てきました(debian の iso imageにBDとか入ってきた
せいか、油断するとあふれることが…)

そこで、少し前からkernelでサポートされた「mdにデバイスを追加してでかくしてみる」ことを
してみましょう。1TBを5本→1TBを6本の構成にしてみます。

最初はこんな感じ。

$ lsscsi
[6:0:0:0]    disk    ATA      WDC WD740GD-00FL 21.0  /dev/sda
[8:0:0:0]    disk    ATA      WDC WD10EACS-22D 01.0  /dev/sdb
[11:0:0:0]   disk    ATA      WDC WD10EACS-22D 01.0  /dev/sdc
[13:0:0:0]   disk    ATA      WDC WD10EACS-22D 01.0  /dev/sdd
[14:0:0:0]   disk    ATA      WDC WD10EACS-22D 01.0  /dev/sde
[16:0:0:0]   disk    ATA      WDC WD10EACS-22D 01.0  /dev/sdf
[18:0:0:0]   cd/dvd  Optiarc  DVD RW AD-7170A  1.02  /dev/sr0

$ df /storage
Filesystem           1K-ブロック    使用   使用可 使用% マウント位置
/dev/md0             3845731848 3078934784 766797064  81% /storage
$ df -h /storage
Filesystem          サイズ  使用  残り 使用% マウント位置
/dev/md0              3.6T  2.9T  732G  81% /storage

$ sudo mdadm --misc --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Fri Oct 17 21:15:30 2008
     Raid Level : raid5
     Array Size : 3907039744 (3726.04 GiB 4000.81 GB)
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
   Raid Devices : 5
  Total Devices : 5
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Sep 22 08:58:55 2009
          State : clean
 Active Devices : 5
Working Devices : 5
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : 7b919d4f:b9e7742c:84bd942a:d4b8378f
         Events : 0.19904

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sdc1
       1       8       49        1      active sync   /dev/sdd1
       2       8       17        2      active sync   /dev/sdb1
       3       8       81        3      active sync   /dev/sdf1
       4       8       65        4      active sync   /dev/sde1

HDDはSATA/SASのエンクロージャに全部ささってますし、最近のSATAの
デバイスであれば(少なくともahciの一部、sata_sil24、sata_mvはOk)hot plugで
つなげば認識してくれるので、無造作に(物理的に)HDDをさして認識させます。

$lsscsi
[6:0:0:0]    disk    ATA      WDC WD740GD-00FL 21.0  /dev/sda
[8:0:0:0]    disk    ATA      WDC WD10EACS-22D 01.0  /dev/sdb
[11:0:0:0]   disk    ATA      WDC WD10EACS-22D 01.0  /dev/sdc
[13:0:0:0]   disk    ATA      WDC WD10EACS-22D 01.0  /dev/sdd
[14:0:0:0]   disk    ATA      WDC WD10EACS-22D 01.0  /dev/sde
[15:0:0:0]   disk    ATA      WDC WD10EADS-00M 01.0  /dev/sdg
[16:0:0:0]   disk    ATA      WDC WD10EACS-22D 01.0  /dev/sdf

/dev/sdgが増えました。

fdisk とかでパーティションを一つだけ切って、タイプを Linux raid autodetect
(0xfd)にしときます。

$ fdisk -l /dev/sdg

Disk /dev/sdg: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xfec868df

   Device Boot      Start         End      Blocks   Id  System
/dev/sdg1               1      121601   976760001   fd  Linux raid autodetect

次にmdにこのHDDを追加します。

$ sudo mdadm /dev/md0 --add /dev/sdg1
mdadm: added /dev/sdg1
$ sudo mdadm --misc --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Fri Oct 17 21:15:30 2008
     Raid Level : raid5
     Array Size : 3907039744 (3726.04 GiB 4000.81 GB)
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
   Raid Devices : 5
  Total Devices : 6
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Sep 22 09:08:50 2009
          State : clean
 Active Devices : 5
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : 7b919d4f:b9e7742c:84bd942a:d4b8378f
         Events : 0.19909

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sdc1
       1       8       49        1      active sync   /dev/sdd1
       2       8       17        2      active sync   /dev/sdb1
       3       8       81        3      active sync   /dev/sdf1
       4       8       65        4      active sync   /dev/sde1

       5       8       97        -      spare   /dev/sdg1
$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdg1[5](S) sdc1[0] sde1[4] sdf1[3] sdb1[2] sdd1[1]
      3907039744 blocks level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]

unused devices: 

こんな感じでスペアとして追加されます。

でもって、RAIDデバイスの数を変更します。
変更には mdadmの –grow オプションと –raid-devicesを組み合わせて指定します。

$ sudo mdadm /dev/md0 --grow --raid-devices=6
mdadm: Need to backup 1280K of critical section..
mdadm: ... critical section passed.

ここまでは、とりあえず数秒で終了します。

で、ここからRAIDの再構成が行われますがこれがものすごく時間がかかるので
気長に待ちましょう。

$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdg1[5] sdc1[0] sde1[4] sdf1[3] sdb1[2] sdd1[1]
      3907039744 blocks super 0.91 level 5, 64k chunk, algorithm 2 [6/6] [UUUUUU]
      [>....................]  reshape =  0.0% (279424/976759936) finish=1951.8min speed=8337K/sec

unused devices: 

mdのサイズにもよると思いますが、今回のサイズだと丸一日はかかるつもりで
いないとダメです(わら

この間もmdデバイスはon lineなので、通常どおり使用できます(が、まぁ今回の構成だと
このrebuild中にHDD一本でも死ぬとアウトなわけですが(わら 基本ここにはmirrorしか
入って無いので最悪死んでも復元できるので気にしない。もちろん用途によっては、
もう少し冗長性をとりましょう)

ただし、このrebuildが終わらないと「mdとしてのサイズが以前のまま(デバイス追加
する以前のサイズのまま)」なので、以下のファイルシステムのresizeはできません。

でもって、rebuildが終わったのを確認したら、ファイルシステムをresizeします。

$ sudo resize2fs /dev/md0
resize2fs 1.41.9 (22-Aug-2009)
Filesystem at /dev/md0 is mounted on /storage; on-line resizing required
old desc_blocks = 233, new_desc_blocks = 292
Performing an on-line resize of /dev/md0 to 1220949920 (4k) blocks.

これも容量によると思いますが、30分くらい待つと完了。

$ df /storage
Filesystem           1K-ブロック    使用   使用可 使用% マウント位置
/dev/md0             4807165280 3089638432 1717526848  65% /storage
$ df -h /storage
Filesystem          サイズ  使用  残り 使用% マウント位置
/dev/md0              4.5T  2.9T  1.6T  65% /storage

ほい、できました。

Debian mirrorの更新って、ミラー中もアクセスしても整合性がとれてるように、
ざっくりいうと次みたいな流れになっている。

1. pool/以下を–deleteなしでrsync
2. 全体を–after-deleteありrsync

(正確には dists/以下の特定パターンのファイルがあとで更新されること、
ファイルの削除が最後に消されることが条件だけど、まぁ細かいことは
考えなくてもいい、ここでは)

で、なにが言いたいかいうと、結局都合2回rsyncがかかるのと、1回目と2回目に
同じディレクトリのトラバーサルが走るので、まぁなんつーか若干効率が悪い
わけです。

でだ、一方 rsync には –deley-updates というオプションがあります。

これは取り合えずファイルを別の位置にどばーっととってきておいて、
実際のファイルの更新は最後にまとめてやりますよ というオプション。

一般的にリモートからローカルの転送には時間がかかるけど、ローカルでの
renameは比較的短時間で済むので、ツリー全体の不整合な時間を
ある程度減らせますよ というためのものですね(もちろん、atmicには
なりません)。

でね、この –deley-updatesオプションの動作を拡張するなり、
別のオプション(例えば –deley-update-patternとかいうオプション
を新設がいいんじゃね? という気がしている)して、「指定したパターンに
合致したファイル/ディレクトリのみ、delay-update する」とかできると、
Debian mirror 的には rsync 一発でいけるようになるので、ちょっと
うれしいんじゃねぇか? とか思いました。

誰かやる人?(わら
(自分でやれといわれそうだな(わら)