OpenSUSE Leap'ta "Dosya Sistemi Kökü" Düşük Disk Alanı hatası 15


0

Sorun

Görünüşe göre kök bölümümdeki disk alanım azalıyor. İşletim sistemimi kurarken (VM'de openSUSE Leap 15) Varsayılan bölümlemeyi seçtim. Şimdi "Dosya sistemi kökü" uyarısı / Hata Düşük Disk Alanı alıyorum . Sisteme başladığımda beni uyarıyor ve büyük bir projeyi derlemeye çalıştığımda hata veriyor.

analiz

Depolama durumunu kontrol edelim:

rapor dosya sistemi disk alanı kullanımı:

$ 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

Tahmini dosya alanı kullanımı:

$ 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

Anlık görüntüleri @Kamil Maciorowsk tarafından önerilen şekilde listeleme:

$ 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

Eski kullanılmayan Çekirdekleri de duydum, bu yüzden onu kontrol ettim ve şunu buldum:

$ 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

Bir Çözüm İçin Fikirler:

  1. Kök bölümünü yeniden boyutlandırın. (10 tane daha konser veren kök güzel olurdu)
  2. Eski çekirdek sürümünü silmek ve umarım bir şeyleri bozmuyorum ve serbest bırakılan 245 MB şimdilik yeterli olacak.

Ben gerçekten iyilik yapıyorum, sadece köklere daha fazla yer verin, ama bunun nasıl yapılacağına dair bir fikrim yok veya bununla uğraşmak iyi bir fikirse. Hangi çözümü önerirsiniz ve bunu nasıl yapabilirim?

Yanıtlar:


0

Yapılacak ilk şey, önemli bir şeyin yedeğini almaktır. Bu yolda daha da ileri gitmek veri kaybına neden olabilecek şeyleri yapmaktan geçer. Aşağıdaki bazı seçenekler:

  • yeni bir USB SATA sabit sürücü satın alın. USB SATA sürücüsünü eski sürücünüzle durumdayken değiştirin. Linux'u yeni SATA sürücüsüne tekrar yükleyin. Eski dosyalarınıza erişmek istediğinizde, USB sürücüyü takın ve işte bunlar.

  • LVM'yi kullanarak bölümlere ayırdıysanız (ki SuSE'nin muhtemelen kullanmamış olduğu), o zaman lvmresize -L+10G /dev/mapper/whatevereğik çizgi bölümünüzü genişletip genişletemeyeceğinizi ve sonra resize ( resize2fs /dev/mappper/whatever) yapıp yapamayacağınızı görün . Bu en kolay çözümdür.

  • Eğer zor bölümleriniz varsa (örneğin: root açıksa /dev/sda1), o zaman Gparted Live ( https://gparted.org/livecd.php ) ile önyüklemeyi deneyebilir ve etrafınızdaki sabit bölümünüzü genişletmeye çalışabilirsiniz . Genel olarak, buradaki başarı, sürücünüzde ne kadar boş alan kaldığını ve işleri nasıl bölümlendirdiğinizi belirler.

  • yeni bir sabit disk satın alın. Aynı kapasite veya daha büyük. takın ve daha büyük bölümler oluşturun (mümkünse LVM kullanın). Yeni diskteki ilk bölüm 1G boyutunda olmalıdır (daha küçük olabilir, sadece kısa olabilir) ve Grub uyumluluğu için oradadır. Daha sonra, eski diskinize önyükleme yapın ve dizinler oluşturun / yeni disk bölümlerini takın /mnt/new_disk/; Tüm eski bölümleri yeni diske rsync. (örneğin: rsync -av / /mnt/new_disk/slash/; rsync -av /usr /mnt/new_disk/usr/;...). Bitirdikten sonra bir şekilde gruba yeni bir disk kurmanız gerekecek. Bunu genellikle içine bir chroot kullanarak yapıyorum /mnt/new_disk/slash/ama göz korkutucu olabilir. Genellikle grub.cfg şeyler hakkında kafasını karıştırır. Bunu yapmanın daha kolay yolları olmalı.


0

/dev/sda2farklı bağlama noktalarına (farklı içeriğe sahip olmanız gereken yerde) monte edildiğinde, Btrfs kullandığınıza inanıyorsunuz. Ayrıca Snapper'ın/.snapshots varlığını belirten monte ettiniz . Kullanılan alanın çoğunu alan son derece muhtemeldir ./.snapshots

İle analiz Not du -hsx /*bile sürmedi /.snapshotsçünkü dikkate *glob ile başlayan isimlere genişletmek vermez ..

Snapper ile hiçbir deneyimim yok. İçinde Btrfs subvolumes (shapshots) bulunduğundan şüpheleniyorum /.snapshots. Komut du -hsx /.snapshots, kullanılan seçenek 0nedeniyle bile dönebilir -x. Öte yandan du -hs /.snapshots, muhtemelen büyük bir değer getirecektir. Büyüklüğünden çok daha büyük olabilir /dev/sda2( 40GiBçünkü) , muhtemelen disk alanını paylaşan birden fazla anlık fotoğrafa sahip olabilirsiniz (Btrfs bu şekilde çalışır), yine dude ayrı ayrı dosya sistemleri olduğunu düşünecektir.

Daha fazla analiz etmek için Btrfs'e özgü ve / veya Snapper aletlerine ihtiyacınız var. Btrfs ile biraz tecrübem var ama Snapper ile değil. Snapper'ı, oluşturduğu anlık görüntüleri elle yöneterek karıştırıp karıştırmayacağınızı söyleyemem, mümkün olabilir; ama eminim ki Snapper kullanarak Btrfs'i kıramazsın. Bu nedenle güvenli yaklaşım, durumu doğrudan Btrfs araçlarıyla değil Snapper'in sağladığı şeyle ele almaktır.

Bahsedilen eğitimde bize yapabilecekleriniz hakkında bazı ipuçları verilmektedir:

  • Varsayılan yapılandırma (kök) için tüm anlık görüntüleri listele

    snapper list
    
  • Anlık Fotoğrafları Silme

    Varsayılan (kök) yapılandırma için anlık görüntü 65'i silin:

    snapper delete 65
    

Ayrıca:

Otomatik Anlık Görüntü Temizleme Mekanizmaları

Disk alanının dolmasını önlemek için, Snapper anlık görüntüleri düzenli aralıklarla temizler. Varsayılan olarak, bu süre = 1 gün.

Otomatik anlık görüntü temizleme görevi 2 yolla yönetilebilir:

  1. cron zamanlayıcısı ( /etc/cron.daily/suse.de-snapper).
  2. sistemd zamanlayıcı zamanlayıcı ( snapper-cleanup.timerve snapper-cleanup.servicesistemd birimleri).

Varsayılan olarak, cron mekanizması kullanımdadır.

Belki bu temizleme mekanizmasında bir sorun var?

Dediğim gibi Snapper ile hiçbir deneyimim yok, bu yüzden size daha fazla yardımcı olamam. Ancak, eğer haklıysam, şimdi ne araştırılacağını biliyorsunuz. Özetlemek:

  • /.snapshotsDizini tamamen kaçırdınız , büyük olasılıkla kullanılan alanın çoğundan sorumludur;
  • Btrfs anlık görüntüleri muhtemelen karışıyor;
  • Snapper muhtemelen işin içinde.

Snapper listesi 65'i silmemiştir, çünkü snapper listesi 65 ile herhangi bir öğe göstermedi. Listelenmemiş mi?
İnsan

@Human Bu sadece bir örnek…
Kamil Maciorowski

Üzgünüm, başka bir problem nedeniyle çözümünüzü bozuk sistemimde test edemedim. Tam bir yeniden yükleme yapmak zorunda kaldım, ama çoğunlukla haklıydınız, bir sürü btrfs görüntüsü vardı. Ama gerçek boyutlarını bulamadım. Bir btrfs komutu var mı? Ayrıca cronumda / günlük olarak, snapper-işi yoktu, ama sistemd zaman çizelgesinde bir snapper-temizleme buldum systemctl list-timers.
İnsan

Tam bir kök bölümü olan ve nedenini bilmeyen diğer kullanıcılar için daha yararlı hale gelmesi için sorumu nasıl yeniden yazabileceğime dair bir fikrin var mı? Yani btrfs bölümleri ve gizli klasörlerle çalışan tam bir analiz yararlı olabilir mi?
İnsan

@Human Bir anlık görüntüyü silerseniz ne kadar alan boşaltacağını tahmin etmenin güvenilir bir yolunu bilmiyorum. Değerleri (bunları biliyorsanız) eklemediğinize dikkat edin (tek içerik olarak iki büyük özdeş görüntüyü hayal edin; herhangi bir birinin silinmesi hiçbir şeyi değiştirmez, ancak ikisini de silerseniz çok fazla para kazanırsınız). Sorunu nasıl değiştireceğimi bilmiyorum, özellikle de kurulumu kaybettikten sonra. Herhangi bir "kobay işletim sistemi" olmadan "tam bir analiz" yazmanın zor olduğunu düşünüyorum. Eğer Snapper ile bir deneyimim olsaydı, o zaman belki bu konuda yardımcı olabilirdim. Soru (olduğu gibi) olsa da işe yaramaz değil.
Kamil Maciorowski
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.