movie anime 機動戦士ガンダム THE ORIGIN V 激突 ルウム会戦
きょう公開された作品。 TOHO シネマズ日本橋で観てきた。
このシリーズは今まで新宿ピカデリーで観てたけれど、今回は TOHO シネマズのプレミアボックスシートでのんびり観ようかと。 ガンダムが上映される日本橋のスクリーン 7 は、座席数 404 席でプレミアボックスシートが 2 列ある広い空間で、しかもスクリーンサイズが TCX (TOHO CINEMAS EXTRA LARGE SCREEN) という独自規格の巨大なやつ。 迫力満点で、非常に良かった。
今回の第 5 話は戦闘シーンやメカが動きまくるシーン、爆発シーンなどが大半を占めるが、この手のシーンでありがちな手抜きが一切ない、というかむしろ逆に細かく描き込み過ぎてる。 すさまじいクオリティで、大画面で隅々まで観るだけでも楽しい。
ネタバレを避けるため詳しくは書かないが、次回の『誕生 赤い彗星』の冒頭をチラ見せした感じで終わるので、次回が待ち遠しくて仕方がない。 普通の地上波アニメなら 1 週間待つだけでいいのに、この作品だと次回が 8 ヶ月後なんだよなあ。 通常の 3 倍早く上映を!!
http://www.gundam.info/topic/18664
home Wi-Fi ルーター不安定化の原因調査
1 週間前まで一度も不安定だなんて思ったことがなかった Wi-Fi ルーターが、ここ 1 週間やけに不安定なので、解消すべく試行錯誤してみることに。
いま使ってる Wi-Fi ルーター ASUS RT-AC68U は、旧 Wi-Fi ルーターと旧 ONU が故障した日に買い替えたやつで、その翌日から先週月曜の回線工事までずっと WAN 側の回線は WiMAX 2+ だった。 つまり、単なる DHCP クライアントの 1 台として、WiMAX 2+ ルーターにぶら下がってただけ。 それが、回線工事以降、WAN 側は光回線への PPPoE 接続で動作してる。 これが 1 週間前までとの違い 1 点目。
2 点目は、先週火曜から WAN 側でも IPv6 通信を使い始めたこと。 パススルー接続だから基本的にコネクションには関与しないはずだが、違いとしてはこれも。
ルーターが不安定になったときは、高確率で Wi-Fi がつながらなくなる。 勝手に再起動した場合は 3 分くらい待てば復活するが、再起動せずに粘ってしまった場合は強制的に電源をオフ・オンしてあげる必要がある。 後者の場合、再起動後にシステムログを参照すると、カーネル内でメモリが足りずに死んでるパターンが大半。 メモリリークか?
Sep 3 11:55:23 kernel: SLUB: Unable to allocate memory on node -1 (gfp=0x21) Sep 3 11:55:23 kernel: cache: kmalloc_dma-4096, object size: 4096, buffer size: 4096, default order: 3, min order: 0 Sep 3 11:55:23 kernel: node 0: slabs: 3833, objs: 30664, free: 0 Sep 3 11:55:23 kernel: swapper: page allocation failure. order:0, mode:0x4021
ルーターの管理画面でメモリ使用量を見てみると、再起動直後は 20% 前後を維持してる。 これが何かの拍子に上昇し始めると、あとはもう死へのカウントダウン。 65% 以上になると、ほぼ絶望的である。
コネクション単位で通信内容を解析すると思しき Adaptive QoS を無効化したら安定したように見えたが、気のせいだった。 1 点目の PPPoE 接続が原因だったら不具合報告をたくさん見掛けるはずだけれどそんなことはないので、とすると 2 点目の IPv6 が原因なのかなあ。 ルーターと Wi-Fi アクセスポイントが 1 台にまとまってると、再起動中すべての通信が切られてしまうので、なかなかしんどい。
この記事へのコメント
- Re: Wi-Fi ルーター不安定化の原因調査 by hdk 2017/09/03 (日) 21:43
- PC をルーターにするしか!
- Re: Wi-Fi ルーター不安定化の原因調査 by ARAK@管理人 2017/09/03 (日) 21:58
- NAS 専用機を導入したら常時稼働 PC がなくなるから、それは却下かな〜!
home Re: Wi-Fi ルーター不安定化の原因調査
きのう書いたあとも諦めきれずに、短時間で再現できる負荷テスト (後述) を繰り返し、最終的に『NAT アクセラレーター』機能が原因という説にたどり着いた。 NAT アクセラレーターを無効にするとメモリ使用率は再起動直後 17% で、その後も 17〜19% を維持。 負荷テストをなんなくクリアし、さらに一日経っても変わらず 17〜19% のままなので、ひとまず犯人はこいつだろう。
キーワードがわかってしまえば、事例をぐぐるのは簡単。 ASUS に限らず他社の機種でも NAT アクセラレーターは不安定要因のようだし、QoS や IPv6 パススルーと同時に有効にしちゃダメという情報まで見つかる。 NAT アクセラレーターを有効にすると NAT トラフィックがソフトウェアではなくハードウェアで処理されて高速化できるみたいだけれど、少なくとも Wi-Fi でアクセスする限りそんなスループットいらないしね。
負荷テストというのは、NAS に置いてある大量の音楽ファイルを Windows 10 標準アプリの Groove ミュージックでスキャンさせるだけの簡単な操作。 NAT アクセラレーターが有効なときには 200 曲くらいが限界だった (それくらいでルーターが死んでた) のが、NAT アクセラレーターを無効にすると 3000 曲オーバーでも安定してる。
Groove ミュージックがスキャン中に 1 曲ずつ WAN 側に何か問合せをしてるのか、それともすべて LAN 内のトラフィックで完結してるのか、そこらへんの詳細は不明。 NAT アクセラレーターに影響するんだから、さすがに前者のパターンかな。
何はともあれ、これで平和が訪れた。
座椅子処分 done.
夏休みにぼやいてた粗大ごみふたつ (バブルラジカセ (Panasonic RX-DT99) と座椅子) のうち、座椅子のほうを申請して処分した。 ラジカセはハイベッドの下にすっぽり収まって、ひとまず邪魔になってないので、まだあわてるような時間じゃない。
これで先月の部屋の片付けに起因するゴミ捨ては完了だけれど、整理して捨てたいゴミ (旧 PC 含む) はもう少し残ってる。 年内の連休にサクッと処理したいなあ。 連休の予定は ──
- 9/16 (土)、9/17 (日)、9/18 (祝): 1 日フリーライブに行く
- 10/7 (土)、10/8 (日)、10/9 (祝): 1 日ライブに行く
- 11/3 (祝)、11/4 (土)、11/5 (日): 今のところ空き
── えっ、年内の連休って残りこれだけか! (;´Д`)
Club Microsoft 終了のお知らせ
https://www.microsoft.com/ja-jp/atlife/clubmicrosoft/terminate/default.aspx
Q. 2017 年 9 月 29 日以降、購入済みマイクロソフト製品についてのサポートを受ける必要が生じた場合、製品情報はどのように調べることができますか?
A. 2017 年 9 月 29 日以降は、Club Microsoft に登録いただいた製品情報 (プロダクト ID、プロダクト キー、シリアル番号など) を閲覧いただくことはできません。 ただし、製品情報がなくても購入済み製品についてのサポートを受けていただくことはできます。
この期限が迫ってきた。 今のうちに登録製品の情報をメモっておかねばということで登録製品一覧にアクセスしたのだけれど、「登録されている製品はありません。」と冷たい反応。 おや? 高校時代までに買った開発言語とか、大学時代以降に買ったハードウェアとか、それなりに登録してた気がするんだけどな〜。 あれって Club Microsoft じゃなかったのかなあ。
ま、これといって困りそうな事は特に思い浮かばないので、ないならないでいいや。 登録製品一覧が空っぽだったという事実だけ、ここにメモっておこう。
この記事へのコメント
- Re: Club Microsoft 終了のお知らせ by b 2017/09/06 (水) 23:13
- あーそんなのあったね。ということを思い出したことをここにwメモっておこう。
- Re: Club Microsoft 終了のお知らせ by ARAK@管理人 2017/09/07 (木) 00:09
- 何の意味もないパターン ww
会社支給の定期代を素直に使わない場合の位置付け
http://toyokeizai.net/articles/-/185596
「ポイントは、交通費に関する支給基準があるかどうかです。 たとえば、会社の最寄り駅と自宅の最寄り駅を結ぶ公共交通機関の1か月定期券代相当額などというように、実際にどの交通機関を利用しているかどうかに関わらず、住所地から想定される合理的な金額をあらかじめ会社で決めている場合があります。 この場合は『賃金』とみなされますので、実際には、自転車通勤をしたとしても、返還の必要はありません」
ほほぉ、そういう解釈なのか。
今の会社はまさにこの“会社の最寄り駅と自宅の最寄り駅を結ぶ公共交通機関の 1 か月定期券代相当額”ルールなので、1 年ほど前から使ってる yet another 通勤経路でも返還義務はないみたいだな (自転車じゃなくて電車だよ)。 もちろん、会社が認めてる定期区間に影響しない電車遅延が原因で遅刻すると減給される可能性があったり、通勤中に事故っても労災保険が出ない可能性があったりと、返還義務以外のリスクは承知の上で。
ていうかほんと、今の定期区間は何かと都合がいい。 いっそ会社公認の定期区間が変わるように引っ越したいくらいだが、あの沿線の不動産物件は高すぎて。 宝くじ、当たらないかな〜。
NAS のディスクが満杯に
夏休み中にこのサーバはそろそろディスクが溢れそうと書いたのは記憶に新しいが、あれから一ヶ月持たずにディスクが満杯になってしまった。 できれば 12 月の出費にしたかった (今月は有料イベントの参加予定がない代わりにフレッツ光の回線工事費と WiMAX 2+ の契約解除料がかさむし、来月と再来月は有料イベントがある) けれども、そんな悠長な事は言っていられない。 ぐぬぬ。
というワケで結局、HDD を換装して、NAS であるところの Linux サーバを延命する方針に決めた。 ポチッておいた『Seagate 内蔵ハードディスク 3.5 インチ 4TB BarraCuda ( SATA 6Gb/s / 5400rpm / 2 年保証 ) ST4000DM004』(9,980 円) × 2 台がさっそく届いたので、今週末 HDD 換装。 NAS 向けの HDD じゃないけれども、贅沢は言っていられない。
この記事へのコメント
- Re: NAS のディスクが満杯に by hdk 2017/09/08 (金) 23:06
- 分割払いかな? (・∀・)
- Re: NAS のディスクが満杯に by ARAK@管理人 2017/09/08 (金) 23:38
- 予算的には、先月アニサマに行かなかった分で。 (・∀・)
- Re: NAS のディスクが満杯に by b 2017/09/09 (土) 01:51
- アニサマ理由って便利だよねw そればかりになってるきもするが。
まーでもNASの話は、なんか面倒でやってないのが続く・・。
movie 三度目の殺人
きょう公開された作品。 109 シネマズ二子玉川で観てきた。
法廷ミステリー。 心理サスペンス。 映画館で観るほどではないかもしれないが、地上波でいいところに CM が挟まれると興ざめしそうな展開。
福山雅治演じる弁護士は、勝訴のために真実を知る必要はないと割り切っていたはずなのに、役所広司演じる容疑者の発言が二転三転するうちに態度が変わってくる。 もちろん観客は真実を知りたいわけだが、基本的に明確な証拠が描写されないので、果たして何が答えなのだろうかと、頭を回し続けながら観ることになる。 そして、モヤモヤしたまま迎えるエンドロール。
ああこれひとりで観ちゃいけない作品だ! 観た人と小一時間議論しないとスッキリしない気がする! あでも第 74 回ヴェネチア国際映画祭 コンペティション部門 正式出品作品だから、映画評論家のコメントがたくさん出てくるかな? なーんて考えを巡らせながら帰宅したけれど、さっき『三度目の殺人』というタイトルを打ち込んだときに、真実が見えたかもしれない。 そっか、三度目なのか。 このタイトルがウソでなければ。
広瀬すずは、今週ヴェネチアから配信されてた LINE LIVE よりだいぶ幼く見えた。 撮影されたのは 1 年前だったか 2 年前だったか、だとしても少し幼い雰囲気。 作中の設定には合ってた。
movie anime 機動戦士ガンダム THE ORIGIN V 激突 ルウム会戦 (2 回目)
1 週間前の公開初日と同じく、TOHO シネマズ日本橋で観てきた。 2 週目でも、途中入場や途中退場をする人はほぼいない。
1 週間前に観たばかりの内容で展開を知ってるにもかかわらず、まったく飽きずに観られる不思議。 GG ガス (ダブルジーガス) を使ってからのコロニー落としは、何度観てもえげつない。 戦争じゃなくて殺戮だ。
ミノフスキー粒子の散布が始まったら、エンドロールはすぐそこ。 リミッターを解除してあるシャア専用機がまさにこれから!! というところで終わる。 終わってしまうのである。 タイムマシンが実在すれば、我慢できずに未来に続きを観に行くレベル w
この記事へのコメント
- Re: 機動戦士ガンダム THE ORIGIN V 激突 ルウム会戦 (2 回目) by b 2017/09/10 (日) 02:34
- 案外前から二番目だと自分以外も隣の人もトイレにいった・・。
ただ、気づかれない場所だからなーw 確かにそれ以外は動きはなかったかも。
Linux 自宅サーバの HDD 換装 (3T バイト → 4T バイト)
前回の換装の際に LVM が構築できていれば、今回“換装”ではなく“拡張”ができたのかもしれないが、当時なぜか失敗した記録が残っている。 今回は改めて LVM を構築し、移行することにした。
そして今回の換装で、ようやく RAID1 の片肺運転から脱却できる。 そういう意味では、拡張はどのみち無理だったか。 低発熱 & 低騒音を優先した結果、容量アップ率はそれほどでもないので、また近い将来何か手を打たなきゃだけれど。
容量といえば、遂に 12TB! HGST 製 HDD「Ultrastar He12」が販売スタートというニュースが飛び込んできた。 これはプラッタ 8 枚構成のようだから、1.5T バイトのプラッタかな。 今回の新 HDD ST4000DM004 は、2T バイトプラッタ 2 枚の薄型モデル。 このプラッタが同じ枚数まで増やせたら、いい容量になりそうだ。
¶ LVM on RAID 構築
まず、新しい HDD のデバイス名を確認。
tiger:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 149.1G 0 disk ├─sda1 8:1 0 243.1M 0 part /boot ├─sda2 8:2 0 1K 0 part └─sda5 8:5 0 148.8G 0 part ├─tiger-root 253:0 0 147.3G 0 lvm / └─tiger-swap_1 253:1 0 1.5G 0 lvm [SWAP] sdb 8:16 0 3.7T 0 disk sdc 8:32 0 3.7T 0 disk sdd 8:48 0 2.7T 0 disk └─sdd1 8:49 0 2.7T 0 part └─md1 9:1 0 2.7T 0 raid1 /data tiger:~#SIZE 欄 (3.7T) と MOUNTPOINT 欄 (空欄) から、新しい 4T バイトの HDD 2 台が /dev/sdb と /dev/sdc であることは明らか。 ここ重要。
初めに Linux RAID パーティションを作る。
tiger:~# gdisk /dev/sdb Command (? for help): n Partition number (1-128, default 1): First sector (34-7814037134, default = 2048) or {+-}size{KMGTP}: Last sector (2048-7814037134, default = 7814037134) or {+-}size{KMGTP}: Current type is 'Linux filesystem' Hex code or GUID (L to show codes, Enter = 8300): fd00 Changed type of partition to 'Linux RAID' Command (? for help): w Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!! Do you want to proceed? (Y/N): y OK; writing new GUID partition table (GPT) to /dev/sdb. The operation has completed successfully. tiger:~# gdisk /dev/sdc (/dev/sdb と同様) tiger:~#
次にソフトウェア RAID (RAID1) を作る。
tiger:~# mdadm --create --metadata=1.0 --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sd[bc]1 mdadm: size set to 3907017344K mdadm: automatically enabling write-intent bitmap on large array mdadm: array /dev/md0 started. tiger:~# mdadm --detail /dev/md0 /dev/md0: Version : 1.0 Creation Time : Fri Sep 8 23:14:50 2017 Raid Level : raid1 Array Size : 3907017344 (3726.02 GiB 4000.79 GB) Used Dev Size : 3907017344 (3726.02 GiB 4000.79 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Fri Sep 8 23:16:45 2017 State : active, resyncing Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Resync Status : 0% complete Name : tiger:0 (local to host tiger) UUID : c1849c69:6dfa8174:00c88599:da8b643c Events : 25 Number Major Minor RaidDevice State 0 8 17 0 active sync /dev/sdb1 1 8 33 1 active sync /dev/sdc1 tiger:~#
アレイサイズは 3726.02 GiB 4000.79 GB で、2 台とも active。 ここに LVM の物理ボリューム (PV) を作る。
tiger:~# pvcreate --dataalignment 64K /dev/md0 Physical volume "/dev/md0" successfully created. tiger:~#
今回はうまくいったな。 続けて LVM のボリュームグループ (VG) と論理ボリューム (LV) を作成。
tiger:~# vgcreate tiger_data /dev/md0 Volume group "tiger_data" successfully created tiger:~# lvcreate -l +100%FREE tiger_data -n lvdata Logical volume "lvdata" created. tiger:~#
問題なさそうなので、忘れないうちにソフトウェア RAID の設定内容を mdadm.conf に追記しておく。 (あとで意味なくなったけれど。)
tiger:~# mdadm --detail --scan ARRAY /dev/md1 metadata=1.0 name=tiger:1 UUID=ef859f19:46d4975c:6e633508:b0c9e40f ARRAY /dev/md0 metadata=1.0 name=tiger:0 UUID=c1849c69:6dfa8174:00c88599:da8b643c tiger:~# mdadm --detail --scan | grep /dev/md0 ARRAY /dev/md0 metadata=1.0 name=tiger:0 UUID=c1849c69:6dfa8174:00c88599:da8b643c tiger:~# mdadm --detail --scan | grep /dev/md0 >> /etc/mdadm/mdadm.conf tiger:~#
¶ ファイルシステム構築
ファイルシステムは、例によって XFS でいく。 Optimum RAID によると、パラメータをきちんと設定しないとパフォーマンスが最適化されない雰囲気だが、面倒なので適当に。 こまけぇこたぁいいんだよ!!
tiger:~# mkfs -t xfs -s size=4096 -f /dev/tiger_data/lvdata meta-data=/dev/tiger_data/lvdata isize=512 agcount=4, agsize=244188416 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=0, rmapbt=0, reflink=0 data = bsize=4096 blocks=976753664, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=476930, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 tiger:~#
よし出来た。 旧データ領域は /data のままで、新データ領域を /mnt にマウントしてみる。
tiger:~# mount -o logbufs=8 /dev/tiger_data/lvdata /mnt tiger:~# df -h /data /mnt ファイルシス サイズ 使用 残り 使用% マウント位置 /dev/md1 2.8T 2.8T 5.4G 100% /data /dev/mapper/tiger_data-lvdata 3.7T 3.8G 3.7T 1% /mnt tiger:~#
うむ。 イイ感じ。
¶ 旧 HDD から新 HDD へのコピー
前回使わなかった xfsdump & xfsrestore でいってみる。 おとといのうちにここまで仕掛けてから寝た。
tiger:~# mount -o ro,remount /data tiger:~# xfsdump -J - /data | xfsrestore -J -p 60 - /mnt xfsdump: using file dump (drive_simple) strategy xfsdump: version 3.1.6 (dump format 3.0) xfsdump: level 0 dump of tiger:/data xfsdump: dump date: Fri Sep 8 23:35:21 2017 xfsdump: session id: 0e014dbf-3c1a-4ab2-8ee1-b45c31cec62f xfsdump: session label: "" xfsrestore: using file dump (drive_simple) strategy xfsrestore: version 3.1.6 (dump format 3.0) xfsrestore: searching media for dump (中略) xfsrestore: status at 23:36:21: 17664/18585 directories reconstructed, 95.0% complete, 216264 directory entries processed, 60 seconds elapsed xfsrestore: status at 23:37:21: 2743/255300 files restored, 0.1% complete, 120 seconds elapsed xfsrestore: status at 23:38:21: 4188/255300 files restored, 0.1% complete, 180 seconds elapsed xfsrestore: status at 23:39:21: 4254/255300 files restored, 0.2% complete, 240 seconds elapsed (中略) xfsrestore: status at 00:42:21: 23873/255300 files restored, 10.1% complete, 4020 seconds elapsed (中略) xfsrestore: status at 02:25:21: 41279/255300 files restored, 20.0% complete, 10200 seconds elapsed (中略) xfsrestore: status at 04:06:21: 64637/255300 files restored, 30.4% complete, 16260 seconds elapsed (中略) xfsrestore: status at 05:47:21: 84152/255300 files restored, 40.0% complete, 22320 seconds elapsed (中略) xfsrestore: status at 07:18:21: 110344/255300 files restored, 50.0% complete, 27780 seconds elapsed (中略) xfsrestore: status at 08:44:21: 139094/255300 files restored, 60.1% complete, 32940 seconds elapsed (中略) xfsrestore: status at 10:19:22: 178065/255300 files restored, 70.0% complete, 38641 seconds elapsed (中略) xfsrestore: status at 11:47:21: 190789/255300 files restored, 80.0% complete, 43920 seconds elapsed (中略) xfsrestore: status at 13:12:21: 223609/255300 files restored, 90.0% complete, 49020 seconds elapsed (中略) xfsrestore: status at 14:59:21: 255211/255300 files restored, 99.9% complete, 55440 seconds elapsed xfsdump: ending media file xfsdump: media file size 2995036397856 bytes xfsdump: dump size (non-dir files) : 2994881568160 bytes xfsdump: dump complete: 55496 seconds elapsed xfsdump: Dump Status: SUCCESS xfsrestore: restore complete: 55595 seconds elapsed xfsrestore: Restore Status: SUCCESS tiger:~#
コピー完了まで 15 時間半くらい掛かった。 1T バイトあたり約 5 時間といったところ。 コピー元 HDD もコピー先 HDD も速度重視モデルじゃないので、まあこんなものだろう。
tiger:~# df -i /data /mnt ファイルシス Iノード I使用 I残り I使用% マウント位置 /dev/md1 22842528 273887 22568641 2% /data /dev/mapper/tiger_data-lvdata 390701440 273887 390427553 1% /mnt tiger:~#
使用中の i ノード数を見る限り、全部コピーされてる。
¶ 旧 HDD 取り外し
/etc/fstab と /etc/mdadm/mdadm.conf から旧 HDD 用の記述をコメントアウトし、新 HDD 用の記述を生かした状態で、一度 PC をシャットダウン。
tiger:~# vi /etc/fstab tiger:~# grep /data /etc/fstab #LABEL=data /data xfs logbufs=8 0 2 /dev/mapper/tiger_data-lvdata /data xfs logbufs=8 0 2 tiger:~# vi /etc/mdadm/mdadm.conf tiger:~# grep /dev/md /etc/mdadm/mdadm.conf #ARRAY /dev/md1 metadata=1.0 name=tiger:1 UUID=ef859f19:46d4975c:6e633508:b0c9e40f ARRAY /dev/md0 metadata=1.0 name=tiger:0 UUID=c1849c69:6dfa8174:00c88599:da8b643c tiger:~#
旧 HDD を取り外してから起動確認してみると、なぜか新 RAID が /dev/md0 ではなく /dev/md/tiger:0 で認識されていた。
tiger:~# mdadm --detail --scan ARRAY /dev/md/tiger:0 metadata=1.0 name=tiger:0 UUID=c1849c69:6dfa8174:00c88599:da8b643c tiger:~#
細かいことは気にせず、/etc/mdadm/mdadm.conf をこれに合わせて修正しておいた。 これにて換装完了。
RAID の再同期は、きのうの 23 時ごろに完了した。 コピー開始からここまで、ほぼ 24 時間。
tiger% date ; cat /proc/mdstat 2017年 9月 9日 土曜日 22:58:03 JST Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md127 : active raid1 sdc1[0] sdd1[1] 3907017344 blocks super 1.0 [2/2] [UU] [===================>.] resync = 99.9% (3906374080/3907017344) finish=0.1min speed=79304K/sec bitmap: 1/30 pages [4KB], 65536KB chunk unused devices: <none> tiger% date ; cat /proc/mdstat 2017年 9月 9日 土曜日 22:58:12 JST Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md127 : active raid1 sdc1[0] sdd1[1] 3907017344 blocks super 1.0 [2/2] [UU] bitmap: 1/30 pages [4KB], 65536KB chunk unused devices: <none> tiger%
¶ ところで、未使用の電源コネクタが……
前回の換装の際に、
きょう作業を始めて実際に開けてみると,SATA ポートは 6 つあるのに電源はコードの都合で 5 台しか届かないというちぐはぐな状態だった。 なので,コピー作業中は DVD ドライブに通電しないことにして対処。 ここにこうやってメモを残しておけば,次回は準備万端で作業できるはず!
こんな記録が残してあったにもかかわらず、今回まったく準備してなかったため、同じように DVD ドライブの電源を奪って作業することにした。
筐体を開けてみると、RAID 2 台中 1 台が壊れて片肺運転にしたときに外したと思われる未使用の電源コネクタが、どこにも接続されずにぶら下がってた。 しかし、明らかに様子がおかしい。 コネクタの黒い部分の半分くらいが炭化していて、手に取った瞬間ボロボロに……!?
マザーボード上のヒートシンク (CPU ではないチップセットか何かのやつ) に触れ続けていたので、熱で溶けたか。 いくらなんでもこれは危ない。 危なすぎるよ。 ほかの部品が壊れたり、ショートして火事になったりしていなくて良かった、マジで……!!
左側が正常なコネクタで、右側が半分溶けたコネクタ。 この 2 股のコードは廃棄して、残りの電源 4 本でやりくりすることに。 旧 RAID が片肺運転になってたおかげで、DVD ドライブへの通電を犠牲にすればギリギリ足りるのであった。
最終的に旧 HDD を取り外しても DVD ドライブには電源コードが届かない。 Linux サーバの DVD ドライブを使うことはまずないから、このままでいいや。
この記事へのコメント
- Re: 自宅サーバの HDD 換装 (3T バイト → 4T バイト) by b 2017/09/10 (日) 23:19
- 案外焦げ臭いがした時もあったんじゃないかね。
- Re: 自宅サーバの HDD 換装 (3T バイト → 4T バイト) by ARAK@管理人 2017/09/11 (月) 21:26
- 可能性あるよねぇ。 こわいこわい。