Dosyaları role ve sahibe göre sınıflandırın
İşleme için gerekli girdileri, ara dosyaları ve saklanacak sonuçları ayırın. Girdiler bir depodan veya arşivden gelebilir; geçici dosyalar yeniden oluşturulabilir; sonuçlar ise kalıcı bir hedef gerektirir. Dördüncü bir aile ekleyin: bir yürütmenin devam etmesini sağlayan durumlar. Bir devam noktası ne orijinal girdilerle ne de nihai sonuçla karıştırılır.
Her aile için bir sahip ve bir saklama kuralı belirleyin. Bir önbelleğin silinmesine kim izin verebilir? Bir sonucun kullanılabilir olduğunu kim onaylar? İş durursa hangi dosya eksik kalır? Bu yanıtları, seçilen hedefle birlikte proje dosyasına yazın. Katalog GPU'yu tanımlar; disk kapasiteleri, kotalar ve saklama koşulları fiilen sağlanan kapsam için doğrulanmalıdır.
Yalnızca başlangıç arşivini değil, depolama zirvesini hesaplayın
Yürütme sırasındaki azami hacmi değerlendirin. Açılmış görüntüler, çalışma kopyaları veya art arda gelen sürümler, alınan arşivden daha fazla yer kaplayabilir. Doğru hesaplama, aynı anda birlikte bulunan öğeleri toplar. Ne birbirini dışlayan aşamalar toplanmalı ne de işlem hâlâ çıktı üretirken bir dışa aktarmanın hazırlanabileceği unutulmalıdır.
Ondalık GB ile kurgusal bir örnek: bir ekip, 420 GB açılmış dosyanın hazırlanması sırasında 180 GB'lık bir arşivi saklar. 120 GB geçici dosya, 60 GB çıktı ve 24 GB'lık üç devam noktası öngörür. Her şey birlikte bulunursa zirve 180 + 420 + 120 + 60 + 72 = 852 GB olur. %20 olarak seçilen bir iç marj, gereksinimi 1.022,4 GB'a çıkarır. Bu proje varsayımı, bir teklife dahil edilen bir kapasite değildir.
| Kategori | Hesaplama | Hacim |
|---|---|---|
| Saklanan giriş arşivi | 1 × 180 GB | 180 GB |
| Açılmış girdiler | 1 × 420 GB | 420 GB |
| Zirvedeki geçici dosyalar | Çalışma varsayımı | 120 GB |
| Hazırlanan çıktılar | Çalışma varsayımı | 60 GB |
| Devam noktaları | 3 × 24 GB | 72 GB |
| Marj öncesi toplam | Beş kategorinin toplamı | 852 GB |
Bir seriyi başlatmadan önce kullanılabilir konumu doğrulayın
Projeyi gerçekten barındıracak dosya sistemindeki kullanılabilir alanı tespit edin, ardından yazma izinlerini ve dosyaların beklenen azami boyutunu doğrulayın. Çok sayıda küçük dosya söz konusuysa, sistem bunları kullanıyorsa inode kullanılabilirliğine de bakın. GNU df, kullanılabilir bloklar ile inode'ları birbirinden ayırır: bayt cinsinden bir kapasite göstergesi, bir dosya oluşturma hatasının tüm nedenlerini özetlemez.
Linux ve GNU araçları mevcutsa, aşağıdaki komutlar geçerli dizin hakkında salt okunur bir tespit yapmanızı sağlar. İncelenen saati ve yolu not edin. Bu tespitler depolama hızını ölçmez ve bir alan rezervasyonu oluşturmaz; ek kotalar da uygulanabilir. Hazırlığı tamamlanmış saymadan önce bunların kapsamını sorun.
df -B1 --output=source,size,used,avail,pcent,target .
df -i .Ekibin yeniden okuyabileceği adlar ve durumlar düzenleyin
Çıktılara, partiyi ve işlem sürümünü tanımlayan bir ad verin. Devam eden dosyaları kontrol edilmiş teslimatlardan ayırın; teslimat klasörü, kabul edilmiş bir sonuçla aynı adı taşıyan kısmi bir kopyayı karıştırmamalıdır. Bir kayıt defteri, verilerin kendisini içermeden parti kimliğini, kod sürümünü, konumu ve doğrulama durumunu ilişkilendirebilir.
Uzun hesaplamalar için uygulamanın üretebildiği devam noktalarını tanımlayın ve okunabilirliklerini doğrulayın. Gerekli parametreleri kaydedilmiş durumla birlikte saklayın. Bir süreç, kopyalanması sırasında hâlâ bir dosyaya yazıyorsa, uygulamanın öngördüğü bir mekanizma olmadan bu kopyayı tutarlı bir durum saymayın. Tamamlanmış ve tanımlanmış bir yedeği tercih edin, ardından adını devamını hazırlayan kişiye iletin.
Aktarımı ve sonucun kullanımını ayrı ayrı kontrol edin
İlk sonucu son günden önce nihai hedefine aktarın. Beklenen dosyaların listesini ve boyutlarını, ardından prosedürünüz öngörüyorsa sağlama toplamlarını karşılaştırın. GNU'nun SHA-2 araçları dosya sağlama toplamlarını hesaplar ve doğrular. Bir manifest, tamamlanmış dosyalarla eşleşmeli ve bilinen bir kaynakla birlikte saklanmalıdır; tek başına içeriğin iş kalitesini doğrulamaz.
Bütünlük kontrolünden sonra sonucu hedefinden, onu kullanacak uygulamayla açın. Öğe sayısını, biçimi ve harici bağımlılıkları doğrulayın. Kusursuz kopyalanmış bir arşiv bile baştan eksik bir dosya içerebilir. Bu nedenle teslim alma sorumlusu iki ayrı şeyi onaylamalıdır: kopya beklenen pakete karşılık geliyor ve bu paket gerçekten bir sonraki adıma hizmet ediyor.
sha256sum --check MANIFEST.sha256Dönem bitmeden saklama kararı verme
852 GB örneğinde, bağımsız bir kopyanın doğrulanmasından sonra çalışma arşivini silmek, marj öncesi ihtiyacı 672 GB'a düşürürdü. Bu kazanım yalnızca arşivin geri yüklenmesi mümkün kaldığı ve sonraki hiçbir adım bunu yerinde gerektirmediği sürece geçerlidir. Karar veri sahibine aittir; yer sıkıntısı fark eden kişi tarafından doğaçlama alınmamalıdır.
Sık yapılan hatalar; tüm sürümleri sınırsız saklamak, hedef izinlerini test etmek için sonu beklemek ve aynı konumdaki bir kopyayı çıkış çözümü saymaktır. Saklanacak listeyi, dışa aktarma sorumlusunu ve son kontrolünü belirleyin. 3, 7 veya 30 gün içinde hesaplama süresi ile geri alma süresi aynı planın parçasıdır.
Karar vermek için sorular
Tüm geçici dosyalar saklanmalı mı?
Mutlaka değil. Uygulamanın yeniden oluşturabileceği öğeleri belirleyin, ardından bunların hacmini bu yeniden oluşturmanın maliyeti ve süresiyle karşılaştırın. Doğrulanmış bir devam için gerekli öğeleri saklayın. Hâlâ kullanılan bir dosyanın veya vazgeçilmez bir durumun silinmesi, temizleme kuralının dışında tutulmalıdır.
Doğru bir parmak izi bir dışa aktarımı kabul etmek için yeterli mi?
Beklenen parmak iziyle eşleşip eşleşmediğini doğrular. Manifestonun doğru dosyaları kapsadığını ve sonucun bağımlılıklarıyla birlikte açıldığını doğrulamak kalır. Kabul, bu nedenle paket bütünlüğünü ve hedefteki işlevsel kontrolü birleştirir.
GPU belleği, eksik disk alanının yerini alabilir mi?
Hayır: VRAM, kart üzerindeki hesaplamada kullanılan verileri barındırır. Dosyaların hedef aldığı yeri ya da kiralama süresinden sonra saklanmasını yerine koymaz. Dizinizde GPU belleğini, sistem belleğini ve depolamayı ayrı ayrı tanımlayın.