OpenSolaris altında bir dosyayı kaldırırken cihazda yer yok

İstemci kutusuna bir NFS paylaşımını ( OpenIndiana sunucusundan dışa aktarılır ) bağlamaya çalışırken OI sunucusu çöktü. Bir günlük dökümü gibi görünen siyah ölüm ekranını aldım, sonra sistem yeniden başladı. Asla geri gelmedi ve önyüklemeyi durdurduktan sonra aşağıdaki hata mesajını alıyorum:

svc.startd[9] Could not log for svc:/network/dns/mulitcast:default: write(30) failed with No space left on device?

Önyükleme sürücüsünde işletim sistemi dışında başka bir şeyim yok ... Sürücüyü ne doldurabileceğinden emin değilim? Belki bir tür günlük dosyası? Ne olursa olsun hiçbir şeyi silemiyorum. Herhangi bir şeyi silmeye çalıştığımda bana boşluk bırakmıyor:

$ rm filename
cannot remove 'filename' : No space left on device 

"Bakım Modu" na giriş yapabilirim, ancak standart kullanıcı istemine giremiyorum.

Çıktı df:

rpool/ROOT/openindiana-baseline    4133493    4133493          0    100%   /
swap                              83097900      11028  830386872      1%   /etc/svc/volatile
/usr/lib/libc/libc_hwcap1.so.1     4133493    4133493          0    100%   /lib/libc.so.1

Çıktı mount:

/ on rpool/ROOT/openindiana-baseline read/write/setuid/devices/dev:2d9002 on Wed Dec 31 16:00:00 1969
/devices on /devices read/write/setuid/devices/dev:8b40000 on Fri Jul 8 14:56:54 2011
/dev on /dev read/write/setuid/devices/dev:8b80000 on Fri Jul 8 14:56:54 2011
/system/contract on ctfs read/write/setuid/devices/dev:8c40001 on Fri Jul 8 14:56:54 2011
/proc on proc read/write/setuid/devices/dev:8bc0000 on Fri Jul 8 14:56:54 2011
/etc/mnttab on mnttab read/write/setuid/devices/dev:8c80001 on Fri Jul 8 14:56:54 2011
/etc/svc/volatile on swap read/write/setuid/devices/xattr/dev:8cc0001 on Fri Ju8 14:56:54 2011
/system/object on objfs read/write/setuid/devices/dev:8d00001 on Fri Jul 8 14:6:54 2011
/etc/dfs/sharetab on sharefs read/write/setuid/devices/dev:8d40001 on Fri Jul 14:56:54 2011
/lib/libc.s0.1 on /usr/lib/libc/libc_hucap1.s0.1 read/write/setuid/devices/dev:d90002 on Fri Jul 8 14:57:06 2011 

'Zfs list -t all' çıktısı:

rpool                                                       36.4G   0       47.5K   /rpool
rpool/ROOT                                                  4.23G   0         31K   legacy
rpool/ROOT/openindiana                                      57.5M   0       3.99G   /
rpool/ROOT/openindiana-baseline                             61K     0       3.94G   /
rpoo1/ROOT/openindiana-system-edge                          4.17G   0       3.98G   /
rpool/ROOT/openindiana-system-edge@install                  19.9M   -       3 38G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:45:08      73.1M   -       3.57G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:48:53      75.9M   -       3 82G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:14:04      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:15:14      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:28:14      61K     -       3.94G   -
rpool/ROOT/openindiana-system-stable                        61K     0       3.94G   /
rpoo1/ROOT/pre_first_update_07.06                           108K    0       3 82G   /
rpool/ROOT/pre_second_update_07.06                          90K     0       3.57G   /
rpool/dump                                                  9.07G   0       9.07G   -
rpool/export                                                3.85G   0       32K     /export
rpool/export/home                                           3.85G   0       32K     /export/home
rpool/export/home/admin                                     3.85G   0       3.85G   /export/home/admin
rpool/swap                                                  19.3G   19.1G   126M    -

Tamam, bu garip bir… bir dosyayı kaldırmak için yeterli alan yok!

Anlık görüntülere sahip herhangi bir dosya sisteminde potansiyel olarak ortaya çıkabilmesine rağmen, bu ZFS ile ilgili nispeten yaygın bir sorun olarak ortaya çıkıyor .

Açıklama, silmeye çalıştığınız dosyanın hala bir anlık görüntüde var olduğudur. Bu nedenle, sildiğinizde, içerik varlığını korur (yalnızca anlık görüntüde); ve sistem ayrıca anlık görüntünün dosyaya sahip olduğu ancak geçerli durumun sahip olmadığı bilgisini yazmalıdır. Biraz fazla bilgi için yer kalmadı.

Kısa vadeli bir düzeltme, en son anlık görüntüden sonra oluşturulan bir dosyayı bulmak ve silmek. Başka bir olasılık, en son anlık görüntüden sonra eklenen bir dosyayı bulmak ve en son anlık görüntü anında sahip olduğu boyuta göre kısaltmaktır. Günlüklerinizde bir şey spam olduğu için diskiniz doluysa, en büyük günlük dosyalarını kırpmayı deneyin.

Daha genel olarak uygulanabilir bir düzeltme, bazı anlık görüntüleri kaldırmaktır. İle anlık görüntüleri listeleyebilirsiniz zfs list -t snapshot. Belirli bir anlık görüntüyü yok ederseniz ne kadar alan kazanılacağını tahmin etmenin kolay bir yolu yoktur, çünkü depoladığı veriler diğer anlık görüntüler tarafından ihtiyaç duyulabilir ve bu anlık görüntüyü yok ederseniz canlı olarak kalır. Bu nedenle, gerekirse verilerinizi başka bir diske yedekleyin, artık ihtiyacınız olmayan bir veya daha fazla anlık görüntüyü belirleyin ve çalıştırın zfs destroy name/of/snap@shot.

Bu OpenSolaris forumları iş parçacığında bu konuyla ilgili geniş bir tartışma var .

Bu, üzerine yazma dosya sistemleri ile ilgili bilinen bir sorundur: Bir dosyayı silmek için, dosya sisteminin önce bir blok tahsis etmesi ve yeni silinen dosyanın içerdiği alanın zenginliğini serbest bırakmadan önce yeni durumu düzeltmesi gerekir.

( Anlık görüntü içeren dosya sistemleri ile ilgili bir sorun değildir , çünkü bunları uygulamanın üzerine yazma işleminden başka uygulama yolları da vardır)

Sıkışmanın çıkış yolları:

• bir anlık görüntü serbest bırakın (bir tane olması durumunda ...)
• havuzu büyütün (atayabileceğiniz herhangi bir yedek varsa)
• havuzdaki başka bir dosya sistemini yok edin, ardından sıkı dosya sistemini büyütün
• dosyayı kesin, sonra kaldırın (gerçi bunu yapabilmek için çok sıkı bir sıkma yaptıktan sonra , ZFS Tartışmasındaki konuya bakın )
• dosyanın bağlantısını kaldırın. (Yukarıdaki ile aynı)

Birkaç yıl önce aynı tuzağa düştüm ve beni kurtarmak için serbest bırakabileceğim herhangi bir enstantanem yoktu. Bu sorunun derinlemesine tartışıldığı ZFS Discuss'teki konu başlığına bakın .

4.Z3G (rpool / root USED sütunu) şüpheli.

Her durumda, rpool / export / home / admin çok büyük (3.85 GB) büyük olasılıkla temel nedendir. İçeriğine bir göz atın ve orada gereksiz dosyaları kaldırın. Yönetici dosya sisteminde anlık görüntü olmadığından, bu durum hemen havuzda biraz yer açmalıdır.

Buna sahiptim ve neyin gerekli olduğunu anlamaya çalışmak için biraz zaman harcadım. Benim çözüm dosyaları silmek için önce alanı sıfırlamak oldu.

Bazen çılgınca gidip diski çekirdek dosyalarla (bir sayı ile biten) dolduran bazı hatalı işlemler var, bu yüzden bir kopyasını tutmak için böyle bir şey içeren bir komut dosyası ürettim.

for file in core*[0-9]
do
    coreFile=${file%.[0-9]*}

    mv $file $coreFile
    if [[ $? == 0 ]]
    then
        chmod 644 $coreFile
    else
        truncate -s 0 $file # we can't just delete if disk is full so zero out first
        rm $file
    fi
done

Senaryomu çalıştırdığımda bir hata üretti:

mv: cannot rename core.200000 to core: No space left on device

ve dosyaları temizlemek işlevseldi.

Bunu test etmek için diski şu şekilde doldurdum:

for ((ii=0; ii<100000; ii++))
do
    mkfile 1m core.$ii
done