CapordiaKlasifikasikan file berdasarkan peran dan pemilik
Pisahkan input yang diperlukan untuk pemrosesan, file perantara, dan hasil yang harus disimpan. Input dapat berasal dari repositori atau arsip; file sementara dapat dibuat ulang; hasil memerlukan tujuan yang permanen. Tambahkan keluarga keempat: status yang memungkinkan dimulainya kembali suatu eksekusi. Titik pemulihan tidak sama dengan input asli maupun hasil akhir.
Untuk setiap keluarga, tentukan pemilik dan aturan penyimpanan. Siapa yang dapat mengizinkan penghapusan cache? Siapa yang mengonfirmasi bahwa suatu hasil dapat digunakan? File apa yang hilang jika pekerjaan berhenti? Catat jawaban ini dalam lembar proyek, beserta tujuan yang dipilih. Katalog menjelaskan GPU; kapasitas disk, kuota, dan ketentuan penyimpanan harus diverifikasi untuk cakupan yang benar-benar disediakan.
Hitung puncak penyimpanan, bukan hanya arsip awal
Perkirakan volume maksimum selama eksekusi. Gambar yang didekompresi, salinan kerja, atau versi berturut-turut dapat menempati lebih banyak ruang daripada arsip yang diterima. Perhitungan yang tepat menjumlahkan elemen yang ada secara bersamaan. Jangan menjumlahkan fase yang saling eksklusif, dan jangan lupa bahwa ekspor dapat disiapkan sementara pemrosesan masih menghasilkan output.
Contoh fiktif, dengan GB desimal: sebuah tim menyimpan arsip 180 GB selama persiapan 420 GB file yang didekompresi. Tim tersebut merencanakan 120 GB file sementara, 60 GB output, dan tiga titik pemulihan masing-masing 24 GB. Jika semuanya ada bersamaan, puncaknya adalah 180 + 420 + 120 + 60 + 72 = 852 GB. Margin internal yang dipilih sebesar 20% menaikkan kebutuhan menjadi 1.022,4 GB. Asumsi proyek ini bukan kapasitas yang termasuk dalam suatu penawaran.
| Kategori | Perhitungan | Volume |
|---|---|---|
| Arsip input yang disimpan | 1 × 180 GB | 180 GB |
| Input yang didekompresi | 1 × 420 GB | 420 GB |
| File sementara pada puncak | Asumsi kerja | 120 GB |
| Output dalam persiapan | Asumsi kerja | 60 GB |
| Titik pemulihan | 3 × 24 GB | 72 GB |
| Total sebelum margin | Jumlah kelima kategori | 852 GB |
Verifikasi lokasi yang dapat digunakan sebelum menjalankan rangkaian
Catat ruang yang tersedia pada sistem file yang benar-benar akan menampung proyek, lalu verifikasi izin tulis dan ukuran file maksimum yang diharapkan. Dengan banyak file kecil, periksa juga ketersediaan inode jika sistem menggunakannya. GNU df membedakan blok yang tersedia dan inode: indikator kapasitas dalam byte tidak merangkum semua penyebab kegagalan pembuatan file.
Jika Linux dan alat GNU tersedia, perintah di bawah ini memungkinkan pencatatan hanya-baca pada direktori saat ini. Catat waktu dan jalur yang diperiksa. Pencatatan ini tidak mengukur kecepatan penyimpanan dan bukan merupakan reservasi ruang; kuota tambahan juga dapat berlaku. Tanyakan cakupannya sebelum menganggap persiapan selesai.
df -B1 --output=source,size,used,avail,pcent,target .
df -i .Atur nama dan status yang dapat dibaca ulang oleh tim
Beri nama output yang mengidentifikasi batch dan versi pemrosesan. Pisahkan file yang sedang diproses dari hasil yang telah diverifikasi; folder pengiriman tidak boleh mencampur hasil yang diterima dengan salinan sebagian yang memiliki nama sama. Sebuah register dapat menghubungkan identitas batch, versi kode, lokasi, dan status validasi tanpa memuat datanya sendiri.
Untuk komputasi yang panjang, tentukan titik pemulihan yang dapat dihasilkan aplikasi dan verifikasi pembacaannya. Simpan parameter yang diperlukan bersama status yang disimpan. Jika suatu proses masih menulis ke file selama penyalinannya, jangan anggap salinan itu sebagai status yang konsisten tanpa mekanisme yang disediakan aplikasi. Utamakan pencadangan yang telah selesai dan teridentifikasi, lalu sampaikan namanya kepada orang yang menyiapkan kelanjutannya.
Mengontrol transfer dan penggunaan hasil secara terpisah
Transfer hasil pertama ke tujuan akhirnya sebelum hari terakhir. Bandingkan daftar file yang diharapkan beserta ukurannya, lalu bandingkan checksum jika prosedur Anda mengaturnya. Alat SHA-2 dari GNU menghitung dan memverifikasi checksum file. Sebuah manifes harus sesuai dengan file yang sudah final dan disimpan dengan asal-usul yang diketahui; manifes tidak dengan sendirinya memvalidasi kualitas bisnis konten.
Setelah kontrol integritas, buka hasil dari tujuannya dengan aplikasi yang akan menggunakannya. Periksa jumlah item, format, dan dependensi eksternal. Arsip yang tersalin dengan sempurna bisa saja sejak awal berisi file yang hilang. Oleh karena itu, penanggung jawab penerimaan harus mengonfirmasi dua hal yang berbeda: salinan sesuai dengan paket yang diharapkan, dan paket tersebut memang berguna untuk tahap berikutnya.
sha256sum --check MANIFEST.sha256Memutuskan penyimpanan sebelum akhir periode
Dalam contoh 852 GB, menghapus arsip kerja setelah konfirmasi salinan independen akan menurunkan kebutuhan menjadi 672 GB sebelum margin. Penghematan ini hanya berlaku jika pemulihan arsip tetap mungkin dilakukan dan tidak ada tahap berikutnya yang membutuhkannya di tempat. Keputusan berada di tangan pemilik data; keputusan ini tidak boleh diimprovisasi oleh orang yang menemukan kekurangan ruang.
Kesalahan yang sering terjadi adalah menyimpan semua versi tanpa batas, menunggu hingga akhir untuk menguji izin tujuan, dan menganggap salinan yang berada di lokasi yang sama sebagai solusi keluaran. Tetapkan daftar yang harus disimpan, penanggung jawab ekspor, dan kontrol akhirnya. Baik untuk 3, 7, atau 30 hari, durasi komputasi dan durasi pengambilan merupakan bagian dari perencanaan yang sama.
Pertanyaan untuk memutuskan
Apakah semua file sementara harus disimpan?
Tidak harus. Identifikasi file yang dapat dibangun ulang oleh aplikasi, lalu bandingkan volumenya dengan biaya dan waktu pembangunan ulang tersebut. Simpan elemen yang diperlukan untuk pemulihan yang tervalidasi. Penghapusan file yang masih digunakan atau state yang sangat penting harus dikecualikan dari aturan pembersihan.
Apakah checksum yang benar cukup untuk menerima ekspor?
Checksum memverifikasi kesesuaian dengan checksum yang diharapkan. Masih perlu dipastikan bahwa manifes mencakup file yang benar dan bahwa hasil dapat dibuka beserta dependensinya. Jadi, penerimaan menggabungkan integritas paket dan kontrol fungsional dari tujuan.
Apakah memori GPU dapat menggantikan ruang disk yang kurang?
Tidak: VRAM menampung data yang digunakan oleh komputasi di kartu. VRAM tidak menggantikan tujuan file maupun penyimpanan setelah periode sewa. Jelaskan secara terpisah memori GPU, memori sistem, dan penyimpanan dalam berkas Anda.