LVS で IPIP と DR(DSR) を用いる場合のパケット解釈フローについて、雑に図を起こしたので Web へ放流しておきます。
リンク先にオリジナルサイズもあります。
ホワイトボードを写真に撮ったレベルでツッコミどころもありますが、新人に聞かれて説明するときのお供に便利かもしれません。
keepalived + ipvs + tunl0 + lo0 の構成は文章で説明するにはややこしすぎるので、解説するためにこういう図を何度もホワイトボードに書いた覚えがあります。
↧
雑な LVS/TUN の解説図
↧
Debian で NIC offload を無効にする方法
rc.local に書くみたいな雑な手法ではない王道はなにか？
結論から言うと interfaces に offload-lro off とか書ける。
# grep -A3 eth2 /etc/network/interfaces auto eth2 iface eth2 inet manual offload-lro off bond-master bond0 #
Debian のお作法として、 rc まわりの情報は /usr/share/doc/${該当機能を操作するコマンド名}/README.Debian に置いておくものらしい。
例えば /usr/share/doc/ifenslave/README.Debian.gz には、 bonding をやりたいとき interfaces にどう書けば良いかドキュメンテーションされている。
検証環境は Debian 8 Jessie です。他ディストロから来て *NIX お作法の範囲で探すんでは気づきようがなかったので、せめてポインタぐらいは man interfaces に書いといてくれとは思いました。
なお今回は、別のアプローチでググっている時に、たまたま下記が引っかかったからヒントになって発見できた。
ethtool for Debian ------------------ Most settings that can be controlled through ethtool can be specified in /etc/network/interfaces. They will then be applied to interfaces that are brought up automatically at boot time or using the 'ifup' command. The following settings are supported: Link mode (--change): link-speed <speed> link-duplex half|full Ethernet settings (--change): ethernet-autoneg on|off|<mask> ethernet-port <port> ethernet-wol <mode> [<pass-key>] Driver control (--change): driver-message-level <level> Ethernet flow control (--pause): ethernet-pause-rx on|off ethernet-pause-tx on|off ethernet-pause-autoneg on|off Protocol offload (--offload): offload-rx on|off offload-tx on|off offload-sg on|off offload-tso on|off offload-ufo on|off offload-gso on|off offload-lro on|off (etc.) Hardware tuning (--coalesce, --ring): hardware-irq-coalesce-adaptive-rx on|off hardware-irq-coalesce-adaptive-tx on|off hardware-irq-coalesce-rx-usecs <n> hardware-irq-coalesce-rx-frames <n> (etc.) hardware-dma-ring-rx <size> hardware-dma-ring-rx-mini <size> hardware-dma-ring-rx-jumbo <size> hardware-dma-ring-tx <size> Example: iface eth0 inet dhcp link-speed 100 link-duplex full ethernet-autoneg off ethernet-wol s 46:65:62:69:61:6e -- Ben Hutchings <ben@decadent.org.uk>, Sat, 4 Jun 2011 20:37:08 +0100http://metadata.ftp-master.debian.org/changelogs/main/e/ethtool/stable_README.Debian
些細な内容だけど、ググってロクにドキュメント出てこなかったのでここに記す。
↧
↧
Amazon Dash 2nd Generation を分解
Amazon Dash ボタンが日本上陸！ TELEC 201-160049
amazon.com を見たところ AWS IoT Button 2nd Generation なるものが。これはきっと日本で販売されているボタンは TELEC 通した 2nd Gen に違いない！
ってことで買って分解してみました。
もろもろシールを剥がしてみましたが、 1st Gen にはあったネジが見当たらず。
超音波溶着と判断して強引に剥がします。
パカッ。
2nd Gen では電池ボックスになっています。
また、付属の電池がリチウムからアルカリ電池へ変更になっています。
続いてネジ(T5)を外して基板を外します。
パカッ。
以上で分解は終了です。丹念に眺めていきましょう。
バッテリー面は 25Q032 13E40 というシリアル接続フラッシュメモリがあります。
もいっこのチップは不明。電源用と思われるコイルとマイクが気になります。マイクはなんで付いてるんでしょう？
J2 というコネクタが付きそうなランドも気になります。
裏面はこのようになっています。
目立つ部品は MCU (後述)と WiFi コンパニオンチップです。 ATWINC1500B - "single chip IEEE802.11 b/g/n Radio/Baseband/MAC network controller optimized for low-power mobile applications" でした。
中央の黒いチップにはマーキングがあるのですが、マイクロスコープの手持ちがなく裸眼では読み取り不能でした。 WL-CSP のチップが 4つほどあるのですがこちらも判別不能です。
また、同軸コネクタもありますね。
大きな黒いパッケージはスポンジが両面テープでついているだけなので剥がせます。
ATSAMG55J19 SMART SAM G55 - "a series of Flash microcontrollers based on the high-performance 32-bit ARM Cortex-M4 RISC processor with FPU (Floating Point Unit)." が出てきました。これが主役でしょう。
以上、楽しいボタングラビアでございました。リチウム電池からアルカリ電池に変わったのに 2000回持つようになったのが面白いところですかね？
ケース構造だけでなく、基板構成もだいぶ変わっているようです。 WiFi コンパニオンのシールドがなくなったのも目立つところだけど、 STMicroelectronics, Broadcom の組み合わせから両方とも Atmel になったってのも興味深い。
カメラ忘れてスマフォにてお粗末様でした。
↧
YAMAHA ルータと Splatoon 2
結論から言うと、ヤマハルータの Rev.14.01.09 以降ではデフォルトだと Splatoon 2 が動かないが、 nat descriptor backward-compatibility 1 を叩くと動くようになる。
背景
RTX1210 で動いている WiFi に Nintendo Switch を繋いで遊ぼうとしたら、まったく動かない。マッチを始めるとエラーコード 2618-0513 で「相手のゲーム機と通信できませんでした」と表示され失敗するし、 10回に 1回ぐらいはマッチングが始まるが 8人揃わず制限時間を迎える。(制限時間がちょくちょく伸びるので対戦者を追加しようとして失敗してる様子)
調査
マッチングのときに出る問題であることと、NAPT箱が異なる別のネットワークでは正常に動くので、まあ NAPT越え(NAT traversal)まわりやろと当たりをつけた。
Switch の接続テストでは「NATタイプ B」と表示される。
比較的インターネット経由での対戦・協力プレイが行いやすい環境です。
https://support.nintendo.co.jp/app/answers/detail/a_id/34273?a_id=34278
大雑把に RFC 3489 の分類ではどれなの？ということで、What is My IP & NAT - STUNner - Google Play の Android アプリを動かしてみたところ、 "Network Type: Symmetric cone" とのこと。
Symmetric NAT は UDP hole punching が効かないのでダメそう。
Symmetric NAT になる実装はあんまり多くなく*1、知ってる範囲だと OpenBSD pf(4) のデフォルト(static-port オプション無し)ぐらいなので、不思議に思って RTX のドキュメントを探したところ、そのものずばりのものがあった。*2
曰く、ポートセービングIPマスカレードなる機能が Rev.14.01.08 で追加され、これは Symmetric NAT 相当の振る舞いでありデフォルトで有効となっている。
対策
マニュアルどおり nat descriptor backward-compatibility 1 を叩く。
# nat descriptor backward-compatibility 1 NAT backward-compatibility setting has been configured. Please save config and restart router to enable new setting. # save Saving ... CONFIG0 Done . # restart
STUNner を動かしたところ "Network Type: Port restricted cone" に変化し、 Splatoon 2 も速やかにマッチが終わり問題なく遊べるようになった。やったー！！
未解決の疑問点
2つある。
まず、 Symmetric NAT にもかからず、なんで "NATタイプ B" になるんだろうか？ Nintendo Switch の NATタイプ判定に考慮漏れがありそうだが、そもそも rfc3489 が廃止になっちゃうぐらい NAT traversal は複雑奇っ怪なので、しょうがない気はする。
次に、 NAT動作タイプの違いについて によると Rev.14.01 系以降でも TCP 以外のすべてのプロトコルでは従来の(ポートセービングIPマスカレードではない) NAPT になるとあり、 Splatoon 2 は UDP なので、本来はデフォルトのまま動くはずである。が、動かなかった。
もっと言うと nat descriptor backward-compatibility を変更しても変化が無いはずだが、改善した。これはなぜか？実は UDP の挙動も変わってしまっている？
Nintendo Switch の挙動
Nintendo Switch は UPnP に対応していない模様。 UDP 1900 をまったく投げない。 CGN で二重 NAPT になっていることが多いからやめちゃったのだろうか？
また、 Splatoon 2 は UDP フルメッシュで通信し、マッチ中に UDP が届くか相互にパケットを投げて確認しています。サーバが選出されるようなアーキテクチャではないようで、 8台がすべて相互に通信できる必要があります。
Symmetric NAT
今回はトラブルに遭遇してしまったけれども、ポートセービングIPマスカレード自体は良い機能だと思う。 * cone NAT だと振る舞い上、変換後の送信元ポート数(16bit)でセッション数が制限されてしまうので、グローバル IPアドレスあたりの集約率に限界がある。
しかし、 Symmetric NAT なら宛先 IPアドレスが異なれば送信元ポートを共有できるので大幅に集約率を向上できる。例えば Webクローラーを含む数千台のサーバを 1 IPアドレスに収容するといった芸当も可能で、事例も知っている。
しかし、 CGN で導入すると今回のように NAT traversal でクレームが上がりそうだし、 abuse 問い合わせで src port だけでなく dest ip まで必要になるので、(Webサービスなどで)サーバ側のグローバル IPアドレスを含むログを取得しているのかといった問題がでてくるので、ちょっと難しそうであった。
RTX1210 の用途を考えると良い機能だな、と思います。
結論
NAPT むづかしい
STUNner
STUNner はこんな感じで大変便利なツールでした。
RTX1210 ポートセービングIPマスカレード
RTX1210 nat descriptor backward-compatibility 1
↧
Amazonベーシックの激安 Type-C Ethernet Adapter
345円だったので迅速にポチり速やかに手元の Linux 端末に刺し dmesg を採取しました。
Realtek RTL8153 である模様です。
[715761.336406] usb 2-3: new SuperSpeed USB device number 2 using xhci_hcd [715761.357259] usb 2-3: New USB device found, idVendor=0bda, idProduct=8153 [715761.357264] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [715761.357267] usb 2-3: Product: USB 10/100/1000 LAN [715761.357269] usb 2-3: Manufacturer: Realtek [715761.357271] usb 2-3: SerialNumber: xxxxxx000000 [715761.400477] usbcore: registered new interface driver r8152 [715761.406816] usbcore: registered new interface driver cdc_ether [715761.524592] usb 2-3: reset SuperSpeed USB device number 2 using xhci_hcd [715761.601809] r8152 2-3:1.0 eth0: v1.08.8 [715761.630520] r8152 2-3:1.0 enx3c18a0xxxxxx: renamed from eth0 [715761.670409] IPv6: ADDRCONF(NETDEV_UP): enx3c18a0xxxxxx: link is not ready [715761.698715] IPv6: ADDRCONF(NETDEV_UP): enx3c18a0xxxxxx: link is not ready
USB Type-C が刺さる端末をお使いであれば、 345円なら買いましょう。
Amazonベーシック USB3.1タイプC - イーサネットアダプター Mac/PC両対応 ブラック
- 出版社/メーカー: AmazonBasics
- メディア: Personal Computers
- この商品を含むブログ (1件) を見る
追記
Nintendo Switch で認識し無さそうでございました
↧
↧
川崎駅
久しぶりに川崎に来たら、アゼリア入り口がたいへん綺麗になっていてびっくり仰天ですよ。
でも変わらないところもある。
↧
梶が谷駅
始発まで酒飲んだ帰り道、朝焼けの梶が谷駅。
夜景は、人間の目玉よりデジカメの方が、綺麗に写せると思う。
しっかし、いざ写真を撮ってみると、もっとダイナミックレンジ欲しいとか RAW 使いたいとか色々欲求が出てくるなぁ。だがお手軽さも諦めたくないでござる。
↧
■
同一 URL でスマートフォンと PC を出し分けたい vs (キャッシュ出来なくなるので URL 分けるべき or 同一コンテンツで表示変わるようすべき)
みたいな議論を聞いていると、 HTTP レイヤでのキャッシュに用いる key を見直すべき時期に来ているのかなぁ、と思ったりする。
↧
NEX-5R で遊ぶ
お手軽コンデジよりあきらかにムズい。デジカメの性能を試そうなので構図が酷いのはご愛嬌。
まずオートフォーカス時々効かなくて、手ブレよりピンボケ写真を量産したので、 DMF か MF で合わせた方が良い。
気合があればシャッタースピード 1.3秒でもブレないので ISO400 ぐらいは使える。むしろピント合わない。
上の ISO400 と比較すると ISO3200 やっぱノイジー。空とか。
高感度撮影するなら連射合成したほうがノイズは少ない。
しかし、下の ISO400 と連射合成で、遠景部分を見てると、彩度が落ちるのか、やっぱり連射合成しないほうが好みな写り方をする。フォトライフの画像縮小がちょっと微妙なので拡大して見た方が良い。
ちなみに、各写真とも連射合成の場合ホワイトバランスが正しい感じになっているのは、多分カメラが勝手に AWB ではなく適当なホワイトバランスに固定しているから。ナトリウムランプなのでオレンジ色に写るのが正しいので、 AWB から蛍光灯あたりに固定するのが良さげ。
なんというか、一番気に入った子の写真が手持ち夜景モードである辺り、素直にカメラに任せた方が一番綺麗なのではないかという疑惑はある。今度は手持ちじゃない方の夜景モードであるとか、レタッチ前提の撮り方も試してみよう。
ホワイトバランスを蛍光灯に、 ISO400 ぐらいで撮影、 DMF でピント合わせる、ぐらいが得られた知見だった。
それなりにちゃんとしたカメラを使うと、 NIKON P300 のお手軽っぷりを再認識出来る…。テキトーに撮ってもソコソコ綺麗に撮れる。
↧
↧
SSD に関する雑感
- SSDは block erase やら wear levelingで作業領域としての DRAMに大きく頼らざるを得ない。
- 電源断により DRAMの dirty な領域が消失することを考慮しながらメタデータの破損を防ごうとすると、 DRAM -> NAND の書き込み順序に強い制約が生じ、高速化に支障を来す。(ファイルシステムにおけるそれと同じように)
- DRAM with BBU を仮定すると、ファームウェアが書き込みの順序をイジる自由度が大幅に増す。
- HDD と違い、 NAND は短時間ならキャパシタの電力で書き込みを行うことが出来るので、 SSD内部での DRAM with BBU が容易であり広く普及するだろう。
- 安価な SSDであっても、コントローラは数十チャンネルの NAND インターフェイスを持ち、それぞれを並列に動作させることが出来る。
- 多チャンネルの NAND インターフェイスと、 BBU で保護された DRAMがあれば、並行な I/O 要求や block erase, ware leveling を強力に最適化したファームウェアを書けるので、 SSDは大幅に高速化する。
- ケミカルコンデンサも電気二重層コンデンサも経年劣化で容量が減るので、バックアップされてるはずだったが実は容量が足りなくて消えた！という事故が今後 10年ぐらいで起きるだろう。
- コンシューマ向けのくだりで定期的な交換は不要と言っているが、全体の製品寿命に対しては十分な寿命があり問題ない、と考えている。(マザーボード上のキャパシタ同様)
- 電源断についてあーだこーだ書いたが、私が欲しいのは「電源断でも壊れない堅牢なストレージ」ではなく、「電源断を恐れずに高度に性能を追求したストレージ」である。
- もちろん電源断でも壊れない方が良いです。
- 電源断まで厳密に保証したミッションクリティカルなストレージを選んで使うより、ノード冗長を取る方が低コストである。
- ノード冗長の副次的な作用としてオペミスに強くなるというのも、個人的に重視している。
- 他にも色々ありますが、大体こういう思想です。 http://nippondanji.blogspot.jp/2009/03/ssd.html
- 商用 UNIXでカチカチに固めた環境じゃないし、一度電源断したホストの DB を使いつづけたりしないでしょ。
- Linuxなんてファイルシステム・ブロックデバイスレベルでテキトーなので、 kernel panic したら一巻の終わり。
つらつら書きましたが、上のようなことを考えながら日々 SSDを使っています。
私は SSDを作る人ではないし、最新の Linux kernel について深い知見があるわけではないので、 Linux kernel hacker からすれば最近の kernel なら問題ないという意見が出てくるでしょうし、 NAND ストレージベンダーからすればツッコミどころ満載かと思いますが、あくまでこういう考えの奴も居るということで。
↧
Comet 的な HTTP トラフィックのベンチマークを weighttp でやってみる
HTTP コネクションは張ったままだけど大して通信しないという、いわゆる Comet のような負荷をベンチマークするのは意外と難しい。
以下の patch を当てた weighttp でベンチマークすると良い感じだった。 weighttp はいわゆるベンチマークツールだが、軽量かつイベントドリブンなのでコネクション数について良くスケールする。
** worker.c.orig 2013-04-01 16:59:12.000000000 +0900 --- worker.c 2013-04-01 17:06:02.000000000 +0900****************** 17,22 ****--- 17,23 ---- worker = W_MALLOC(Worker, 1); worker->id = id; worker->loop = ev_loop_new(0); + ev_set_io_collect_interval(worker->loop, 3); ev_ref(worker->loop); worker->config = config; worker->num_clients = num_clients;
上記パッチを当てると、トラフィックは 3秒に 1回ぐらいしか流れなくなりぬるくなる。コネクション数以外の部分では当たらなくなるので好都合。
こいつを使ってクライアント 10台ぐらいで nginx をイジメると簡単に C10K を突破する。ソースポートの数とか色々当たってくるので、(頑張ればもっと張れるのは知っているが)クライアント 1台あたり数千〜数万コネクションに抑えた方が面倒は無い。
参考
weighttp 自体は以下を見て知ったので、詳細は直接見た方が早い。 ulimit まわりの話もあります。
http://www.iij.ad.jp/company/development/tech/activities/weighttp/
↧
サーバ用途でコンシューマ SSD へ調子に乗って書き込みすぎると壊れるという話
Crucial M500 の write endurance が 75TB しか無いというのが話題になっていて、同じく 75TB である m4 をわざと虐待していたホストはどうなったのか気になって調べて見たところ、面白い結果が観測されたという話。
石橋を叩いて壊し障害時の挙動を見るべく「自社全サービスのアクセスログを受け止める syslog サーバ」という、どう見ても書き込み中心で SSDにやさしくないホストをあえて動かしていた。具体的には下記のようなノリのホストである。 iostat の一行目なので uptime数百日における平均値であることに注意。
[root@touge ~]# iostat -k -x -d sda | sed -n '3,4p' Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 27.36 414.31 47.72 82.46 2902.21 3431.04 97.30 0.39 2.96 0.62 8.04 [root@touge ~]#
平均で 3431KB/s 出ている。上記は HV 上での値なので、 VMの block device layer における write merge 前では write 900IOPS ぐらい。
SMART Attribute を確認して見たところ、 14ヵ月でだいぶ磨り減ったことが観測された。*1 202 Perc_Rated_Life_Used は保証期間に関する値で、書き込みまくって VALUEが 0 になるとメーカ保証の範囲外となる。 Percは Percentage の略で、 RAW VALUEは「何パーセント使ったか」であろう。
[root@touge smartmontools-6.1]# ./smartctl -i /dev/sda | egrep '(Model|Firm|Capa)' Model Family: Crucial/Micron RealSSD m4/C400 Device Model: M4-CT512M4SSD2 Firmware Version: 0309 User Capacity: 512,110,190,592 bytes [512 GB] [root@touge smartmontools-6.1]# ./smartctl -A /dev/sda | egrep '^(ID| 5| 9|173|195|202)' ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 9 Power_On_Hours 0x0032 100 100 001 Old_age Always - 13748 173 Wear_Leveling_Count 0x0033 033 033 010 Pre-fail Always - 2018 195 Hardware_ECC_Recovered 0x003a 100 100 001 Old_age Always - 106 202 Perc_Rated_Life_Used 0x0018 034 034 001 Old_age Offline - 66 [root@touge smartmontools-6.1]#
m4 の保証値である 75 TB を 3431KB/s で焼きつづければ単純計算で 271日なので、そら当たり前だろうという話ではあり、設計段階から分かっててわざとやった結果である。むしろ 3.4MB/s で 426日ほど*2焼きつづけたのにまだ 1/3 残ってることが驚きである。 2.35倍ぐらい持っている。
173 Wear_Leveling_Count の RAW VALUEも興味深い。 25nm 世代 NAND の書き換え回数が 3000回なので、これがページの平均書き換え回数だと色々しっくりくる。
14ヵ月で 1/3 まで減っているので、単純計算すると上記の使い方でこいつは 2年弱しか持たない。実環境の最悪値かつ保証が切れるだけだが「容量が手狭になるまで持てばいい！」で済ますには微妙なラインである。
結論
最近の*3コンシューマ向け SSDは書き込みまくる用途だと壊れうる。
常日頃から「SSDは壊れない」とか言っていますが、これは「お前が言ってる書き込み量はバーストの値*4でライフサイクル平均でそんな書いてる訳じゃないだろ」ないしは「DB 用途でヘビーに使っていても実は書き込みは*5そんなに多くない」という側面が強く*6、裏を返せばライフサイクル平均で書き込み量が重くのしかかる用途だと寿命を気にする必要がある。
気にする必要がある、なので、たとえば「同じぐらいの平均書き込み量で 10台ストライプするから 4000日=11年ぐらい保証の範囲で使えるので大丈夫だろう」なり、「書き込み 3倍あって同じく単体で使う予定だから 4ヵ月でいつ壊れてもおかしくない」という話ではある。
コンシューマ向け SSDも登場から年月が経ち、各ベンダーとも読みが正確になってきたのかマージンが削られる傾向にある。*7エンタープライズ向け SSDを選択肢に入れるなど、きちんと書き込み量のキャパシティプランニングを行う必要がある時期に達しつつあるのではないだろうか。
備考
以下は、生の smartctl 出力と備考。
- TRIM を使っていないので消耗が激しくなっている可能性がある
- VM側のアライメントは合わせてある(はず)
- 容量の 80% ぐらいをファイルで埋めている
- これは極端な例なので他の多数の m4 は 8割 9割残っている
- 202 Perc_Rated_Life_Used の RAW VALUEは 100% を越えて動く模様
- この手の値をグラフにしようってのいい加減手をつけろ >self
- サーバにおいて「ピーク MB/s」みたいな微分やピークには敏感だが「積算 MB」のような単位は未経験で勘が鈍いのではないか
- 積算で効くのは稼働時間ぐらいしか思いつかないが時間の流れる速さは大体一定である
[root@touge smartmontools-6.1]# ./smartctl -iA /dev/sda smartctl 6.1 2013-03-16 r3800 [x86_64-linux-2.6.18-238.19.1.el5xen] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Crucial/Micron RealSSD m4/C400 Device Model: M4-CT512M4SSD2 Serial Number: 00000000111403056xxx LU WWN Device Id: 5 00a075 103056783 Firmware Version: 0309 User Capacity: 512,110,190,592 bytes [512 GB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 6 SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Tue Apr 16 19:54:36 2013 JST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 100 100 050 Pre-fail Always - 0 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 9 Power_On_Hours 0x0032 100 100 001 Old_age Always - 13747 12 Power_Cycle_Count 0x0032 100 100 001 Old_age Always - 7 170 Grown_Failing_Block_Ct 0x0033 100 100 010 Pre-fail Always - 0 171 Program_Fail_Count 0x0032 100 100 001 Old_age Always - 0 172 Erase_Fail_Count 0x0032 100 100 001 Old_age Always - 0 173 Wear_Leveling_Count 0x0033 033 033 010 Pre-fail Always - 2018 174 Unexpect_Power_Loss_Ct 0x0032 100 100 001 Old_age Always - 1 181 Non4k_Aligned_Access 0x0022 100 100 001 Old_age Always - 65535 44819 28690 183 SATA_Iface_Downshift 0x0032 100 100 001 Old_age Always - 0 184 End-to-End_Error 0x0033 100 100 050 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 001 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 001 Old_age Always - 0 189 Factory_Bad_Block_Ct 0x000e 100 100 001 Old_age Always - 323 194 Temperature_Celsius 0x0022 100 100 000 Old_age Always - 0 195 Hardware_ECC_Recovered 0x003a 100 100 001 Old_age Always - 106 196 Reallocated_Event_Count 0x0032 100 100 001 Old_age Always - 0 197 Current_Pending_Sector 0x0032 100 100 001 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 001 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 100 100 001 Old_age Always - 0 202 Perc_Rated_Life_Used 0x0018 034 034 001 Old_age Offline - 66 206 Write_Error_Rate 0x000e 100 100 001 Old_age Always - 0 [root@touge smartmontools-6.1]#
m4 の話ばっかりしてるけど、 Intel, Samsungも同等以上にバンバン使っているので、そいつらも取り上げていきたい。
↧
昔の SSD はタフだった
d:id:halfrack:20130417:1366193468を見た同僚が教えてくれた X25-M G2 のホストについて、古い SSDはマージンたっぷりだったという話。
このホストは DB サーバだが、メッセージングサービス的なものに使われているので、更新ヘビーで辛い DB になる。
[root@nantokagoe smartmontools-6.1]# uptime 19:29:02 up 1028 days, 2:49, 2 users, load average: 0.00, 0.05, 0.04 [root@nantokagoe smartmontools-6.1]# iostat -k -x -d sda | sed -n '3,4p' Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 0.12 246.21 114.24 260.99 1434.11 6111.88 40.22 0.02 0.19 0.11 4.19 [root@nantokagoe smartmontools-6.1]#
書き込み量は前エントリの倍近いレートの 6.1MB/s である。
しかし、 SMART Attribute を確認すると、この書き込み量で 36ヵ月以上虐待し続けたにも関わらず、 233 Media_Wearout_Indicator は 39% 残っている。*1
[root@nantokagoe smartmontools-6.1]# ./smartctl -i /dev/sda | egrep '(Model|Firm|Capa)' Model Family: Intel X18-M/X25-M/X25-V G2 SSDs Device Model: INTEL SSDSA2M080G2GN Firmware Version: 2CV102G9 User Capacity: 80,026,361,856 bytes [80.0 GB] [root@nantokagoe smartmontools-6.1]# ./smartctl -A /dev/sda | egrep '^(ID| 5| 9|225|233)' ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0032 100 100 000 Old_age Always - 164 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 26935 225 Host_Writes_32MiB 0x0030 200 200 000 Old_age Offline - 16741249 233 Media_Wearout_Indicator 0x0032 039 039 000 Old_age Always - 0 [root@nantokagoe smartmontools-6.1]#
225 Host_Writes_32MiB に至っては RAW VALUEがカンストしてしまっていて、メーカー想定外の酷い使い方である雰囲気を感じる。また、この値を信じるなら最低でも 535TB は書き込んでいることとなり、 X25-M G2 公称値の 15TB を 35回ほどブッちぎっている。ほんと良く壊れてないなこいつ。
結論
危険側に倒さなそうなメーカの初期製品は、マージンもりもりで美味しい。*2
初期の製品だったので、ありとあらゆるところを安全側に倒してこの SSDを Intelは設計・開発したのだろう。また、 X25-M G2 の NAND は 34nm のものであり 5000回の書き換えに耐え、最近の微細化が進んだ NAND より書き込み量の面で大きな余裕がある。
備考
以下備考と全ログ。
[root@nantokagoe smartmontools-6.1]# ./smartctl -iA /dev/sda smartctl 6.1 2013-03-16 r3800 [x86_64-linux-2.6.18-164.11.1.el5xen] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Intel X18-M/X25-M/X25-V G2 SSDs Device Model: INTEL SSDSA2M080G2GN Serial Number: CVPO942000660xxxxx LU WWN Device Id: 5 001517 9590b6814 Firmware Version: 2CV102G9 User Capacity: 80,026,361,856 bytes [80.0 GB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Device is: In smartctl database [for details use: -P show] ATA Version is: ATA/ATAPI-7 T13/1532D revision 1 SATA Version is: SATA 2.6, 3.0 Gb/s Local Time is: Wed Apr 17 19:58:37 2013 JST ==> WARNING: This drive may require a firmware update to fix possible drive hangs when reading SMART self-test log: http://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=18363 SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 5 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 3 Spin_Up_Time 0x0020 100 100 000 Old_age Offline - 0 4 Start_Stop_Count 0x0030 100 100 000 Old_age Offline - 0 5 Reallocated_Sector_Ct 0x0032 100 100 000 Old_age Always - 164 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 26935 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 31 192 Unsafe_Shutdown_Count 0x0032 100 100 000 Old_age Always - 18 225 Host_Writes_32MiB 0x0030 200 200 000 Old_age Offline - 16741652 226 Workld_Media_Wear_Indic 0x0032 100 100 000 Old_age Always - 65535 227 Workld_Host_Reads_Perc 0x0032 100 100 000 Old_age Always - 65535 228 Workload_Minutes 0x0032 100 100 000 Old_age Always - 65535 232 Available_Reservd_Space 0x0033 098 098 010 Pre-fail Always - 0 233 Media_Wearout_Indicator 0x0032 039 039 000 Old_age Always - 0 184 End-to-End_Error 0x0033 100 100 099 Pre-fail Always - 0 [root@nantokagoe smartmontools-6.1]#
Intelばかり立てて Micron 落としてる感じだが、 Intelも 25nm 製品の初期ロットで何回か初期不良に遭遇したりとかあるので、どっこいどっこいかと思います。
↧
↧
警察庁の有識者は torrc.sample も読んでいないのではないだろうか
念のため強調しておきますが、個人の見解なので誤りなど多分に含まれうるものです。ご注意を。
発信元の特定を困難にする匿名化システム「Ｔｏｒ（トーア）」を悪用した犯罪対策を検討していた警察庁の有識者会議は１８日、サイト管理者の判断で通信を遮断することが抑止に効果があるとする報告書をまとめた。警察庁は提言を踏まえ、インターネット接続事業者の業界などに自主的な取り組みを促す。
http://mainichi.jp/select/news/20130418k0000e040232000c.html
(中略)
具体策として、同システムが経由地に使うパソコンのうち、最後の３台目に割り当てられたＩＰアドレスの一覧が公開されている点に着目。このＩＰアドレスからアクセスがあった場合、通信を遮断するようにすれば犯罪抑止に一定の効果があると提言した。
コンテンツサービスプロバイダ(CSP)側で Tor によるアクセスの遮断を警察が要請するそうで。ここでは原文に当たった上で CSP サイドでのフィルタと判断し議論します。*1
CSP 側によるフィルタリングも Tor は考慮している*2んですが、有識者の皆様におきましては torrc.sample ぐらいはお読みになられたのでしょうか。
177 ## Bridge relays (or "bridges") are Tor relays that aren't listed in the
https://gitweb.torproject.org/tor.git/blob/release-0.2.4:/src/config/torrc.sample.in
178 ## main directory. Since there is no complete public list of them, even an
179 ## ISP that filters connections to all the known Tor relays probably
180 ## won't be able to block all the bridges. Also, websites won't treat you
181 ## differently because they won't know you're running Tor. If you can
182 ## be a real relay, please do; but if not, be a bridge!
183 #BridgeRelay 1
ISPサイドでのフィルタリングについては、凄いコストを ISPに強いることになるわ、通信の秘密とは何だったのかとなるわ、挙句の果てに Tor の仕組みから全然効果が無いので言語道断だと思います。
CSP サイドでのフィルタリングも上記の仕組みにより面倒くさくする程度の効果しかなく、例えば Socks Proxy たる Tor の先に国外の野良 HTTP Proxy を挟むという手法で突破出来、*3効果が無いでしょう。
多段プロキシによるTorのExitノードの隠蔽についてが追試せんでも見りゃ分かる良い資料*4ですね。
雑感
- 「我が国に Tor は不要」*5という内容の発言をしちゃうような人が警察側に居る事実より、匿名であることを技術的に担保出来る仕組みの存在は非常に重要であると認識を新たにしました。
- 某市政とか見てると日本においても「政府の弾圧」が無いとは言いきれないと思うので、遮断するんであれば日本を中国と同等の国にする覚悟が必要かと思います。(それが
貶良いことかどうかはお読みの方にお任せします。) - というか、前述の仕組みもあり某検閲先進国の金盾でも Tor を止められないのですが、日本なら出来ると考えてるんですかね？
- 便所の落書き程度の追跡性しか無い代物に過剰な反応してるのがそもそもの間違いだと思います。
- 便所の落書きを書いた奴が発覚した場合の対応を考えるに、犯行予告は呼び出して事情聞いて要注意人物として様子見るぐらいが正しいんではないか、というのが個人的見解です。*6
- Tor 自体の研究すべきだが民間じゃ利益が出ないのでうんぬんとあるけど、お前どの口でそれを言っているのかと(ry
- その受け皿たる国立研究機関をドンドン追い出したツケですねアホー
- 匿名化システムを作り動かす研究とそれを突破する研究は表裏一体
- Tor より先に、スパマーなりアタッカーなりを通報しても、踏み台の中に海外 IP アドレスが出てくるだけで諦めちゃうのをどうにかした方がよっぽど有益じゃないでしょうかね。
- Tor を解析出来たとしても、接続先ノードが海外だったらどうするの？
- 黒子のバスケ事件はどうなったんだろう？
あ、武雄市とか中国が嫌いな人たちはお呼びでないです。武雄市とか中国が嫌いな人たちはお呼びでないです。大事なことなので二回言いました。
結論
「Tor ノードをブロックしても効果無いでしょ」という指摘が 2013/4/23 の時点で存在していることが重要だと思うので、ここに記す。
ちなみに私は、商取引など匿名や追跡可能性の欠如が問題となるサービスについては、デジタル署名出来る IC カードやワンタイムパスワードトークン等の下層の安全性に左右されない認証方法を用いるか、フレッツ網や携帯電話網みたいな管理された閉域網でやれ、という立場でございます。
そもそも Tor を悪用されて困るような使い方を、有象無象が繋がるインターネットの上でしてはいけない。
*1:誤読してる人も多いので、新聞記者各位には「インターネット接続事業者(ISP)」の狭義の意味と、その文脈における「コンテンツ(サービス)プロバイダ(CP/CSP)」という用語の意味を理解して記事とか書いてほしく思います。
*2:なお、 ISP側によるフィルタリングに対してはさらに効果がない。
*3:多段プロキシとかガキでも思いつく
*4:悪用するものには常識であり利益が無く、悪用しないものにはリスクを犯さず概要が理解出来る。
*5:原文当たらずに批判する人は躓いて転べば良いと思っているのでワザと表現変えました。「サイバー犯罪捜査の課題と対策」部会 第3回 7ページを参照。
*6:正しいリスクマネジメントの出来ない人は嫌いです。
↧
chown -R による壊滅的な状況を切り抜ける方法
ある日、ぼーっと DB のコピーをした後に、コピー元と uid が違っていたので以下のようなコマンドを叩いた。ぼーっと。
chown -R mysql:mysql ../
これを叩いたときのカレントディレクトリは /var/lib/mysqlである。ドットが一個多いので /var/lib 以下が全部 mysqlになって大惨事。
こういうとき FreeBSDだったらmtreeを使うんですが、 GNU/Linuxだと無いようなのでどうするねん。と困っていたところ、 satoh_fumiyasu@ さんに getfacl/setfacl というポインタを教えてもらいました。
同一構成の適当なホストからパチってきて合わせる。
-bash-3.2# hostname rokuchotouge -bash-3.2# pwd /var -bash-3.2# getfacl -R lib | nc tochugoe.localdomain 30000 -bash-3.2#
-bash-3.2# hostname tochugoe.localdomain -bash-3.2# pwd /var -bash-3.2# nc -l 30000 | setfacl --restore=- setfacl: lib/hoge: No such file or directory (snip) -bash-3.2#
残りは ls -Rl | grepmysqlとかで探してよきに計らう。
10年に一度ぐらいしか作らないようなホストを作る最後の方でヘマやらかして、作り直しに心折れていたところなので大変役に立ちました。
↧
六丁峠
↧
今年こそ Android で IPv6 元年
日本国内で Androidにて 3G/LTEで IPv6が使えるようになった、という話。
の 3つについて、 Nexus 7 2013 での設定方法もメモしておきます。
DoCoMo Xi
DoCoMo純正の Xi SIM で IPv6接続する場合について。 Xperia SP か何かと一緒に契約した気がします。
- My docomoにて mopera Uを追加で契約
- http://www.mopera.net/customize/にて「IPv6アドレスを利用する」に設定
- APN 設定画面にて APN プロトコルに IPv4/IPv6を選択
www.mopera.net で設定をいじる必要があるのがミソ。下記 PDF の序盤とかを参考にすればいいと思います。
http://www.mopera.net/manual/option/ipv6_l02c_win.pdf
実際の設定画面はこんな感じ。
DoCoMo純正端末だと殺されている選択項目が Nexus 7 2013 ではまともに使える。
NTT DOCOMOで…
IPv6です。
auiPhone 5 SIM
auLTEの SIM で IPv6接続する場合。 iPhone 5から引っこ抜いた SIM ですが、 Androidと同じ SIM だと思われます。
なお、 auはどっかのキャリアと違って素晴らしいので、 au販売の端末でも LTE NET for DATA を契約し上記 APN に変更すれば、 IPv6が使えるものと推測しています。未確認なので誰か試して！
なお、 uno.au-net.ne.jp では IPv6が使えなかったので、 LTE NET for DATA の契約は必須である模様。
Nano SIM なのでこういうことをします。
APN はこんな感じ。
WCDMA 端末でも LTE Band 1 対応なら繋がり…
IPv6アドレスが付く。
IIJmio高速モバイル/D
IIJmio SIM も例によって IPv6に対応している。
極めて簡単。契約とか網側設定とかを Web 経由で設定したりする必要は無い。本来こうあるべき。
ASUS Shop で IIJmioプリペイドパックなるキャンペーン商品を購入している人はかなり居るはずなので、設定の容易さも相まってモバイル環境での IPv6普及率を押し上げてくれるんじゃないかと期待している。
特に IIJmioとか出ないんですが…
アドレスはこうなる。
Nexus 7 2013 のプリセットで入ってる APN もデフォルトで IPv4/IPv6にしないのかなぁ？
背景
日本では、割と前からモバイルネットワーク側は IPv6に対応していた。
- DoCoMomopera Uでは 2011/6/1 より IPv6対応*1
- KDDILTE NET for DATA では 2012/11 IPv6対応*2
- IIJmio高速モバイル/D では 2012/5/22 より IPv6対応*3
が、スマートフォン側は下記のような状況で、なかなか IPv6を試すことが出来ないで居た。
- mopera Uの IPv6は LTE端末専用
- auの LTE端末は私が持っていなかった
- 国内の DoCoMoLTE端末はわざわざ IPv6を殺してある
- 海外端末
- 国内の Band 1 LTEに対応する端末が最近まで存在し無かった
- 外国人旅行者の知人に手伝ってもらわないと電波法的にホワイトで無い
そこに颯爽と Nexus 7 (2013) なる端末が現れた。
これらの条件により、日本で心置きなくモバイルで IPv6を楽しむ環境が整った。
なお、 auユーザはもうちょっと前から IPv6を楽しむことが出来ていた模様。俺、 WiMAXが使えるんで愛用している Motorola Photon が 2年経ったら auLTE端末をゲットするんだ…。
その他 Nexus 7 2013 雑感
OTA を適用した後、右上の「初期設定にリセット」するとプリセットでこれだけ出てくる。
この亀の躍動感をお伝えすることが出来ないのが残念です。
キャリアサーチするとこんな感じ。
さあ皆も Nexus 7 2013 で IPv6だ！
*1:http://www.mopera.net/information/info/110517_01.html
*2:http://www.soumu.go.jp/main_content/000231523.pdf
*3:http://www.iij.ad.jp/news/pressrelease/2012/0425.html
*4:http://www.iij.ad.jp/company/development/tech/activities/lte_mvno/index.htmlhttp://www.iij.ad.jp/company/development/tech/activities/lte_ipv6/index.htmlより
↧
↧
Intel SSD のファームウェアを USB メモリで更新する
IntelSSDFirmware Update Tool は ISO イメージを dd で直接 USB メモリに書き込むと、その USB メモリから boot して使える。
具体的にはこう。
dd if=issdfut_2.0.6.iso of=/dev/da0 bs=1M
この da0 の USB メモリから起動すると、暫く ISOLINUX とか表示され動かなくなるが、放っとくと起動する。
前の issdfut は ISO イメージからファイル引っこ抜いて FreeDOSでほにゃららみたいなことをする必要があり面倒だったが、久しぶりに同じことをしようと mount_cd9660 したら、 vmlinz とか見えたので試したら上手くいった。 2系から変わったんかな？
たぶん isolinux さん辺りがよきに計らってくれてるぽいが、 CD boot 用の bootloader なのに USB メモリからも起動するのは面白い。
↧
質感まで表現できるカメラが欲しい
手に入れた気がする。
このぐらいになってくると、画像の縮小アルゴリズムとかも雰囲気に影響するようになってくる。その点、はてなフォトライフはいまいちである。オリジナルサイズの画像をアップロードした方と比較するとなんか違う。
iG50 は良いタイヤでした。バンパーでラッセルする深雪でも再発進出来るし、深夜の凍結路でも一度のトラブルも無くこの冬を越せました。
シャーベット状の雪を漫然と走っていたときはヒヤッとしたけど、これは私が悪い。
↧
Android GoogleMap でレーン表示が出るようになった
8.0.0 からだと思うけど、 Androidの Google Mapsのカーナビ機能で、交差点でのレーン表示が出るようになった。
合わせて、マップに別経路が提案されるようにもなった。多少はずれても選んだ経路へ戻るルートを提案し続ける傾向になった気もするが、これはよく分からん。
レーン表示はアプライアンスなカーナビの優位点だと思っていたので、これはカーナビメーカー危うしという感じがする。
まだ優位性は残っていると思うけど、数がものを言う通信機能なんかは Google Mapsに先を行かれているので、普及価格帯の製品にも付けるとかして頑張ってほしい。
とはいえ、 20万円も取るような商売はもう出来ないだろうなぁ。 PC/AT互換機の登場に近い雰囲気を感じる。
↧