Tidak ada ruang pada perangkat saat menghapus file di bawah OpenSolaris

Ketika mencoba untuk me-mount share NFS (diekspor dari server OpenIndiana ) pada kotak klien, server OI jatuh. Saya mendapatkan layar hitam kematian, yang tampak seperti tempat sampah, kemudian sistemnya dinyalakan kembali. Tidak pernah muncul kembali dan saya mendapatkan pesan kesalahan berikut setelah saya menghentikan boot:

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

Saya tidak punya apa-apa lagi di boot drive selain dari OS jadi ... Saya tidak yakin apa yang bisa mengisi drive? Mungkin semacam file log? Sepertinya saya tidak bisa menghapus apa pun. Ini memberi saya kesalahan tanpa spasi ketika saya mencoba dan menghapus apa pun:

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

Saya bisa masuk ke "Mode Pemeliharaan" tetapi bukan prompt pengguna standar.

Output dari dfadalah:

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

Output dari mountadalah:

/ 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 

Output dari 'zfs list -t all' adalah:

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    -

Ok, itu aneh ... tidak cukup ruang untuk menghapus file!

Ini ternyata menjadi masalah yang relatif umum dengan ZFS, meskipun berpotensi muncul pada sistem file yang memiliki snapshot .

Penjelasannya adalah bahwa file yang Anda coba hapus masih ada pada snapshot. Jadi ketika Anda menghapusnya, konten tetap ada (hanya dalam snapshot); dan sistem juga harus menulis informasi bahwa snapshot memiliki file tetapi keadaan saat ini tidak. Tidak ada ruang tersisa untuk informasi ekstra itu.

Perbaikan jangka pendek adalah menemukan file yang telah dibuat setelah snapshot terbaru dan menghapusnya. Kemungkinan lain adalah menemukan file yang ditambahkan setelah snapshot terbaru dan memotongnya dengan ukuran seperti pada saat snapshot terbaru. Jika disk Anda penuh karena ada sesuatu yang telah melakukan spam pada log Anda, coba pangkas file log terbesar.

Perbaikan yang lebih umum berlaku adalah untuk menghapus beberapa foto. Anda dapat membuat daftar snapshot dengan zfs list -t snapshot. Tampaknya tidak ada cara mudah untuk memperkirakan berapa banyak ruang yang akan diperoleh kembali jika Anda menghancurkan snapshot tertentu, karena data yang disimpannya ternyata dibutuhkan oleh snapshot lain dan akan tetap hidup jika Anda menghancurkan snapshot itu. Jadi buat cadangan data Anda ke disk lain jika perlu, identifikasi satu atau lebih foto yang tidak lagi Anda perlukan, dan jalankan zfs destroy name/of/snap@shot.

Ada diskusi panjang tentang masalah ini di utas forum OpenSolaris ini .

Itu adalah masalah yang terkenal dengan sistem file copy-on-write: Untuk menghapus file, filesystem pertama-tama harus mengalokasikan blok dan memperbaiki status baru sebelum mampu melepaskan kekayaan ruang yang terkandung dalam file yang baru saja dihapus.

(Ini bukan masalah filesystem dengan snapshot, karena ada cara lain untuk mengimplementasikannya daripada hanya copy-on-write)

Cara keluar dari pemerasan:

• lepaskan foto (jika ada satu ...)
• menumbuhkan kolam (kalau-kalau ada sisa yang dapat Anda tetapkan untuk itu)
• hancurkan filesystem lain di pool, lalu kembangkan filesystem yang ketat
• pangkas file, lalu hapus (meskipun begitu saya terlalu menekan untuk dapat melakukan hal itu, lihat utas di ZFS Diskusikan )
• batalkan tautan file. (sama seperti di atas)

Saya telah mengalami jebakan yang sama beberapa tahun yang lalu, dan tidak memiliki snapshot yang bisa saya lepaskan untuk membebaskan saya. Lihat utas di ZFS Diskusikan di mana masalah ini telah dibahas secara mendalam.

4.Z3G (kolom rpool / root USED) meragukan.

Bagaimanapun, rpool / ekspor / rumah / admin terlalu besar (3,85 GB) kemungkinan merupakan penyebab utama. Lihat isinya dan hapus file yang tidak perlu di sana. Karena sistem file admin tidak memiliki snapshot, ini harus segera membebaskan beberapa ruang di kolam.

Saya memilikinya dan menghabiskan beberapa waktu untuk mencari tahu apa yang dibutuhkan. Solusi saya adalah mengecilkan ruang file sebelum mencoba menghapusnya.

Kami memiliki beberapa proses nakal yang kadang-kadang menjadi gila dan mengisi disk dengan file inti (diakhiri dengan angka) jadi saya membuat skrip yang berisi sesuatu seperti ini untuk menyimpan satu salinan.

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

Ketika saya menjalankan skrip saya, itu menghasilkan satu kesalahan:

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

dan fungsional membersihkan file.

Untuk menguji ini saya mengisi disk dengan:

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