문제

문제

문제

분명히 루트 파티션의 디스크 공간이 부족합니다. 내 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번의 공연을 더 주는 것이 좋을 것입니다)
  2. 이전 커널 버전을 삭제하고 문제가 발생하지 않기를 바랍니다. 지금은 확보된 245MB이면 충분합니다.

나는 루트에 더 많은 공간을 제공하는 것을 선호하지만, 어떻게 해야 할지, 아니면 아예 엉망으로 만드는 것이 좋은 생각인지 전혀 모릅니다. 어떤 솔루션을 제안하시겠습니까? 어떻게 그렇게 할 수 있나요?

답변1

/dev/sda2다른 마운트 지점(다른 콘텐츠가 있어야 하는 위치)에 마운트하면 Btrfs를 사용하고 있다고 믿게 됩니다. 당신 /.snapshots은 또한도미. /.snapshots사용 공간의 대부분을 차지할 가능성이 높습니다 .

glob은 로 시작하는 이름으로 확장되지 않기 때문에 분석은 du -hsx /*고려되지 않았습니다 ./.snapshots*.

나는 Snapper에 대한 경험이 없습니다. 내부에 Btrfs 하위 볼륨(shapshots)이 있는 것 같습니다 /.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일입니다.

자동 스냅샷 정리 작업은 다음 두 가지 방법으로 관리할 수 있습니다.

  1. 크론 스케줄러( /etc/cron.daily/suse.de-snapper).
  2. systemd 타이머 스케줄러( snapper-cleanup.timersnapper-cleanup.servicesystemd 장치).

기본적으로 cron 메커니즘이 사용됩니다.

이 정리 메커니즘에 문제가 있는 것은 아닐까요?

말씀드린 대로 저는 Snapper에 대한 경험이 없기 때문에 더 이상 도움을 드릴 수 없습니다. 그러나 제가 옳다면 이제 무엇을 조사해야 할지 아실 것입니다. 요약:

  • 당신은 디렉토리를 완전히 놓쳤습니다 /.snapshots. 사용된 공간의 대부분을 담당할 가능성이 높습니다.
  • Btrfs 스냅샷이 관련되었을 수 있습니다.
  • Snapper가 관련되었을 가능성이 높습니다.

답변2

가장 먼저 해야 할 일은 중요한 내용을 백업하는 것입니다. 이 경로를 더 진행하려면 데이터 손실이 발생할 수 있는 작업을 수행해야 합니다. 아래의 일부 옵션:

  • 새 USB SATA 하드 드라이브를 구입하세요. 케이스에 있는 USB SATA 드라이브를 기존 드라이브로 교체하세요. 새 SATA 드라이브에 Linux를 다시 설치합니다. 이전 파일에 액세스해야 할 때마다 USB 드라이브를 연결하면 해당 파일이 저장됩니다.

  • LVM을 사용하여 파티션을 나눈 경우(SuSE는 그렇지 않았을 것임) lvmresize -L+10G /dev/mapper/whatever슬래시 파티션을 확장( )한 다음 크기를 조정할 수 있는지( resize2fs /dev/mappper/whatever) 확인하십시오. 이것이 가장 쉬운 수정입니다.

  • 하드 파티션이 있는 경우(예: 루트가 켜져 있음 /dev/sda1) Gparted Live로 부팅해 볼 수 있습니다(https://gparted.org/livecd.php) 그리고 하드 파티션을 확장하려고 애쓰는 원숭이들. 일반적으로 여기서 성공 여부는 드라이브에 남은 여유 공간과 파티션을 어떻게 분할했는지에 따라 달라집니다.

  • 새 하드 드라이브를 구입하세요. 용량은 같거나 더 큽니다. 그것을 연결하고 더 큰 파티션을 생성하십시오(가능하면 LVM을 사용하십시오). 새 디스크의 첫 번째 파티션은 크기가 1G여야 하며(더 작을 수도 있고 간단할 수도 있음) Grub 호환성을 위해 존재합니다. 그런 다음 기존 디스크로 부팅하고 에 디렉터리를 만들고 새 디스크 파티션을 마운트합니다 /mnt/new_disk/. 모든 기존 파티션을 새 디스크로 재동기화합니다. (예: rsync -av / /mnt/new_disk/slash/; rsync -av /usr /mnt/new_disk/usr/;...). 작업을 마친 후에는 어떻게든 새 디스크에 grub을 설치해야 합니다. 나는 보통 chroot into를 사용하여 이 작업을 수행 /mnt/new_disk/slash/하지만 이는 어려울 수 있습니다. 일반적으로 grub.cfg는 사물에 대해 혼란스러워합니다. 더 쉬운 방법이 있어야 합니다.

관련 정보