start

CrucialのSSDのTrimコマンドはバグ持ちらしい

最近知ったのだけど、CrucialのSSDのNCQなTrimコマンドにはバグがあるらしく、Linuxではブラックリスト入りしてる模様。このバグを踏むと、SSDがビープ音を発しデータがぶっ壊れるそうな((((;゚Д゚))))

フォーラムとブラックリストを見る限り“QUEUED”なTrim固有の問題のようだが、ここによれば“non-QUEUED”なTrimでも起きると書いてある。どっちが本当なんだ…?

他に情報をあたってもLinux以外のOSでの回避方法やら発生報告は見当たらないし、良く分からん。シェアからしたらWindowsでの報告があっても良さそうだけど、例え本当にバグ要因のデータ消失が起こっていたとしても、寿命要因でのクラッシュくらいにしか見られて無さそう…。

そもそも、TrimのQUEUEDとnon-QUEDEDって何やねんって話だが、要はNCQに対応してるかどうかの違いみたい。当初、Trimコマンドは非NCQなコマンドとして規定され、その後Serial ATA Revision 3.1でNCQ版が登場したという歴史のようだ。もしかして、バグの原因はNCQでコマンドが並べ替えられた結果、データ読み込み要求よりTrimコマンドが先に発行されて、データがぶっ壊れるというオチだったりして?(流石にこんな単純なバグではないだろうけど)

とりあえず、うちではCT960M500SSD1を1年ほどMacOS XでTrim有効の状態で使っていたが、バグったことはない。ついでに現在進行形でCT128M550SSD1をFreeBSDでTrim有効で使っているが、今のところ問題は出ていない。

YAMAHA RTX1100で転送量を調べる

ネット回線の転送量を知りたくなったのでメモ。RTX1100とは書いたけど、ヤマハルータ全般で使えるハズ。

show status lan2でLAN2ポートの送受信パケット数を取得出来る。LAN2以外を外部通信に使ってるなら適宜読み替えてくだしあ。

> show status lan2
LAN2
説明:
IPアドレス:                     192.168.0.1/24
イーサネットアドレス:           XX:XX:XX:XX:XX:XX
動作モード設定:                 Auto Negotiation (100BASE-TX Full Duplex)
最大パケット長(MTU):            1500 オクテット
プロミスキャスモード:           OFF
送信パケット:                   14675823 パケット(2594214328 オクテット)
  IPv4(全体/ファストパス):      14532497 パケット / 11471073 パケット
  IPv6(全体/ファストパス):      1 パケット / 0 パケット
受信パケット:                   17463235 パケット(15242278294 オクテット)
  IPv4:                         14692144 パケット
  IPv6:                         0 パケット
未サポートパケットの受信:       2564160
受信オーバーフロー:             102

ついでに、アップタイムはshow environmentでおk。

> show environment
RTX1100 BootROM Rev.5.07
RTX1100 Rev.8.03.94 (Thu Dec  5 19:06:16 2013)
  main:  RTX1100 ver=c0 serial=XXXXXXXXXXX MAC-Address=YY:YY:YY:YY:YY:YY MAC-Address=ZZ:ZZ:ZZ:ZZ:ZZ:ZZ MAC-Address=WW:WW:WW:WW:WW:WW
CPU:   5%(5sec)   3%(1min)   3%(5min)    メモリ: 33% used
実行中ファームウェア: exec0  実行中設定ファイル: config0
デフォルトファームウェア: exec0  デフォルト設定ファイル: config0
起動時刻: 2015/05/15 19:47:41 +09:00
現在の時刻: 2015/06/30 16:38:14 +09:00
起動からの経過時間: 45日 20:50:33
セキュリティクラス レベル: 1, FORGET: ON, TELNET: OFF

Netatalk 3でsendfileを無効にするとCannot allocate memoryが起きる?

(2016-01-04 追記)
どうやらVirtualBoxが原因だった模様。詳細→FreeBSDでVirtualBoxを動かしていると巨大ファイルの転送でCannot allocate memoryが出る

いつ頃からから、Netatalk 3.1.7で提供しているボリュームとの接続が突然切れる現象が起きるようになった。

正確な発症条件は不明だが、ストレージの読み書き負荷が高い時や、巨大な動画ファイルでシークすると発生しやすい印象。いずれにせよ、何の前触れもなく発生し接続断のダイアログも出ないので地味にストレスが溜まる。

接続が切れる直前は決まって、ログにdsi_stream_sendafp_read_extのCannot allocate memoryが記録されている。

Jun 02 23:55:18.897112 afpd[57517] {afp_dsi.c:624} (debug:AFPDaemon): <== Start AFP command: AFP_READ_EXT
Jun 02 23:55:18.897126 afpd[57517] {fork.c:829} (debug:AFPDaemon): afp_read(fork: 422 [data], off: 1310720, len: 65536, size: 2222591)
Jun 02 23:55:18.897156 afpd[57517] {fork.c:880} (debug:AFPDaemon): afp_read(name: "01 プロローグ・静かなる侵略.m4a", offset: 1310720, reqcount: 65536): got 65536 bytes from file
Jun 02 23:55:18.897170 afpd[57517] {dsi_read.c:29} (maxdebug:DSI): dsi_readinit: sending 65536 bytes from buffer, total size: 65536
Jun 02 23:55:18.897183 afpd[57517] {dsi_stream.c:530} (maxdebug:DSI): dsi_stream_send(65536 bytes): START
Jun 02 23:55:18.897353 afpd[57517] {dsi_stream.c:564} (error:DSI): dsi_stream_send: Cannot allocate memory
Jun 02 23:55:18.897375 afpd[57517] {fork.c:913} (error:AFPDaemon): afp_read(01 プロローグ・静かなる侵略.m4a): Cannot allocate memory
Jun 02 23:55:18.897397 afpd[57517] {dsi_stream.c:281} (maxdebug:DSI): dsi_stream_write(send: 18 bytes): START
Jun 02 23:55:18.897419 afpd[57517] {dsi_stream.c:325} (maxdebug:DSI): dsi_stream_write(send: 18 bytes): END
(中略)
Jun 02 23:55:18.898533 afpd[57517] {cnid_dbd.c:498} (debug:CNID): closing database connection for volume 'Decomo'
Jun 02 23:55:18.898578 cnid_dbd[57522] {comm.c:207} (maxdebug:CNID): comm_rcv: got data on fd 5
Jun 02 23:55:18.898980 afpd[57517] {afp_dsi.c:108} (note:AFPDaemon): AFP statistics: 3177.09 KB read, 2524196.96 KB written
Jun 02 23:55:18.899005 afpd[57517] {dircache.c:615} (info:AFPDaemon): dircache statistics: entries: 2088, lookups: 10018, hits: 7503, misses: 2463, added: 2140, removed: 52, expunged: 52, evicted: 0
Jun 02 23:55:18.899020 afpd[57517] {dsi_stream.c:530} (maxdebug:DSI): dsi_stream_send(0 bytes): START
Jun 02 23:55:18.899033 afpd[57517] {dsi_stream.c:538} (maxdebug:DSI): dsi_stream_send(16 bytes): DSI header, no data
Jun 02 23:55:18.899045 afpd[57517] {dsi_stream.c:281} (maxdebug:DSI): dsi_stream_write(send: 16 bytes): START
Jun 02 23:55:18.899068 afpd[57517] {dsi_stream.c:325} (maxdebug:DSI): dsi_stream_write(send: 16 bytes): END
Jun 02 23:55:18.899089 afpd[57517] {afp_dsi.c:137} (info:AFPDaemon): Connection terminated
Jun 02 23:55:18.899899 afpd[57498] {main.c:149} (info:AFPDaemon): child[57517]: exited 1

Mac側はOS X v10.9.5で、サーバ側はFreeBSD 10.1-RELEASE。10.1RにはZFSのARCがメモリを食いつぶすバグがあるらしく、それが原因かと思って10-STABLEに更新するも、症状は相変わらず。

で、試行錯誤を続けていたが、Netatalk 3のsendfileを有効にしたらピタッとおさまった。正確には未だ出るけど、Netatalkとの接続は維持自体はされるようになった(自動で再接続されている模様)。おぼろげな記憶をたどると「ZFS環境でApache等のsendfileを有効にするとキャッシュの二重持ちになる可能性がある」という資料を見て、sendfile無効でNetatalk 3を作り直してたような気がしないでもなく、丁度その辺から問題が出たような気がする……。

時を同じくして、同サーバのSamba 4でファイル一覧の取得がタイムアウトしたり、動画が全く再生できなくなったりしていたのだが、こちらは逆にuse sendfile = yesを無効化したら直った。

全く以て謎だ…

RAID-Z2の再構築速度

知人の業務用ファイルサーバという名の自作マシンに、悪名高きST3000DM001が5台も使われている。HDDの通電時間も15000時間を超え、そろそろ怖くなってきたので全部取り替えることになった。

CPU Intel Xeon E3-1225 V2
M/B Gigabyte Z77X-UP5
メモリ 16GB
ストレージ HDD 6台(ST3000DM001×5 + HDS723030ALA640)のRAID-Z2
OS FreeBSD 9.2-RELEASE-p4
# zpool list
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
zdata  16.2T  8.45T  7.80T    52%  1.00x  DEGRADED  -

こんな環境。

早速1台をzpool replaceしてみたところ、6時間で1.41TBを同期して完了。既存データを総なめしてる訳だから、410MB/sほどの速度。他のRAIDシステムを使ったことがないので、これが速いのか遅いのかは判断できないが、遅くはないんじゃないかなーと思う。

ちなみに、再構築中のロードアベレージは0.5位で、CPUはsystemに15%前後取られていた。

さて、残り4台もこの調子で交換していこう。

続・L2ARCの空き容量が16EB(16.0E)と表示される件

こないだの続き。

その後システムをFreeBSD 10-STABLE (r283857)に更新しL2ARCを有効にしていたが、これまた、たまたまzpool iostatを流してたら16EBになる瞬間を捉えられた。

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome        731G   197G      0     68      0  8.01M
  mirror     731G   197G      0     68      0  8.01M
    ada0p1      -      -      0     68      0  8.13M
    ada3p1      -      -      0     74      0  8.88M
logs            -      -      -      -      -      -
  mirror     128K  7.94G      0      0      0      0
    ada1p3      -      -      0      0      0      0
    ada9p3      -      -      0      0      0      0
cache           -      -      -      -      -      -
  ada9p5    40.0G  1.78M      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome        731G   197G      0    369      0  16.3M
  mirror     731G   197G      0    369      0  16.3M
    ada0p1      -      -      0    197      0  16.2M
    ada3p1      -      -      0    191      0  15.5M
logs            -      -      -      -      -      -
  mirror    13.8M  7.92G      0      0      0      0
    ada1p3      -      -      0      0      0      0
    ada9p3      -      -      0      0      0      0
cache           -      -      -      -      -      -
  ada9p5    40.0G  16.0E      0     63      0  7.96M  ★★ここ★★
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome        731G   197G      0      0      0      0
  mirror     731G   197G      0      0      0      0
    ada0p1      -      -      0      0      0      0
    ada3p1      -      -      0      0      0      0
logs            -      -      -      -      -      -
  mirror    13.8M  7.92G      0      0      0      0
    ada1p3      -      -      0      0      0      0
    ada9p3      -      -      0      0      0      0
cache           -      -      -      -      -      -
  ada9p5    40.0G  1.40M      0     33      0  4.25M
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome        731G   197G      0      0      0      0
  mirror     731G   197G      0      0      0      0
    ada0p1      -      -      0      0      0      0
    ada3p1      -      -      0      0      0      0
logs            -      -      -      -      -      -
  mirror    13.8M  7.92G      0      0      0      0
    ada1p3      -      -      0      0      0      0
    ada9p3      -      -      0      0      0      0
cache           -      -      -      -      -      -
  ada9p5    40.0G   924K      0     37      0  4.74M
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome        731G   197G      0      0      0      0
  mirror     731G   197G      0      0      0      0
    ada0p1      -      -      0      0      0      0
    ada3p1      -      -      0      0      0      0
logs            -      -      -      -      -      -
  mirror    13.8M  7.92G      0      0      0      0
    ada1p3      -      -      0      0      0      0
    ada9p3      -      -      0      0      0      0
cache           -      -      -      -      -      -
  ada9p5    40.0G   424K      0     41      0  5.24M
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome        731G   197G      0      0      0      0
  mirror     731G   197G      0      0      0      0
    ada0p1      -      -      0      0      0      0
    ada3p1      -      -      0      0      0      0
logs            -      -      -      -      -      -
  mirror    13.8M  7.92G      0      0      0      0
    ada1p3      -      -      0      0      0      0
    ada9p3      -      -      0      0      0      0
cache           -      -      -      -      -      -
  ada9p5    40.0G  16.0E      0     46      0  5.86M  ★★ここ★★
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome        731G   197G      0     77      0  9.12M
  mirror     731G   197G      0     77      0  9.12M
    ada0p1      -      -      0     77      0  9.24M
    ada3p1      -      -      0     84      0  10.1M
logs            -      -      -      -      -      -
  mirror    13.8M  7.92G      0      0      0      0
    ada1p3      -      -      0      0      0      0
    ada9p3      -      -      0      0      0      0
cache           -      -      -      -      -      -
  ada9p5    40.0G  16.0E      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

L2ARCの空きが無くなると16.0Eになるっぽい。unsignedな型で負数を扱おうとして爆発してるように見える。というか、r273060のコミットログに、思いっきり「the number became negative and overflows」と理由が載っていた(´・ω・`)

更にarc.cのログを追っていたら、r275096で修正がリバートされてるやないか!4Kセクタデバイスを考慮しておらず正しい修正ではなかったとの事……。解決には時間が掛かりそうな雰囲気。

  • start.txt
  • 最終更新: 2022-07-27 15:26
  • by Decomo