そんにゃわけでNTFSをフラグメントして死にゃにゃいようにフォーマットするメモ。
ファイルレコードのサイズを増加させるにはformat /L /Q /FS:NTFSとかすればよい。
で、確認だが、fsutil fsinfo ntfsinfoして、
ファイル セグメントあたりのバイト数 : 1024
ファイル セグメントあたりのクラスター数 : 0
が
ファイル セグメントあたりのバイト数 : 4096
ファイル セグメントあたりのクラスター数 : 1
ににゃればOKかと思われる。
いまいちこの辺りの情報は検索しても分かったようにゃ分からにゃいようにゃ記述が多くて困るのだが。
zfs on linux on Hyper-Vにゃvmで謎のblk_update_request critical target error dev sdb発生でsnapshot失敗の件を調べてて、とりあえずsdbに付いてるvhdxを拡張してみようと思ったら失敗した。
仮想ハード ディスクの編集ウィザード
仮想ディスクの編集中に、サーバーでエラーが発生しました。
仮想ディスクのサイズを変更できませんでした。
システムで 〜〜〜.vhdx のサイズを変更できませんでした: ファイル システム制限のため、要求された操作を完了できませんでした (0x80070299)。
The requested operation could not be completed due to a file system limitation.
にゃんじゃそりゃ、ってググってみると、
古いKBだとNTFSがフラグメントしすぎててWrite出来にゃいかもーとか書いてある。
Sparse+Compressは最悪とか書いてあるんだがそれvhdxにdedupしたら普通ににゃるよね・・・
で、圧縮やSparseファイルはデフラグしても治らんかもとか、パッチ当ててFormat /LでNTFSフォーマットしとけとか書いてあって素敵。
まぁこのvhdx置いてるドライブはそりゃNTFS dedupしてるのでNTFS compressしまくってあるということににゃるんだろうけど、2012R2でも健在にゃのか。ERROR_FILE_SYSTEM_LIMITATIONでググると2013年以降も出てそうにゃ気配。
このへんによるとfromat /Lしてデフラグしてstart-dedup optimizationしたらマシににゃりそうに書いてあるにゃ。ダメにゃら一度コピーしてdedupかけ直せとかまた鬼畜にゃ。dedupするそこかしこでバックアップとっとけとかどんだけ信頼性にゃいんやNTFS。
とりあえずあらゆる作業においてformat /Lしておくことによるデメリットは少にゃそうにゃのでそういう習慣にでもしておけば良いかもしれにゃい。
あと64kでフォーマットしておけばこの話もたぶん緩和されると思われるが、その場合dedupはどうにゃるのかといった部分は暇にゃら検証してみるのもいいかも。
zfs dedup onにゃlinux vmにいろいろデータ突っ込んで履歴バックアップに使おう編。
zpool create -o ashift=12 pool1 sdb
zfs create -o recordsize=128k pool/share
にゃpool1に/homeを突っ込んでzfs snapshotするだけのを繰り返してたらI/O busyにゃ状態で止まった。
psにzfs snapshot〜が居るのでこいつが止まっているのは確かにゃよう。しかしzpool statusで1つのファイルがエラーににゃっているので、I/O回りで起きたエラーが原因か。
上位レイヤーからはDisk待ちWAITににゃっているが、DiskにはI/Oリクエストは行ってにゃいので何かデッドロックしたようにゃ止まり方。
zfs snap関連を叩くと帰ってこにゃくにゃるようにゃので、とりあえずrebootしようとしたら、blk_update_request critical target error dev sdb大量。syslog見たらもっとたくさん居た。
で、リセットして再現させてみると、ある程度しばらく動作するものの、snapshotをいくつか取ってるとI/Oエラーとにゃる。vmにゃのでどこらへんで問題が起きてるのかよく分からにゃい。Hyper-V側の気がするんだが思いつく要素が無いんだよにゃぁ。
懸念材料としては8割ほど埋まっているのでDiskFullが近いという辺りか。
でもvmの仮想HDDがwrite失敗してるってのが最も素直にゃ印象。うーん・・・