ソースの表示以前のリビジョンバックリンク全て展開する／折り畳む文書の先頭へ Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit Teams最近の変更Send via e-Mail印刷パーマリンク × 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有効で使っているが、今のところ問題は出ていない。 参考サイト M500/M5x0 QUEUED-TRIM data corruption alert (mostly for Linux users) - Crucial Community linux/libata-core.c · torvalds/linux · GitHub Trim (computing) - Wikipedia, the free encyclopedia When Solid State Drives are not that solid | Milliseconds Matter SSDをめぐる議論に浮かび上がるベンダ模様（1/2） － ＠IT 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でおｋ。 > 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_sendかafp_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セクタデバイスを考慮しておらず正しい修正ではなかったとの事……。解決には時間が掛かりそうな雰囲気。 < Newer Posts 1 2 ... 41 42 43 44 45 46 47 ... 82 83 Older Posts > start.txt 最終更新: 2022-07-27 15:26by Decomo