WSLの `du`がマシンメモリよりも大きいディレクトリサイズを与えるのはなぜですか？
コンピューター上のどのファイルが最も多くのスペースを使用しているかを調べようとしているときに、質問に遭遇しました。これは、Windows Subsystem for Linux（WSL）/ bashから検出された合計マシンメモリに関する情報です。
bballdave025@WORK:~$ df -h /mnt/c
Filesystem Size Used Avail Use% Mounted on
C: 239G 231G 7.8G 97% /mnt/c
私の質問は、スペースをクリアする方法についてではないことに注意してください。
Program Filesディレクトリを確認することから始めました。
bballdave025@WORK:~$ du -sh /mnt/c/Program\ Files/
du: cannot read directory '/mnt/c/Program Files/Microsoft Policy Platform/authorityDb': Permission denied
du: cannot read directory '/mnt/c/Program Files/Microsoft SQL Server/130/Shared/ErrorDumps': Permission denied
du: cannot read directory '/mnt/c/Program Files/WindowsApps': Permission denied
2.5T /mnt/c/Program Files/
主な問題
私のWSLbashduは、私のマシン（239GBのメモリがある）で、私のProgram Filesディレクトリが占有していると言っています。 2.5TB 利用可能なメモリの239GBの。飲み込まずに2パイントの水を口に含んでいるようなものです。 （これはサイズの比率を示すためだけのものです。私の問題は水に関係していません。）
ちなみに、私には管理者権限がありません。問題を解決するためのSudo !!はありません。この投稿を書き続けるときは、Permission deniedエラー（willrealSudoなしで発生します）を省略します。また、私は仕事用のコンピューターを使用しているため、アクセスできないものがあることにも注意してください。
主な質問：私の状況でディスク使用量を確認する比較的簡単な方法はありますか？つまり、Windowsサブシステムを使用してWindowsC:ドライブのディスク使用量を確認しますLinuxの場合？
二次質問：ここで一体何が起こっているのですか？ Program Filesディレクトリが自分のマシンに存在するよりも10倍多くのスペースを占有しているというレポートを受け取るのはなぜですか？
ちなみに... Windowsによると、Program Filesのサイズは4.83 GBです。これは、File Explorerを使用して、Program Filesフォルダーを右クリックし、[プロパティ]を選択して見つけた事実です。
解決策への私の試み
私が最初に考えたのは、会社のコーディングソフトウェアやウイルス対策プログラムなどにシンボリックリンクやドライブマッピングが含まれている可能性があるため、manページでduを確認しました。私は次の2つのフラグを見つけました。これは役立つと思いました。
-P, --no-dereference don't follow any symbolic links (this is the default) -x, --one-file-system skip directories on different file systems
しかし、du -shP /mnt/c/Program\ Files/、du -shx /mnt/c/Program\ Files/、さらにはdu -shPx /mnt/c/Program\ Files/でさえ2.5Tをくれました。さらに言えば、shouldシンボリックリンクをたどるオプションdu -shLもそうです。 2.5Tを出力します。私が試した他の多分関連するオプションであるdu -shDとdu -shHについても同じで、それらすべてに同じ--2.5Tが与えられました。
私の次の考えは、おそらくWindowsショートカットが物事を台無しにしているので、それらを除外してみました。 （このコードが実際にショートカットをたどることを妨げるかどうかはわかりませんが、試してみる価値があると思いました。）サイコロはありません。
bballdave025@WORK:~$ du -sh --exclude=*.lnk /mnt/c/Program\ Files/
2.5T /mnt/c/Program Files/
偏見を残して、<shudder> Windows Command Line </shudder>から何かを試したり、古いPowerShellスキルをほこりで払ったりすることもできます。弾丸を噛んでFile ExplorerGUIの各ディレクトリに移動し、各フォルダをクリックして[プロパティ]を選択し、最もスペースを占めるサブディレクトリを見つけて、メモリ使用量が最も多いディレクトリに入り、各フォルダをクリックを繰り返すこともできると思います。 。 [睡眠] ...
...しかし、なぜこの奇妙な結果が得られるのか興味があります。 Program Files (x86)を見ると、詰め物のような結果が得られます。 サッカーボール （非アメリカンフットボール）私の口の中で。 （繰り返しになりますが、サイズの比率で話しています。口のボリュームは問題とは関係ありません。）
bballdave025@WORK:~$ du -sh /mnt/c/Program\ Files\ \(x86\)/
11T /mnt/c/Program Files (x86)/
（Windows/File Explorerは22.8GBのサイズを報告しました... 30秒待った後。）
ソースと試行
このスーパーユーザーの回答 から、自分の状況がそうではないことを確認してみるというアイデアが浮かびました
削除したファイルは、おそらくまだプロセスによって開かれています。
bballdave025@WORK:~$ lsof -a +L1 /mnt/c/Program\ Files/
bballdave025@WORK:~$
出力がなかったので、削除したファイルはまだプロセスによって開かれていないと思います。
また、LinuxとCygwinでのさまざまなdu結果について この質問と回答 も調べました。ただし、その質問で説明されているサイズの不一致はごくわずかであったため、問題が類似しているとは思いません。私はそれを確信している間
その場合、同じファイルセットが異なるファイルシステムに保存されたときに異なる[原文のまま]ディスクサイズを使用することは驚くことではありません。
I do同じファイルセットを使用するのは驚きだと思いますany根本的な方法が異なっていても、実際に1か所に保存されている場合はディスクサイズが異なりますそれらにアクセスします。
次のステップ
C:ドライブにフォルダーを作成し、小さなファイルを入れて、ファイルサイズが期待どおりであることを確認することにしました。
bballdave025@WORK:~$ mkdir -p /mnt/c/Users/bballdave025/little_guy
bballdave025@WORK:~$ echo "This should make a small file." > /mnt/c/Users/bballdave025/little_guy/small_file.txt
bballdave025@WORK:~$ du -sh /mnt/c/Users/bballdave025/little_guy/small_file.txt
17K /mnt/c/Users/bballdave025/little_guy/small_file.txt
bballdave025@WORK:~$ du -shPx /mnt/c/Users/bballdave025/little_guy/
17K /mnt/c/Users/bballdve025/little_guy/
17KBは、その小さなテキストファイルでは大きいように見えます。 1文字あたりのバイト数がある場合、31バイトになります。テキストファイルを作成してduをチェックするというその演習が質問に答えるのに役立つかどうかはわかりませんが、それは私の努力の一部です。
行き詰まっています。私は本当にフォルダをクリックしたくありません。また、なぜこの奇妙な振る舞いをするのか知りたいです。何かアイデアはありますか？
システムの詳細
bballdave025@WORK:~$ uname -a | head -n 1
Linux WORK 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
bballdave025@WORK:~$ bash --version | head -n 1
GNU bash, version 4.3.46(1)-release (x86_64-pc-linux-gnu)
bballdave025@WORK:~$ systeminfo.exe | sed -n 's/^OS\ *//p'
Unable to translate current working directory. Using C:\Windows\System32
Name: Microsoft Windows 10 Enterprise
Version: 10.0.15063 N/A Build 15063
Manufacturer: Microsoft Corporation
Configuration: Member Workstation
Build Type: Multiprocessor Free
再生
私はあなたと同じコマンドを試しました：du -sh /mnt/c/Program\ Files/と私の報告は、Windowsが報告したもので正しく報告されました。
バグでパッチが適用されているか、ファイルシステムに私が行っていないことがある可能性があります。リンク/ショートカットの掘り下げはすでに行っていますが、まだ見落とされていることがあるのではないでしょうか。
Bash on Ubuntu on Windows "WSLLegacy"とUbuntuを再確認しましたが、どちらも同じように報告されました。
報告されたバグ に関する質問へのコメントを見たところ、言及されたすべてが修正されたようです????
試すための追加の手順
これが1年以上前に尋ねられたことを考えると、おそらくこの問題はもう発生していません。その多数がどこから来ているのかを特定するために、私が試みるいくつかの追加のステップがあります。
NCDUをインストールする
ncduを試すことをお勧めします。 Ubuntu/WSL [Ubuntu Flavour]には、次の方法でインストールできます。
Sudo apt install ncdu
これにより、システムがクロールされ、スペースの行き先が視覚的に示されます。これは、そのプログラムファイルのマウントでディスクが使用されていると思われる場所を特定するのに役立ちます。これが同じ問題を示しているかどうかを確認したいと思います。 ncduはduを使用していると思いますので、これを回避するために舞台裏でいくつかのフラグを使用しない限り、同じように表示されると思います。
Program FilesDirectoryの使用状況のみを表示
ncduを使用して特定のディレクトリのみをクロールするのは、非常に簡単です。次のコマンドを使用して、WindowsのProgram Filesディレクトリの使用状況のみを表示できます。
ncdu /mnt/c/Program\ Files
解決
特にファイルシステムが間違いなくNTFSであることを考えると、Windowsを使用してWindowsオペレーティングシステムのディスク使用量を判断することをお勧めします。
WSLインスタンスだけでディスク使用量を確認する場合は、ncduを使用し、/mntディレクトリを無視して、Linuxシステムの使用量のみを表示し、Windowsマウントは表示しないことをお勧めします。
誤解しないでください、私の興味はあなたの状況で何が起こっているかについても同様に刺激されます。
Windowsマウントを無視してLinuxのディスク容量を確認する
Windowsマウントを無視してLinuxディスクの使用状況を確認するには、次のコマンドを実行できます。
ncdu --exclude /mnt
小さなファイルがより多くのデータを使用する理由
正しく思い出せば、テキストファイルに数文字しか入力しなくても、ドライブのセクターを占有していることになります。ダブルチェックNTFSドライブシステムではこれを再現できませんでしたが、FAT32では再現できました。 NTFSはWindowsで使用されるため、Linuxを介したレポートは、Linuxが使用しているファイルシステムの解釈を通じて表示されている可能性があります。
以前は、一部のアプリは数千の小さなファイルを作成し、100万の紙切れによる死のようでした。また、何千もの小さなファイルを転送すると、1つの大きな連続ファイルよりもはるかに時間がかかります。
実際のサイズとディスク上で占めるサイズを確認できることに注意してください。
これがディスクレポートに大きな不一致が見られる理由ではないかと思いますが、何百万もの小さなファイルがある場合は興味深いかもしれません。一部のキャッシュ/ストレージスキームは、迅速なバイナリ検索アクセスのために多くの小さなファイルに分岐する傾向があります。
