私は一般的なWindowsユーザーであり、時にはスペースとマシンが利用可能なときにLinuxでタスクを開発します。 Microsoft AzureとUbuntuの仮想マシンを直接使用しているので、このエラーは奇妙に見えます。 /dev/のように結合されたメモリの代わりにマウントが多いのはなぜですか?完全にマージできませんか?空き領域がある領域から空き領域に空き領域を再割り当てできるコマンドは端末にありますか?
私は入ったdf-i何が起こったのか見てください。結果は次のとおりです。
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/root 3870720 396517 3474203 11% /
devtmpfs 2048512 464 2048048 1% /dev
tmpfs 2049470 63 2049407 1% /dev/shm
tmpfs 2049470 1051 2048419 1% /run
tmpfs 2049470 4 2049466 1% /run/lock
tmpfs 2049470 18 2049452 1% /sys/fs/cgroup
/dev/loop0 10833 10833 0 100% /snap/core18/2246
/dev/loop1 10836 10836 0 100% /snap/core18/2253
/dev/loop2 11736 11736 0 100% /snap/core20/1242
/dev/loop3 11776 11776 0 100% /snap/core20/1270
/dev/loop5 796 796 0 100% /snap/lxd/21835
/dev/sdb15 0 0 0 - /boot/efi
/dev/loop6 479 479 0 100% /snap/snapd/14295
/dev/loop7 479 479 0 100% /snap/snapd/14066
/dev/loop4 5777 5777 0 100% /snap/docker/1125
/dev/sda1 2097152 12 2097140 1% /mnt
tmpfs 2049470 37 2049433 1% /run/user/123
tmpfs 2049470 64 2049406 1% /run/user/1000
/dev/loop8 2268 2268 0 100% /snap/intellij-idea-community/337
/dev/loop9 40310 40310 0 100% /snap/postman/149
df -h:
Filesystem Size Used Avail Use% Mounted on
/dev/root 29G 27G 2.2G 93% /
devtmpfs 7.9G 0 7.9G 0% /dev
tmpfs 7.9G 83M 7.8G 2% /dev/shm
tmpfs 1.6G 1.5M 1.6G 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup
/dev/loop1 56M 56M 0 100% /snap/core18/2253
/dev/loop0 56M 56M 0 100% /snap/core18/2246
/dev/loop2 62M 62M 0 100% /snap/core20/1242
/dev/loop3 818M 818M 0 100% /snap/intellij-idea-community/337
/dev/sdb15 105M 5.2M 100M 5% /boot/efi
/dev/loop4 62M 62M 0 100% /snap/core20/1270
/dev/loop5 169M 169M 0 100% /snap/postman/149
/dev/loop7 68M 68M 0 100% /snap/lxd/21835
/dev/loop6 44M 44M 0 100% /snap/snapd/14295
/dev/loop8 117M 117M 0 100% /snap/docker/1125
/dev/loop9 43M 43M 0 100% /snap/snapd/14066
/dev/sda1 32G 49M 30G 1% /mnt
tmpfs 1.6G 20K 1.6G 1% /run/user/123
tmpfs 1.6G 28K 1.6G 1% /run/user/1000
答え1
Azure仮想マシンを使用しているので、通常はAzureが提供するディスクパーティションスキームを取得します。
マウントは、RAMにロードされ、主にカーネルでデバイスファイルを使用可能にするために使用される一時ファイルシステムであるファイルシステム/dev
です。devtmpfs
マウントは/run
RAMにロードされた一時ファイルシステムでもあり、一時systemd
ファイルスペースが必要なサービスやその他のサービスで主に使用されます。
/snap
install を使用したパッケージのインストール壊れる。これらの悪用loop
装備通常書くことはできません。これらの場所のいずれかに書き込もうとすると、ある種の「デバイスにスペースがない」エラーが発生します。これはdf -h
、これらのインストールが100%使用中としてマークされていることを意味します。
利用可能なすべてのディスク容量は、2つのデバイスに割り当てられているようです。
/dev/root
/
これは、ルートファイルシステムとも呼ばれる29G、27Gの使用、および2.2Gの残りの使用可能スペースとマウントされたスペースを報告します。ほとんどのデータがここにあるようです。このコマンドは、du -h --max-depth=1 /
ディスク領域が使用されている場所を表示する必要があります。
/dev/sda1
合計32Gのスペース、40Mの使用スペース、約30Gの残りの空きスペースを報告し、その/mnt
場所を使用してデータを保存するように構成できる必要があります。
Azureがディスクをこのように処理する理由についての答えを得るには、Azureに尋ねる必要があります。 2つのデータディスクスペースを組み合わせて合計60Gのスペースを持つ単一のインストールで提供したい場合は、この基準を満たす仮想マシンを提供できます。
答え2
ご覧のとおり、これらの「フル」ファイルシステムはすべて/dev/loop
デバイスです。ディスクではなくファイルにマップされます。たとえば、ISOイメージをマウントして同じ結果を見ることができます。これはから抜粋したものです。man
ページ:
ループデバイスは、データブロックをハードディスクや光学ドライブなどの物理デバイスではなく、ファイルシステムの通常のファイルブロックまたは他のブロックデバイスにマッピングするブロックデバイスです。
答え3
より進化した方法:あなたが所有するすべての「デバイス」にはマウントポイントがあります。ファイルをマージする方法はなく、「デバイス」間に空き領域を再配布したくありません。つまり、ファイルが保存した場所とは異なる「デバイス」にあることになります。
あなたが考える限り、実際の問題はありません。すべてのファイルシステム全体はループデバイス(つまりファイルに対応する「デバイス」)であり、/ snapにマウントされます。スナップがどのように機能するかはわかりませんが、仮想ファイルシステムが含まれているという事実は驚くべきことではありません。
答え4
@Jeredriq Demas: Azure Linux VM で同様の問題に直面しました。この問題を解決しましたか?それでは、ソリューションを公開できますか?