ソースの表示以前のリビジョンバックリンク全て展開する／折り畳む文書の先頭へ Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit Teams最近の変更Send via e-Mail印刷パーマリンク × zfs destroyしても空き容量はすぐには増えない？ ここに16TiBのRAID-Z2プールがあるじゃろ。 $ zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT zdata 16.2T 5.63T 10.5T 34% 1.00x ONLINE - $ zfs list NAME USED AVAIL REFER MOUNTPOINT zdata 5.63T 5.02T 304K /mnt/zdata zdata/ROOT 5.63T 2.37T 304K /mnt/zdata/ROOT zdata/ROOT/data 5.63T 2.37T 5.63T /mnt/zdata/ROOT/data それを消したんじゃ。 $ sudo zfs destroy -R zdata/ROOT そして再度ファイルシステムを確認すると… $ zfs list NAME USED AVAIL REFER MOUNTPOINT zdata 5.61T 5.04T 288K /mnt/zdata なんと、空き容量が増えておらんのじゃ！ もう少し詳しく見てみる。 $ zpool iostat zdata 1 capacity operations bandwidth pool alloc free read write read write ---------- ----- ----- ----- ----- ----- ----- zdata 8.20T 8.05T 403 161 2.35M 659K zdata 8.20T 8.05T 445 0 1.86M 0 zdata 8.20T 8.05T 359 0 1.64M 0 zdata 8.20T 8.05T 494 0 2.65M 0 zdata 8.20T 8.05T 446 0 1.75M 0 zdata 8.20T 8.05T 309 0 1.42M 0 zdata 8.19T 8.06T 416 266 2.17M 1.62M zdata 8.19T 8.06T 415 0 1.88M 0 zdata 8.19T 8.06T 438 0 2.47M 0 zdata 8.19T 8.06T 328 0 1.49M 0 zdata 8.19T 8.06T 379 0 1.82M 0 zdata 8.19T 8.06T 494 0 2.65M 0 zdata 8.19T 8.06T 314 158 1.46M 647K zdata 8.18T 8.07T 349 8 1.40M 36.0K zdata 8.18T 8.07T 549 0 2.71M 0 zdata 8.18T 8.07T 444 0 1.85M 0 zdata 8.18T 8.07T 660 0 3.09M 0 zdata 8.18T 8.07T 408 0 1.72M 0 zdata 8.18T 8.07T 310 0 1.83M 0 zdata 8.16T 8.09T 303 161 1.28M 659K zdata 8.16T 8.09T 469 0 2.61M 0 zdata 8.16T 8.09T 350 0 1.89M 0 zdata 8.16T 8.09T 269 0 1.86M 0 zdata 8.16T 8.09T 272 0 1.72M 0 zdata 8.16T 8.09T 264 0 1.76M 0 zdata 8.15T 8.10T 196 170 1.29M 695K ^C $ zfs list NAME USED AVAIL REFER MOUNTPOINT zdata 5.39T 5.27T 288K /mnt/zdata $ df -h Filesystem Size Used Avail Capacity Mounted on zdata 6.6T 287k 6.6T 0% /mnt/zdata なんか頑張って回収しとるのぉ…。この状態でファイルを作るとどうなるんじゃろ？iostatを見ながらddしてみる。 $ sudo zfs create zdata/ROOT $ dd if=/dev/zero of=/mnt/zdata/ROOT/zero.tmp bs=8m ^C 601+0 records in 600+0 records out 5033164800 bytes transferred in 24.909500 secs (202058043 bytes/sec) ---------- $ zpool iostat zdata 1 zdata 3.92T 12.3T 231 1.43K 1.71M 141M zdata 3.92T 12.3T 274 0 1.48M 0 zdata 3.90T 12.3T 102 1.36K 464K 141M zdata 3.88T 12.4T 202 720 811K 59.7M zdata 3.88T 12.4T 548 667 2.63M 81.2M zdata 3.88T 12.4T 117 1.75K 472K 192M zdata 3.88T 12.4T 212 208 872K 856K zdata 3.88T 12.4T 197 2.36K 1.06M 293M zdata 3.88T 12.4T 203 796 827K 68.5M zdata 3.88T 12.4T 242 1.78K 979K 225M zdata 3.88T 12.4T 159 1.39K 647K 146M zdata 3.88T 12.4T 134 1.51K 539K 191M zdata 3.87T 12.4T 120 1.33K 484K 143M zdata 3.87T 12.4T 380 1.80K 2.12M 224M zdata 3.87T 12.4T 504 953 1.97M 83.2M zdata 3.87T 12.4T 350 2.42K 1.37M 304M zdata 3.86T 12.4T 674 913 3.13M 80.2M zdata 3.86T 12.4T 338 2.50K 1.33M 314M zdata 3.86T 12.4T 1005 606 4.41M 47.1M zdata 3.86T 12.4T 289 2.86K 1.13M 360M zdata 3.86T 12.4T 704 184 2.75M 749K zdata 3.86T 12.4T 103 3.36K 415K 418M zdata 3.86T 12.4T 867 191 3.88M 779K zdata 3.86T 12.4T 63 3.17K 255K 396M zdata 3.86T 12.4T 954 149 4.22M 611K zdata 3.86T 12.4T 38 3.46K 156K 432M zdata 3.86T 12.4T 797 66 3.11M 276K zdata 3.86T 12.4T 0 3.07K 0 375M zdata 3.86T 12.4T 761 532 3.47M 62.6M zdata 3.86T 12.4T 651 263 2.54M 7.09M ★ここでddを終了 zdata 3.86T 12.4T 1.02K 182 4.55M 743K zdata 3.86T 12.4T 1.01K 0 4.55M 0 zdata 3.86T 12.4T 1.24K 0 5.46M 0 zdata 3.86T 12.4T 1.09K 0 4.87M 0 zdata 3.86T 12.4T 1.37K 0 5.99M 0 zdata 3.86T 12.4T 1.45K 0 6.27M 0 zdata 3.86T 12.4T 1.04K 167 4.68M 683K ^C 当然じゃが普通に動くようじゃ。dd終了後は、また領域の回収？に戻っておるの。 暫く放置したら回収？作業が終わったようじゃ。 $ zfs list NAME USED AVAIL REFER MOUNTPOINT zdata 90.2M 10.7T 288K /mnt/zdata $ df -h Filesystem Size Used Avail Capacity Mounted on zdata 10T 288k 10T 0% /mnt/zdata じゃがしかし！AVAILが10.7T止まりなのは何故じゃ！？や、RAID-Z2であるからして、パリティ2台分の容量を考慮すると妥当な値なんじゃが、プール作成直後は16Tになってた気がするんだがのぉ……こっちの値が不正確と言われればそれまでなんじゃが、気になる………。 FreeBSDでVirtualBoxを動かしていると巨大ファイルの転送でCannot allocate memoryが出る FreeBSD 10.1-RELEASEな自宅ファイルサーバからMacにファイルをコピーすると「予期しないエラーが起きたため、操作を完了できません（エラーコード -50）。」が発生してコピーに失敗する現象に長らく苦しめられていた。経験的にファイルサイズが大きいほど発生確率が高く、数百MBくらいまでのファイルなら問題ないが、2GBを超えるとまずアウトっていう。鯖→Macの場合AFP(Netatalk 3.1.7)でもCIFS(Samba 4.2.5)でも発生し、鯖→Windowsの場合は言うまでもなくCIFSしか使えないが、所々詰まりながらも一応成功するといった具合。 失敗時はNetatalkのログに「Cannot allocate memory」が必ず記録されている。発生場所は大体{fork.c:913} (error:AFPDaemon): afp_readか{dsi_stream.c:424} (error:DSI): dsi_stream_read_fileのどっちか。メモリたんねーと言われましても、32GB積んでるtopで見ても余裕のよっちゃんイカで数GBレベルで残ってますし…。もう全くわけがわからないよ！本格的に原因を探ろうとsshで各種情報をモニタリングしながらコピーしたら、今度はsshdまでCannot allocate memory吐いて接続切れるし……。 ドライバの不具合？NIC/L2SW由来の不具合？？もしかしてケーブルが腐ってる？？？などなど、疑心暗鬼ロードを爆走していたが、ようやく、ついに！遂に！！原因がわかったッ！！！！ 犯人はヤス何とVirtualBox。 VirtualBox実行中はnetgraph関連のメモリが不足しやすく？なるっぽい。ここやここで同症状が報告されており、/boot/loader.confにnet.graph.maxdata=65536を追加すればおｋと書いてあった。 このカーネルパラメータはnetgraphのデータキューの最大確保数を表すものらしい。同様に非データ用のnet.graph.maxallocなんてのもある。それぞれ/usr/src/sys/netgraph/ng_base.cで定義されていて、コメントが若干怖いことが書いてあった。 static int maxalloc = 4096;/* limit the damage of a leak */ static int maxdata = 512; /* limit the damage of a DoS */ 下手に大きくすると問題発生時に被害が拡大しそうな雰囲気。ま、外部公開してなきゃそんなに気にしなくてもいいだろうけど。 ついでにdmesgにLimiting open port RST response from 208 to 200 packets/sec.なるログも出ていたので、/etc/sysctl.confに以下を追加。 net.inet.icmp.icmplim=2000 肝心のloader.confも一応。 net.graph.maxdata=65536 net.graph.maxalloc=65536 上記設定で1～6GBほどのファイルを100GB分くらいコピーしてみたら、何の問題もなく完了した。普通に動くって素晴らしい。 参考サイト Network problems while running VirtualBox Write failed: Cannot allocate memory (FreeBSD) bacula-fdが ERR=Cannot allocate memory というエラーを出す - ttt NETGRAPH(4) - 特殊ファイル - YOS OPENSONAR apache負荷対策 | ガイドミー管理者日記 IRSTはダイナミックディスク非対応だったり？ システムドライブがダイナミックディスクの場合、Intel(R) Rapid Storage TechnologyのSSDキャッシュ機能が使えない予感。確かな文献がないため、環境依存なのかそういう仕様なのかは不明だが、少なくとも自分の環境では“ソリッドステートドライブを使用して高速化”のメニューが出てこなかった。 ベーシックディスクに戻すと出現するので、きっとそういうモンなんだろう。 ちなみに、ダイナミックディスク→ベーシックディスクの非破壊変換は、TestDiskを使うと比較的簡単かつ安全に出来る。“安全”とは言っても、一歩間違うとWindowsが起動しなくなるばかりか最悪データの消失に繋がりかねない。細心の注意と自己責任で以てよろ。良い子のみんなは業務用PCなんかで挑戦しちゃダメだぞ★。ぼくはかいしゃのぱそこんでためしてきどうしなくなってちょうあせったよ。 IRSTの効果はというと、体感レベルで結構効いてる感じ。キャッシュ有りの環境になれた後でキャッシュを切って試してみると、ものすごーく遅い。正直、効果の面でも運用の面（データの保全は大丈夫なのかとか？）でも懐疑的だったけど杞憂ですた。自分より遥かに頭の良い人達が開発してるんだから疑うほうが失礼か。 このIRSTで地味に凄いのが、キャッシュのON/OFFをOSの再起動なしで出来るという所。稼働中のシステムHDDにSSDをくっつけた仮想ボリュームを作り、元のHDDとオンラインで丸ごと差し替えるとか中々狂ってる。ZFSみたいにファイルシステムレベルでキャッシュ機能を持ってたり、非システムディスクならともかく、デバイスレベルで丸ごと差し替えですよ？人間で言ったら生きたまま心臓を交換するようなもんですよ？IntelもWindowsもすげーと言わざるをえない。 RAID-Z再構築中に更にHDDが脱落してプールがUNAVAILになったでござる(°ω°) ところで俺のRAID-Zを見てくれ。こいつをどう思う？ [Decomo@Freyja ~]$ zpool status pool: zdata state: UNAVAIL status: One or more devices are faulted in response to IO failures. action: Make sure the affected devices are connected, then run 'zpool clear'. see: http://illumos.org/msg/ZFS-8000-HC scan: resilvered 121G in 2h0m with 13047163 errors on Thu Sep 24 23:26:28 2015 config: NAME STATE READ WRITE CKSUM zdata UNAVAIL 96 0 0 raidz1-0 UNAVAIL 194 0 0 11774477246658925336 REMOVED 0 0 0 was /dev/ada0p1 ada1p1 ONLINE 0 0 0 replacing-2 UNAVAIL 0 0 0 3139585788591315191 UNAVAIL 0 0 0 was /dev/gpt/data0-1a ada2p1.nop ONLINE 0 0 0 raidz1-1 ONLINE 0 0 0 ada5p1 ONLINE 0 0 0 block size: 512B configured, 4096B native ada3p1 ONLINE 0 0 0 block size: 512B configured, 4096B native ada4p1 ONLINE 0 0 0 block size: 512B configured, 4096B native logs mirror-2 ONLINE 0 0 0 ada10p4 ONLINE 0 0 0 ada15p4 ONLINE 0 0 0 cache ada10p5 ONLINE 0 0 0 errors: 13047165 data errors, use '-v' for a list すごく・・・UNAVAILです・・・。 RAID-Zを使い始めて早4年、遂にうちにも訪れてしまった、この恐怖の現象「RAIDリビルド中のHDD死亡お替わり」が。いつの間にかデグレってた事は何度かあったけど、UNAVAILは初めて見たよ……。幸いにもada0は脱落しただけで死んではおらず、SATAケーブル＆電源抜き差しで無事復活というかresilveringなう(๑˃̵ᴗ˂̵)وなんですけども。心臓に悪いったらありゃしない。 それにしても、SATAコネクタの信頼性の低さはどうにかならないかなー。コンシューマ向けのHDD×7台でRAID組んでるのがそもそもの間違いではあるし、信頼性求めるならSAS使えって話でもあるけどさ、流石に家庭でSASはやり過ぎっつーかオーバースペックも良いとこでしょ。そんな金もないし。このあたりのイレギュラーさを差し引いても、SATAコネクタは緩み易過ぎると個人的には思う。もうちょっとガッチリとはまって欲しいもんだ。 とか何とか言ってるそばから、またada0が脱落してるし……。 2015-10-03 追記 無事リビルド完了（念のために言っておくと作業自体は随分前に終わってる。） 面白いログが取れたので記念ぱぴこ。 [Decomo@Freyja ~]$ zpool status zdata pool: zdata state: DEGRADED status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Sat Sep 26 13:42:23 2015 4.51T scanned out of 14.7T at 376M/s, 7h51m to go 968G resilvered, 30.78% done config: NAME STATE READ WRITE CKSUM zdata DEGRADED 0 0 0 raidz1-0 DEGRADED 0 0 0 ada12p1 ONLINE 0 0 0 (resilvering) ada1p1 ONLINE 0 0 0 replacing-2 DEGRADED 0 0 370K 3139585788591315191 UNAVAIL 0 0 0 was /dev/gpt/data0-1a ada2p1 ONLINE 0 0 0 (resilvering) raidz1-1 ONLINE 0 0 0 ada5p1 ONLINE 0 0 0 block size: 512B configured, 4096B native ada3p1 ONLINE 0 0 0 block size: 512B configured, 4096B native ada4p1 ONLINE 0 0 0 block size: 512B configured, 4096B native logs mirror-2 ONLINE 0 0 0 ada14p4 ONLINE 0 0 0 ada15p4 ONLINE 0 0 0 cache ada14p5 ONLINE 0 0 0 errors: 4503902 data errors, use '-v' for a list RAID-Zを構成するHDDが2台同時にリビルドされてた。流石ZFS、なかなか器用なことをしてくれる。これもブロック単位でチェックサムを持ってるお陰なのかしら？ FreeBSDの環境そのままにCPU代えたらIllegal instructionでまくり ASRock C2750D4Iは8コアAtom C2750搭載でSATAポートが12個もある、正にファイルサーバにうってつけのマザボである。Mini-ITXながら通常サイズのDDR3 DIMMが4本刺さり、やろうと思えば16GBモジュール×4で64GBものメモリが積めるのも素晴らしい。これまた大食漢のZFSにおあつらえ向きの仕様で、加えてIPMIでリモートで電源ON/OFFやBIOSがいじれたりして、刺さる人には刺さりまくりの素敵ママンだ。流石は変態紳士ASRock。 発売当初から目は付けていたものの、4万後半という値段に手が出せないまま円安と増税の影響で更に値上がりし、もう買えない…と諦めかけていたその時！偶然、JMC DirectでB級品が35000円弱で売られているのを見つけてしまったので光速でポッチッチ。 家鯖のFreeBSD 10.1-RELEASE環境はそのままに、早速Z77A-GD65 + Xeon E3-1260Lと入れ替えてみたところ、難なく動いた。 ……と思ったのも束の間、portsで入れたソフトが軒並みIllegal instructionで落ちまくる！CPUTYPE?=nativeでコンパイルしたバイナリなので、Avotonじゃ実行できない命令が生成されてるんだろう。SandyBridgeからのグレードダウンとはいえ、同時期のCPUで実行できないほどのアグレッシブなコードを吐くclang先輩マジぱねっす。C2750用にビルドし直そうとしても、これまた軒並みIllegal instructionで落ちまくり。ツールチェイン、お前らもか……。たかがgmakeですら超最適化してくれるclang先輩マジ(ry 怪しそうなportsを片っ端からリビルドしたり、gdbで落ちてるライブラリを探ったり、どうしても分からん時はpackagesに逃げたりして何とか再構築できた。最適化ビルドも考えものだな…。少なくともカーネルを再構築する時は、無難な最適化オプションにしないと泣きを見そう……。そのためのCPUTYPE?なんだろうし（?付きの方はカーネル構築時には適用されないらしい）。 < Newer Posts 1 2 ... 39 40 41 42 43 44 45 ... 82 83 Older Posts > start.txt 最終更新: 2022-07-27 15:26by Decomo