Windows 11 22H2マシンに巨大ファイルをコピーするとスループットが大幅に低下する問題 35
ストーリー by nagazou
/J 部門より
/J 部門より
headless 曰く、
Windows 11 2022 Update (バージョン 22H2) マシンに数 GB の巨大ファイルをコピーすると、スループットが大幅に低下する問題が確認されているそうだ。 (Storage at Microsoft の記事、 On MSFT の記事、 Neowin の記事、 Ghacks の記事)
リモートコンピューターから SMB でコピーする場合には最大 40 % 程度のスループット低下がみられるが、SMB 限定ではなくローカルでのファイルコピーでも同様の挙動になるという。一方、コピー先が Windows 11 バージョン 22H2 以外のマシンの場合、問題は発生しないとのこと。Microsoft では問題解決に向けて作業を進めているが、回避策として robcoopy や xcopy でバッファーなしI/Oを使用するオプション「/J」を指定してコピーする方法が紹介されている。
確か (スコア:2)
Win2000辺りでも、小さな大量のファイルコピーでくっそ遅くなるから
圧縮してからコピーするようにしてた記憶が・・・
Re: (スコア:0)
MS標準のコピーがあまりにもウンコだったのでFastCopyばかり使ってました。
Re: (スコア:0)
そりゃ大量のファイルだとオーバーヘッドも大量に発生しますからね
HTTP(S)のセッションだって同様で、小さいファイルを大量に使ったwebサイトなんかも遅いでしょう
むしろWindows Vistaのファイルコピー・移動が遅いのを思い出しました
2007年のパッチが出回る前に、当時のPCの搭載メモリの少なさも相まってVistaはクソという評価が世の中で定着し、
そのまま復活することがなかったなぁという思い出
21H2のWindows 10でも (スコア:1)
> コピー先が Windows 11 バージョン 22H2 以外のマシンの場合、問題は発生しない
21H2のWindows 10ですが、同様の症状に以前から苦しんでます。
コピーではなく、移動時の話です。
巨大ファイルではなく、細かなファイル（数MB）の大量移動時にも発生します。
Re: (スコア:0)
21H2のWindows 10ですが、同様の症状に以前から苦しんでます。
黎明期のSSDとかUSB接続だったりSDカードだったりせんかね
Trim効かずに消去→書き込みしなきゃならん状態だと遅くならざるをえない
もしくはSMRのHDDで瓦の重ね直しになってるとか
# さすがにSMRをRAIDで使っている可能性はないとは思うが
どこが原因よ? (スコア:0)
ファイルシステム?デバイスI/O?
巨大ファイルって言うからライトキャッシュちょっと改良したときにエンバグしたか。
怖いなこういうところの不具合って。
# SMB関係ないなら書かなきゃいいのにいらん情報よな
Re: (スコア:0)
エクスプローラーのバグじゃないのかな。22H2は他にも、日本語入力で固まるとか大量に不具合報告でてるみたい。
10で良かった。というか10の22H2は無事であってくれ。
Re: (スコア:0)
思いとどまって良かった。
人柱のみんな、がんばえー。
Re: (スコア:0)
はやく-1してやって
Re: (スコア:0)
「自分のマシンを制御できない向き」が自嘲してるんだぞ。
ここ来てる奴なら、そんなインスタンスのひとつやふたつ抱えてるだろ。「おかんのPC」とか。
Re: (スコア:0)
違うよ。第一声だと目を付けられるからレスにぶらさげはじめた例の構ってちゃんだよ。
Re: (スコア:0)
回避策として robcoopy や xcopy でバッファーなしI/Oを使用するオプション「/J」を指定してコピーする
てことは xcopy などでもバッファなしオプションを指定しなければ速度低下するということで、エクスプローラーのファイルコピーに限られた症状ではなさそうだ
Re: (スコア:0)
> どこが原因よ?
ですよねぇ。こういうところも継続的に手を入れてるんでしょうね。
Re: (スコア:0)
直しながら継続的にバグも注入されている。
Re: (スコア:0)
SMBの方は既知でローカルでも似た現象が起こるという話。要するにSMBの件の続報。
Re: (スコア:0)
じゃあこの段階ではますますSMB出す必要ないじゃん。
関係ないと分かったんだから。
Re: (スコア:0)
公式がSMBって言ってるんだから仕方ないだろ。
# 公式では問題のごく一部しか認めないのあるある
本件っぽい症状 (スコア:0)
これが原因かどうかはわからないけど、それっぽい症状がありました。
月1回のバックアップでNASとローカルHDDへファイルコピーを走らせています。
22H2より前は7-9時間程度で終了していましたが、22H2では11時間ほどかかりました。
バックアップ先のローカルHDDがSMRなので、終盤はもともと1-2MB/sとなり、本件の影響だとしてもどのくらいかは不明です。
SMB over QUIC (スコア:0)
SMB over QUICを無効化すれば、改善するという記事もあったな。
SMBによる圧縮転送をやめる必要もあるかも。
結局、それらの新しいプロトコルではなく、旧式のプロトコルであれば問題は起きていないという話もある。
Re: (スコア:0)
ローカルファイルのコピーにも SMB over QUIC を使ってるのかい？
Re: (スコア:0)
例えば、ローカルコピー時にサイドチャネル攻撃で読み取られることを防ぐために何らかの暗号化を行っていて、QUICと同じプログラムルーチンを使っていてバグっているとかだろうか。
まぁExplorerの方もあれだし (スコア:0)
IO処理させすぎると処理終わっても手動リロードしなければフォルダ内の表示更新されなかったりするし
開放漏れのバグはそこら中に埋まってる感じだよね
# 面倒でもそうなったらタスクマネージャーのプロセスタブからまとめて落として開き直すアホらしさ
×巨大な→○大きな (スコア:0)
最近は動画触り始めて数百GB単位の移動が普通になっていたので、”二桁小さい数GB程度で巨大と言っちゃうのかよ…NASA推しのtremendousか定番のhugeか、何と表現しているのかな、ワクワク…”と元記事を見に行ったら、やっぱりlargeでしかなかったガッカリ感。
がっかりさせんなよ！
…で、皆がどのくらいのファイルサイズを「大きい」「巨大」と表現し始めるのか、ちょっと気になってきた。
Re: (スコア:0)
確か、エクスプローラの検索オプションに、"巨大"ってのがあったような。500M以上でしたっけ?
Re:×巨大な→○大きな (スコア:1)
ファイルエクスプローラーの列フィルタや検索は、
Win10 (20H2)では、
・空 "Empty" (0 KB)
・かなり小さい "Tiny" (0 - 16 KB)
・小さい "Small" (16 KB - 1 MB)
・中程度 "Medium (1 - 128 MB)
・大きい "large" (128 MB - 1 GB)
・かなり大きい "Huge" (1 - 4GB)
・巨大 "Giantic" (>4 GB)
となっていますね。""内は英語版の表記。
なお、2017時点では、同じ Win10 でも次のようにサイズが異なっていました：
・Empty (0 KB)
・Tiny (0 - 10 KB)
・Small (10 - 100 KB)
・Medium (100 KB - 1 MB)
・large (1 - 16 MB)
・Huge (16 - 128 MB)
・Giantic (>128 MB)
フルHDゲーム動画を1時間も録っていれば、すぐ15GBに達するので、
動画時代になって、巨大、大きい、とかの感覚が変わったということでしょうね。
Re: (スコア:0)
4GBというのは、FAT32の最大ファイルサイズを意識してたりするんだろうか。
Re: (スコア:0)
数百GBはやや巨大～かなり巨大のイメージはあるなあ。数GBだと僅かに巨大と言えなくもないかなあ。
Re: (スコア:0)
10MBまでいったら巨大ですね。だいたいメールで容量制限にひっかかるのがこのあたりなので。
今時メールの添付ファイルなぞくそ迷惑だよｗ (スコア:1)
たった10MBで巨大なんていつの時代に住んでいるんだよ？
伝書バトにメモリカード添付する [it.srad.jp]か、クラウドストレージサービス使ってくれよ。
モデレータは基本役立たずなの気にしてないよ
Re: (スコア:0)
昔ならフロッピー1枚に収まる範囲(1MBぐらい)
Re: (スコア:0)
「megaデモ」と言ったら小ささの象徴でしたね。
速く走るために馬力を下げることもある (スコア:0)
ネットワークやI/Oを専有しないためにも、遅くすることでシステムが安定することがある。
覚えておいたほうがいいぜ。
Re: (スコア:0)
誰とも競合しない状況で4割もスループット落とす「安定化」とか、今更OSに入ればただのバグだろそんなもん
Re: (スコア:0)
車は時速80kmを超えると燃費悪くなるんだって