☰

問題

tag-icon • tag-icon linux partitioning filesystems root opensuse
問題

問題

どうやらルートパーティションのディスク容量が不足しているようです。OS（VM上のopenSUSE Leap 15）をインストールしたときに、デフォルトのパーティション分割を選択しました。今、警告/エラーが表示されます。「ファイルシステム ルート」のディスク容量が不足していますシステムを起動すると警告が表示され、大きなプロジェクトをコンパイルしようとするとエラーが発生します。

分析

保管状況を確認してみましょう:

ファイルシステムのディスク領域の使用状況を報告します:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs         13G     0   13G   0% /dev
tmpfs            13G   34M   13G   1% /dev/shm
tmpfs            13G   82M   13G   1% /run
tmpfs            13G     0   13G   0% /sys/fs/cgroup
/dev/sda2        40G   38G  2.2G  95% /
/dev/sda2        40G   38G  2.2G  95% /root
/dev/sda2        40G   38G  2.2G  95% /boot/grub2/i386-pc
/dev/sda3       204G  165G   40G  81% /home
/dev/sda2        40G   38G  2.2G  95% /boot/grub2/x86_64-efi
/dev/sda1       500M  5.0M  495M   1% /boot/efi
/dev/sda2        40G   38G  2.2G  95% /usr/local
/dev/sda2        40G   38G  2.2G  95% /srv
/dev/sda2        40G   38G  2.2G  95% /opt
/dev/sda2        40G   38G  2.2G  95% /.snapshots
/dev/sda2        40G   38G  2.2G  95% /tmp
/dev/sda2        40G   38G  2.2G  95% /var
tmpfs           2.6G   20K  2.6G   1% /run/user/462
tmpfs           2.6G   48K  2.6G   1% /run/user/1000

ファイルスペースの使用量を推定します:

$ sudo du -hsx /* | sort -rh | head -n 40
[sudo] password for root: 
du: cannot access '/proc/8809/task/8809/fd/4': No such file or directory
du: cannot access '/proc/8809/task/8809/fdinfo/4': No such file or directory
du: cannot access '/proc/8809/fd/4': No such file or directory
du: cannot access '/proc/8809/fdinfo/4': No such file or directory
51G /home
5.5G    /usr
972M    /opt
894M    /var
792M    /lib
63M /boot
38M /tmp
24M /etc
18M /run
11M /sbin
11M /lib64
2.1M    /bin
320K    /root
0   /sys
0   /srv
0   /selinux
0   /proc
0   /mnt
0   /dev

$ sudo du -hsx /.snapshots
2.2M    /.snapshots

$ sudo du -hs /.snapshots
129G    /.snapshots

@Kamil Maciorowsk の提案に従ってスナップショットをリストします:

$ sudo snapper list
 Type   | #   | Pre # | Date                             | User | Cleanup | Description           | Userdata     
-------+-----+-------+----------------------------------+------+---------+-----------------------+--------------
single | 0   |       |                                  | root |         | current               |              
single | 1   |       | Tue 02 Oct 2018 02:42:20 PM CEST | root |         | first root filesystem |              
pre    | 74  |       | Mon 08 Oct 2018 03:25:32 PM CEST | root | number  | zypp(zypper)          | important=yes
post   | 75  | 74    | Mon 08 Oct 2018 03:27:17 PM CEST | root | number  |                       | important=yes
pre    | 82  |       | Tue 16 Oct 2018 09:11:33 AM CEST | root | number  | zypp(zypper)          | important=yes
post   | 83  | 82    | Tue 16 Oct 2018 09:12:04 AM CEST | root | number  |                       | important=yes
pre    | 108 |       | Thu 01 Nov 2018 01:25:41 PM CET  | root | number  | zypp(zypper)          | important=yes
post   | 109 | 108   | Thu 01 Nov 2018 01:27:12 PM CET  | root | number  |                       | important=yes
pre    | 122 |       | Thu 08 Nov 2018 09:26:09 AM CET  | root | number  | zypp(zypper)          | important=yes
post   | 123 | 122   | Thu 08 Nov 2018 09:27:40 AM CET  | root | number  |                       | important=yes
pre    | 128 |       | Mon 12 Nov 2018 08:40:03 AM CET  | root | number  | zypp(zypper)          | important=yes
post   | 129 | 128   | Mon 12 Nov 2018 08:41:36 AM CET  | root | number  |                       | important=yes
pre    | 144 |       | Mon 19 Nov 2018 09:52:15 AM CET  | root | number  | zypp(zypper)          | important=no 
post   | 145 | 144   | Mon 19 Nov 2018 09:54:33 AM CET  | root | number  |                       | important=no 
pre    | 146 |       | Wed 21 Nov 2018 11:07:33 AM CET  | root | number  | zypp(zypper)          | important=no 
post   | 147 | 146   | Wed 21 Nov 2018 11:07:56 AM CET  | root | number  |                       | important=no 
pre    | 148 |       | Thu 22 Nov 2018 09:19:51 AM CET  | root | number  | zypp(zypper)          | important=no 
post   | 149 | 148   | Thu 22 Nov 2018 09:19:54 AM CET  | root | number  |                       | important=no 
pre    | 150 |       | Mon 26 Nov 2018 09:12:02 AM CET  | root | number  | zypp(zypper)          | important=no 
post   | 151 | 150   | Mon 26 Nov 2018 09:12:19 AM CET  | root | number  |                       | important=no 
pre    | 152 |       | Thu 29 Nov 2018 09:34:37 AM CET  | root | number  | zypp(zypper)          | important=no 
post   | 153 | 152   | Thu 29 Nov 2018 09:35:22 AM CET  | root | number  |                       | important=no

古い未使用のカーネルについても聞いたことがあるので、調べてみたところ、次のことがわかりました。

$ ls -la /lib/modules
total 0
drwxr-xr-x 1 root root 108 Nov  8 09:29 .
drwxr-xr-x 1 root root  78 Oct  4 16:13 ..
drwxr-xr-x 1 root root 354 Oct 16 09:11 4.12.14-lp150.12.22-default
drwxr-xr-x 1 root root 354 Nov  8 09:26 4.12.14-lp150.12.25-default

解決策のアイデア:

  1. ルート パーティションのサイズを変更します。(ルートにさらに 10 GB 割り当てると便利です)
  2. 古いカーネル バージョンを削除して、何も壊さないことを願っています。解放された 245 MB で今のところは十分でしょう。

私はルートにもっと多くのスペースを与えることを本当に望んでいますが、それをどのように行うのか、あるいはそれをいじることがそもそも良い考えであるのかどうか、全く分かりません。どのような解決策を提案しますか、また、それをどのように実行できますか?

答え1

/dev/sda2異なるマウントポイント（異なるコンテンツがあるはず）にマウントされているので、Btrfsを使用していると思われます。また、/.snapshotsマウントされているので、スナッパー/.snapshots使用スペースの大部分を占める可能性が高いです。

glob は で始まる名前には展開されないため、を使用した分析では が考慮du -hsx /*されていないことに注意してください。/.snapshots*.

Snapper の経験はありません。 内に Btrfs サブボリューム (スナップショット) があると思われます。 使用されたオプションが原因で、/.snapshotsコマンドdu -hsx /.snapshotsが を返す場合もあります。 一方、はおそらく非常に大きな値を返します。 のサイズ( )よりもはるかに大きい可能性があります。これは、おそらくディスク領域を共有する複数のスナップショットがあるためです (これが Btrfs の動作方法です)。それでも、それらは別々のファイルシステムであるとみなされます。0-xdu -hs /.snapshots/dev/sda240GiBdu

さらに分析するには、Btrfs 固有のツールや Snapper ツールが必要です。私は Btrfs の経験はありますが、Snapper の経験はありません。Snapper が作成したスナップショットを手動で変更して Snapper を混乱させることができるかどうかはわかりませんが、可能かもしれません。しかし、Snapper を使用して Btrfs を壊すことはできないはずです。したがって、安全なアプローチは、Btrfs ツールを直接使用するのではなく、Snapper が提供するものを使用して状況に対処することです。

すでに述べたチュートリアル何ができるかについていくつかのヒントを示します:

  • デフォルト構成（ルート）のすべてのスナップショットを一覧表示します

    snapper list

  • スナップショットの削除

    デフォルト (ルート) 構成のスナップショット 65 を削除します。

    snapper delete 65

だけでなく：

自動スナップショットクリーンアップメカニズム

ディスク容量がいっぱいになるのを防ぐために、Snapper は定期的にスナップショットをクリーンアップします。デフォルトでは、この期間は 1 日です。

自動スナップショット クリーンアップ タスクは、次の 2 つの方法で管理できます。

  1. cron スケジューラ ( /etc/cron.daily/suse.de-snapper)。
  2. systemd タイマー スケジューラ (snapper-cleanup.timerおよびsnapper-cleanup.servicesystemd ユニット)。

デフォルトでは、cron メカニズムが使用されています。

このクリーンアップメカニズムに何か障害が発生したのでしょうか?

前にも言ったように、私は Snapper の経験がないので、これ以上お手伝いすることはできません。しかし、私の言うことが正しければ、何を調査すればよいかがわかるでしょう。まとめると、次のようになります。

  • ディレクトリを完全に見落としています/.snapshots。おそらく、使用済みスペースの大部分はディレクトリが原因です。
  • Btrfs スナップショットが関係している可能性があります。
  • おそらくスナッパーが関与していると思われます。

答え2

まず最初に、重要なもののバックアップを作成してください。この方法をさらに進めると、データ損失につながる可能性があります。以下にいくつかのオプションを示します。

  • 新しい USB SATA ハード ドライブを購入します。ケース内の古いドライブと USB SATA ドライブを交換します。新しい SATA ドライブに Linux を再インストールします。古いファイルにアクセスする必要があるときはいつでも、USB ドライブを接続するだけでアクセスできます。

  • lvmresize -L+10G /dev/mapper/whateverLVM を使用してパーティション分割している場合 (SuSE ではおそらくそうではありません) 、スラッシュ パーティションを拡張 ( ) してからサイズを変更 ( ) できるかどうかを確認しますresize2fs /dev/mappper/whatever。これが最も簡単な修正方法です。

  • ハードパーティションがある場合（例：ルートがオンになっている場合/dev/sda1）、Gparted Live（参考:) ハード パーティションを拡張しようと試行錯誤します。一般的に、ここでの成功は、ドライブにどれだけの空き領域が残っているか、またパーティションをどのように分割したかによって決まります。

  • 新しいハード ドライブを購入します。容量は同じかそれ以上です。接続して、より大きなパーティションを作成します (可能な場合は LVM を使用します)。新しいディスクの最初のパーティションのサイズは 1G である必要があります (短くするため、これより小さくてもかまいません)。これは、Grub との互換性のためです。その後、古いディスクを起動し、ディレクトリを作成するか、新しいディスク パーティションをマウントします/mnt/new_disk/。すべての古いパーティションを新しいディスクに rsync します (例: rsync -av / /mnt/new_disk/slash/; rsync -av /usr /mnt/new_disk/usr/;...)。完了したら、何らかの方法で新しいディスクに grub をインストールする必要があります。私は通常、chroot を使用してこれを行います/mnt/new_disk/slash/が、これは困難な場合があります。通常、grub.cfg は混乱します。もっと簡単な方法があるはずです。

関連情報