Secara massal menghapus direktori besar pada ZFS tanpa melintasi secara rekursif


9

Saya ingin menghapus direktori yang memiliki banyak data di dalamnya. Ini adalah array cadangan saya, yang merupakan sistem file ZFS , rentang linier, kumpulan tunggal yang disebut "san". San sudah terpasang di /san jadi saya ingin menghapus massal / san / thispc / tertentuFolder

$ du -h -d 1 certainFolder/
1.2T    certainFolder/

Daripada saya harus menunggu, rm -rf certainFolder/tidak bisakah saya menghancurkan pegangan ke direktori itu sehingga dapat ditimpa (bahkan dengan nama dir yang sama jika saya memilih untuk membuatnya kembali) ??

Jadi untuk misalnya tidak mengetahui banyak tentang zfs fs internal mgmnt secara khusus bagaimana memetakan direktori, tetapi jika saya menemukan bahwa peta mengatakan untuk misalnya, dan menghapus entri yang tepat untuk misalnya, direktori tidak akan lagi ditampilkan, dan ruang yang sebelumnya dimiliki oleh direktori harus dihapus dari semacam audit juga.

Apakah ada cara mudah untuk melakukan ini, bahkan jika pada ext3 fs, atau apakah sudah melakukan perintah hapus rekursif di tempat pertama, yaitu mencuri melalui dan mengedit jurnal?

Saya hanya berharap untuk melakukan sesuatu seperti di kill thisDirmana ia hanya menghapus beberapa jenis ID, dan poof direktori tidak lagi muncul ls -ladan data masih ada di drive jelas, tetapi ruang sekarang akan digunakan kembali ( ditimpa), karena ZFS memang keren?

Maksud saya, saya pikir zfs benar-benar keren, bagaimana kita bisa melakukannya? Idealnya? menggosok tangan bersama-sama :-)

Kasing penggunaan khusus saya (selain cintaku untuk zfs) adalah pengelolaan arsip cadangan saya. Dir cadangan ini didorong melalui freefilesync (PROG AWESOME) pada kotak Windows saya ke file-smb berbagi, tetapi juga memiliki direktori versi di mana file lama pergi. Saya menghapus direktori tingkat atas yang berada di cadangan utama, yang disalin ke versi - misalnya /san/version/someStuff, sebagai pembersihan dua bulanan dari rm -rf /san/version/someStuff/*terminal dempul, sekarang saya harus membuka terminal lain; tidak ingin melakukan itu setiap waktu, saya bosan sia-sia harus memonitor rm -rf.

Maksudku, mungkin aku harus mengatur perintah untuk hanya melepaskan pegangan, lalu mencetak ke std, itu mungkin bagus. Lebih realistis lagi , membuat ulang set data dalam beberapa detik zfs destroy san/version; zfs create -p -o compression=on san/versionsetelah pemikiran dari respons dari @Gilles.


FYI, saya menjalankan perintah ini untuk membuat dataset yang saya gunakan saat ini .. `zfs create dataset -p -o compression=on yourPoolName/BackupRootDir/hostNameYourPc/somesubdir
Brian Thomas

Harap terima jawaban jika seseorang memecahkan masalah yang dijelaskan dalam pertanyaan awal Anda. Masalah yang baru saja Anda tambahkan ke pertanyaan Anda terlihat sangat berbeda sehingga harus benar-benar ditanyakan dalam pertanyaan baru.
jlliagre

Jawaban:


12

Melacak blok yang dibebaskan tidak dapat dihindari dalam sistem file yang layak dan ZFS tidak terkecuali . Namun ada cara sederhana di bawah ZFS untuk memiliki penghapusan direktori hampir seketika dengan "menunda" pembersihan yang mendasarinya. Secara teknis sangat mirip dengan saran Gilles tetapi secara inheren dapat diandalkan tanpa memerlukan kode tambahan.

Jika Anda membuat snapshot dari sistem file Anda sebelum menghapus direktori, penghapusan direktori akan sangat cepat karena tidak ada yang perlu dieksplorasi / dibebaskan di bawahnya, semua masih dirujuk oleh snapshot. Anda kemudian dapat menghancurkan snapshot di latar belakang sehingga ruang akan secara bertahap pulih.

d=yourPoolName/BackupRootDir/hostNameYourPc/somesubdir
zfs snapshot ${d}@quickdelete && { 
    rm -rf /${d}/certainFolder
    zfs destroy ${d}@quickdelete & 
}

ok, saya tidak terbiasa dengan snapshot. itu mungkin bisa membantu saya. saya telah menghapus / bergerak sepanjang hari. Saya membuat kumpulan data tidak hanya untuk direktori cadangan utama, tetapi direktori tingkat atas di dalamnya, masing-masing dimulai dengan nama host, dan beberapa tingkat teratas .., jadi saya memiliki sedikit fleksibilitas di sana untuk hanya menghancurkan dan membuat ulang kumpulan, tetapi tidak sempurna , karena saya tidak selalu ingin menghapus seluruh dir pool ini, saya harus membuat lebih banyak lagi, dan itu banyak pembuatan dataset, jadi saya suka saran Anda karena alasan itu!
Brian Thomas

4
Jika tersedia, feature@async_destroymungkin juga membantu mempercepat ini (dari perspektif pengguna atau administrator) jika diaktifkan; lihat zpool get all $pool. Perhatikan bahwa setidaknya yang terakhir saya perhatikan, jika ada penghancuran yang tertunda sedang berlangsung pada impor pool , maka destr tersebut menjadi sinkron dan impor pool tidak akan selesai sampai penghancuran selesai. Hati-hati jika Anda perlu reboot!
CVn

Saya memiliki pelanggan dengan freenas yang kehilangan koneksi SMB pada penghapusan besar. Setelah mengaktifkan snapshot berkala (dan penghapusan otomatis) masalah "menghilang". pembebasan ruang membutuhkan waktu lebih lama di latar belakang, tetapi SMB-Share tetap dapat diakses setiap saat.
Martin Seitl

6

Apa yang Anda minta tidak mungkin. Atau, lebih tepatnya, ada biaya yang harus dibayar saat menghapus direktori dan file-nya; jika Anda tidak membayarnya pada saat penghapusan, Anda harus membayarnya di tempat lain.

Anda tidak hanya menghapus direktori - itu hampir instan. Anda menghapus direktori dan semua file di dalamnya dan juga secara rekursif juga menghapus semua subdirektori. Menghapus file berarti mengurangi jumlah tautannya, dan kemudian menandai sumber dayanya (blok digunakan untuk konten file dan metadata file, dan inode jika sistem file menggunakan tabel inode) gratis jika jumlah tautan mencapai 0 dan file tidak Buka. Ini adalah operasi yang harus dilakukan untuk setiap file di pohon direktori, sehingga waktu yang dibutuhkan setidaknya sebanding dengan jumlah file.

Anda dapat menunda biaya menandai sumber daya sebagai gratis. Sebagai contoh, ada filesystem yang dikumpulkan sampah, di mana Anda dapat menghapus direktori tanpa menghapus file yang dikandungnya. Jalankan pengumpul sampah akan mendeteksi file yang tidak dapat dijangkau melalui struktur direktori dan menandainya sebagai gratis. Melakukan rm -f directory; garbage-collectpada filesystem yang dikumpulkan sampah melakukan hal yang samarm -rfpada sistem file tradisional, dengan pemicu yang berbeda. Ada beberapa filesystem yang dikumpulkan sampah karena GC adalah kompleksitas tambahan yang jarang dibutuhkan. Waktu GC dapat datang kapan saja, ketika filesystem membutuhkan beberapa blok gratis dan tidak menemukannya, sehingga kinerja suatu operasi akan tergantung pada sejarah masa lalu, bukan hanya pada operasi, yang biasanya tidak diinginkan. Anda harus menjalankan pengumpul sampah hanya untuk mendapatkan jumlah ruang kosong yang sebenarnya.

Jika Anda ingin mensimulasikan perilaku GC pada sistem file normal, Anda bisa melakukannya:

mv directory .DELETING; rm -rf .DELETING &

(Saya menghilangkan banyak detail penting seperti pengecekan error, seperti ketahanan terhadap kehilangan daya, dll.) Nama direktori menjadi tidak ada segera; ruang reklamasi semakin progresif.

Pendekatan yang berbeda untuk menghindari membayar biaya selama penghapusan tanpa GC adalah dengan membayarnya selama alokasi. Tandai pohon direktori sebagai dihapus, dan pergi melalui direktori yang dihapus ketika mengalokasikan blok. Itu akan sulit untuk didamaikan dengan tautan keras, tetapi pada sistem berkas tanpa tautan keras, hal itu dapat dilakukan dengan O (1) peningkatan biaya dalam alokasi. Namun itu akan membuat operasi yang sangat umum (membuat atau memperbesar file) lebih mahal, dengan satu-satunya manfaat menjadi operasi yang relatif jarang (menghapus pohon direktori besar) lebih murah.

Anda bisa menghapus sebagian besar pohon direktori jika pohon itu disimpan sebagai kumpulan bloknya sendiri. (Catatan: Saya menggunakan kata "kumpulan" dalam arti yang berbeda dari "kumpulan penyimpanan" ZFS. Saya tidak tahu apa istilah yang tepat.) Itu bisa sangat cepat. Tapi apa yang Anda lakukan dengan ruang kosong? Jika Anda menetapkan ulang ke kumpulan lain, itu memiliki biaya, meskipun jauh lebih sedikit daripada menghapus file satu per satu. Jika Anda meninggalkan ruang sebagai ruang cadangan yang tidak digunakan, Anda tidak dapat segera mengklaimnya kembali. Memiliki kumpulan individu untuk pohon direktori berarti menambah biaya untuk menambah atau mengurangi ukuran kumpulan itu (baik dengan cepat atau eksplisit). Membuat pohon kumpulan penyimpanannya sendiri juga meningkatkan biaya memindahkan file masuk dan keluar dari pohon.


Ok jawaban yang bagus! Paruh pertama benar-benar memuaskan pada sistem normal. ZFS memiliki beberapa trik di lengannya, misalnya tidak perlu memformatnya, jadi jika saya menghancurkan kolam, yang saya pikir saya akan lakukan di lain waktu hanya membuat kolam (jamak) seperti yang seharusnya, maka ti menghilang radar langsung, dan ruang itu segera tersedia. Saya kira saya mencoba untuk menciptakan kembali pada zfs, pada direktori di dalam kolam, dan saya pikir karena itu bukan kolam itu sendiri, sifatnya menjadi lebih standar, dan metode yang Anda sebutkan tampaknya berlaku dalam kasus itu. menarik.
Brian Thomas

Saya pikir di situlah saya membuat kesalahan saya, saya membaca sebuah artikel tadi malam, saya tidak tahu apakah saya dapat menemukannya, yang menunjukkan bahwa kolam harus digunakan seperti dirs terbatas pada ~ 18.446.744 Triliun kolam maks pada FS. jika saya membuat direktori cadangan teratas saya sebagai kumpulan masing-masing, ketika cadangan pergi untuk menulis kepada mereka, dir akan sudah dalam kebijaksanaan, yang merupakan kolam mudah dihapus .. Jika kolam tidak ada cadangan hanya akan membuat dir, dan kolam tidak akan terlihat di zfs list. Sampai saat itu, berharap orang lain memiliki beberapa masukan tentang cara menghapus massal pada ZFS di sebuah subdir pool. :-)
Brian Thomas

Juga, ketika membaca respons pertama Anda, pikiran pertama saya adalah; "BENAR!", "Biayanya"! Itulah yang saya sentuh ketika saya berbicara tentang menghapus entri jurnal. jadi seperti yang saya duga. menisik! Namun, Anda berada di jalur yang benar. Mari kita datang dengan sesuatu di sini, sehingga kita bisa mendapatkan skrip bersama yang akan melakukan ini mungkin ... sebuah pemikiran :-)
Brian Thomas

Brian, berhati-hatilah jangan sampai membingungkan zpools dan dataset. Meskipun memang tidak ada batasan kode keras yang dapat dijangkau pada jumlah zpool yang dapat Anda buat, Anda akan dengan cepat dibatasi oleh jumlah perangkat yang mendasarinya (misalnya partisi) yang tersedia di mesin Anda. Selain itu, memiliki kumpulan yang didedikasikan untuk direktori tunggal akan mengalahkan beberapa fitur zfs yang berharga dan membuat operasi perpindahan jauh lebih lambat.
jlliagre

pada komentar ini Anda buat di sini @Gilles "Tapi apa yang Anda lakukan dengan ruang kosong? Jika Anda menetapkan kembali ke kolam lain, itu ada biaya, meskipun jauh lebih sedikit daripada menghapus file secara individual" saya tidak yakin, tapi saya rasa tidak ada adalah penalti yang menciptakan kumpulan baru, saya pikir saya berurusan dengannya saat menulis saja. tidak perlu dipartisi untuk alasan yang sama .. saya percaya ini adalah mekanisme yang sama ..
Brian Thomas

1

Jika harus cepat, saya membuat direktori sementara baru, mvdirektori di bawahnya dan kemudian secara temporer menghapus sementara:

t=`mktemp -d`
mv certainFolder $t/
rm -rf $t &

Apakah & menghapus kesalahan penanganan, atau squash?
Brian Thomas

1
Ini tidak jauh berbeda dari saran Gilles dan memiliki kelemahan yang sama. Jika OS di-boot ulang atau rmperintah tidak selesai karena alasan lain, direktori phantom dibiarkan tidak terhapus.
jlliagre

ahh benar, tetapi & itu baru bagi saya, itu bagian dari teka-teki ... saya ingin menyingkirkan pegangan. Namun ya benar, jangan mau sampah itu jika ada masalah ..
Brian Thomas

@BrianThomas &hanya latar belakang proses, sehingga Anda dapat terus melakukan hal-hal lain dalam shell yang sama saat penghapusan sedang berjalan (dikenakan hukuman kinerja yang relevan).
CVn
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.