स्टोरेज

Arkvory हर प्रकाशित फ़ाइल को एक बार, अपरिवर्तित, सर्वर की स्थानीय डिस्क पर एक स्टोरेज डायरेक्टरी में रखता है। यह पेज बताता है कि डिस्क स्थान क्या लेता है, कोटा और प्रतिधारण नीतियों से इसे कैसे सीमित करें, हटाई गई फ़ाइलें डिस्क से कैसे जाती हैं, और डिस्क भर जाने पर क्या करें।

सामग्री कहाँ रहती है

स्टोरेज डायरेक्टरी ARKVORY_DATA_DIR से सेट होती है। इंस्टॉलर ये स्थान इस्तेमाल करते हैं:

इंस्टॉलेशन	स्टोरेज
Windows	C:\ProgramData\ProAnima\Arkvory में data\
Linux	/opt/proanima-arkvory में data/
Docker Compose	Docker वॉल्यूम proanima-arkvory_storage

इसके भीतर, blobs/ तैयार फ़ाइलें रखता है, staging/ और parts/ प्रगतिरत अपलोड रखते हैं, और storage-id फ़ाइल डायरेक्टरी को डेटाबेस से जोड़ती है। कैटलॉग, सभी नामों, लेबलों, संस्करणों और अनुमतियों के साथ, PostgreSQL में है। फ़ाइलें और डेटाबेस एक साथ रहते हैं।

• ऐसा स्थानीय फ़ाइल सिस्टम इस्तेमाल करें जो हार्ड लिंक का समर्थन करता हो। स्टोरेज के लिए नेटवर्क शेयर इस्तेमाल न करें।
• डायरेक्टरी में हाथ से फ़ाइलें न जोड़ें, न बदलें और न हटाएँ। Arkvory खुद फ़ाइलें हटाता है, जैसा नीचे बताया गया है।
• प्रकाशित फ़ाइल कभी नहीं बदली जाती। नई सामग्री नई ID वाली नई फ़ाइल होती है।

डिस्क की योजना बनाएँ

निम्नलिखित स्टोरेज वॉल्यूम पर डिस्क स्थान लेते हैं:

क्या	टिप्पणियाँ
प्रकाशित फ़ाइलें	आपके रखे सभी संस्करण
प्रगतिरत अपलोड	भाग और स्टेजिंग फ़ाइलें, जब तक अपलोड समाप्त न हो
भागों में तैयार अपलोड की फ़ाइलें	अस्थायी भाग तैयार फ़ाइल के पास तब तक रहते हैं जब तक कोई भौतिक क्लीनअप पास उन्हें हटा न दे। भौतिक क्लीनअप देखें
हटाई गई फ़ाइलें	वे डिस्क पर तब तक रहती हैं जब तक छूट अवधि समाप्त न हो और कोई क्लीनअप पास उन्हें हटा न दे
मिरर प्रतियाँ	जब तक मिरर कोई फ़ाइल कॉपी करता है, mirror-staging में एक भाग। मिरर देखें

स्टोरेज के अलावा, अगर हो सके तो PostgreSQL डेटाबेस, लॉग और बैकअप स्टोरेज (vault) की योजना अलग वॉल्यूम पर बनाएँ। बैकअप देखें।

Arkvory स्टोरेज वॉल्यूम पर मुक्त स्थान का एक रिज़र्व रखता है। डिफ़ॉल्ट रूप से यह 1 GiB (ARKVORY_STORAGE_RESERVE_BYTES) है। जो अपलोड रिज़र्व इस्तेमाल कर लेता, उसे HTTP 507 और कारण storage_full के साथ अस्वीकार कर दिया जाता है। डाउनलोड काम करते रहते हैं। नए डेटा के लिए जगह न होने पर GET /health/ready writable: false दिखाता है।

दो सीमाएँ डिस्क से स्वतंत्र रूप से काम करती हैं:

• ARKVORY_CAPACITY_BYTES इंस्टॉलेशन की सभी आरक्षित सामग्री को सीमित करता है। डिफ़ॉल्ट 10 TiB है। यह एक तार्किक सीमा है, डिस्क की जाँच नहीं। इस तक पहुँचने पर, अपलोड HTTP 507 और कारण catalog_limit के साथ विफल हो जाते हैं।
• ARKVORY_MAX_OBJECT_BYTES एक फ़ाइल का आकार सीमित करता है।

एनवायरनमेंट वेरिएबल देखें। Arkvory के पास स्टोरेज या डेटाबेस के मुक्त स्थान के लिए कोई मेट्रिक नहीं है। वॉल्यूम पर अपने ऑपरेटिंग सिस्टम उपकरणों या node exporter से नज़र रखें।

स्टोरेज कौन प्रबंधित कर सकता है

स्टोरेज सेटिंग्स सामान्य पढ़ने और लिखने के अधिकारों का हिस्सा नहीं हैं। सेवा कुंजी को रिपॉज़िटरी पर स्पष्ट कार्रवाइयाँ चाहिए:

कार्रवाई	अनुमति देता है
storage.read	नीति, उपयोग और क्लीनअप सेटिंग्स देखें
storage.manage	नीति, कोटा और क्लीनअप सेटिंग्स बदलें, और क्लीनअप बैच का अनुरोध करें
artifact.delete	विलोपन का पूर्वावलोकन करें, आर्टिफ़ैक्ट हटाएँ, और स्वचालित प्रतिधारण नीति चालू करें
diagnostics.read	स्टोरेज इवेंट पढ़ें

पासवर्ड वाले खातों और पुनर्प्राप्ति कुंजी के पास खुद से ये अधिकार नहीं होते। कंसोल में स्टोरेज प्रबंधित करने के लिए:

1. रिपॉज़िटरी के लिए ऐसी नीति वाला सेवा खाता बनाएँ जिसमें चारों कार्रवाइयाँ शामिल हों। खाते और एक्सेस देखें।
2. उसके लिए एक कुंजी जारी करें और सक्रिय करें।
3. कंसोल में सेवा या ऑटोमेशन कुंजी से कनेक्ट करें खोलें, कुंजी चिपकाएँ और कनेक्ट करें चुनें।
4. रिपॉज़िटरी खोलें, और रिपॉज़िटरी के कार्ड पर स्टोरेज और क्लीनअप चुनें।

कैटलॉग के ऊपर पैनल स्टोरेज और स्वचालित क्लीनअप दिखाई देता है। अधिकारों के बिना, पैनल छिपा रहता है।

चालू प्रतिधारण नीति उस कुंजी से बँधी होती है जिसने उसे चालू किया। हर स्वचालित रन फिर जाँचता है कि यह कुंजी अब भी सक्रिय है, समाप्त नहीं हुई, और उसके पास अब भी storage.manage और artifact.delete हैं। अगर आप कुंजी निरस्त करते हैं या उसके अधिकार घटाते हैं, तो विलोपन रुक जाता है और इवेंट retention.failed दिखाई देता है। कुंजी रोटेट करने के बाद, नई कुंजी के साथ नीति दोबारा सहेजें।

कोटा और चेतावनी थ्रेसहोल्ड

रिपॉज़िटरी का एक कोटा हो सकता है। कोटा के बिना, केवल वैश्विक सीमा लागू होती है।

सेटिंग	कंसोल फ़ील्ड	अर्थ	डिफ़ॉल्ट
कोटा	कोटा, GiB (खाली = रिपॉज़िटरी की कोई सीमा नहीं)	रिपॉज़िटरी जितना अधिकतम स्थान इस्तेमाल कर सकती है। API सटीक बाइट लेता है, 1 से 9 007 199 254 740 991 तक, और बिना सीमा के लिए null	कोई सीमा नहीं
चेतावनी थ्रेसहोल्ड	चेतावनी सीमा (%)	कोटा का वह हिस्सा जो चेतावनी देता है। 1–98	80
क्रिटिकल थ्रेसहोल्ड	गंभीर सीमा (%)	वह हिस्सा जो त्रुटि देता है। 2–99, चेतावनी थ्रेसहोल्ड से अधिक	95

कोटा के विरुद्ध गिना जाने वाला उपयोग रिपॉज़िटरी की उन सभी फ़ाइलों का आकार है जो अब तक डिस्क से नहीं हटाई गईं: प्रकाशित फ़ाइलें, अधूरे अपलोड और वे हटाई गई फ़ाइलें जो क्लीनअप की प्रतीक्षा कर रही हैं। इसलिए हटाई गई फ़ाइल तब तक कोटा इस्तेमाल करती रहती है जब तक कोई क्लीनअप पास उसे हटा न दे।

• जाँच। अपलोड शुरू होने पर सर्वर कोटा जाँचता है। जो नया अपलोड कोटा पार कर लेता, वह HTTP 507 और कारण storage_quota के साथ विफल हो जाता है। उसी आइडेम्पोटेंसी कुंजी के साथ रीट्राई स्थान दोबारा आरक्षित नहीं करती।
• घटाना। आप कोटा मौजूदा उपयोग से कम सेट कर सकते हैं। चल रहे अपलोड पूरे हो सकते हैं। सीमा से अधिक नए अपलोड अस्वीकार कर दिए जाते हैं।
• कोई स्वचालित मुक्ति नहीं। कोटा कभी विलोपन नहीं कराता। प्रतिधारण कोटा पूरा करने के लिए अतिरिक्त बिल्ड नहीं हटाता।
• स्थितियाँ। स्थिति unlimited, normal, warning, critical या exceeded होती है। स्थिति का बदलाव एक बार स्टोरेज इवेंट के रूप में दर्ज होता है।
• निगरानी। सर्वर हर मिनट अधिकतम 20 रिपॉज़िटरी की स्थितियाँ फिर जाँचता है, तब भी जब स्वचालित विलोपन बंद हो।

ये संख्याएँ तार्किक आरक्षण हैं, मुक्त डिस्क स्थान नहीं। कोई रिपॉज़िटरी अपने कोटा के भीतर हो सकती है जबकि डिस्क भरी हुई हो, क्योंकि डिस्क पर स्टेजिंग फ़ाइलें और अन्य रिपॉज़िटरी भी रहती हैं।

प्रतिधारण नीति

प्रतिधारण नीति पुराने पंजीकृत UPack बिल्ड अपने-आप हटाती है और उनमें से अंतिम N रखती है। यह अन्य फ़ाइलें नहीं हटाती: पथ वाली सादी फ़ाइलें, कंटेनर इमेज, Git LFS ऑब्जेक्ट और npm पैकेज इसके बाहर हैं। नीति के बिना, कुछ भी अपने-आप नहीं हटता।

सेटिंग्स

सेटिंग	कंसोल फ़ील्ड	अर्थ	डिफ़ॉल्ट
चालू करें	स्वचालित क्लीनअप सक्षम करें	स्वचालित विलोपन चालू करता है	बंद
समूहन	पिछले N की गिनती का आधार	जो इकाई गिनी जाती है: पैकेज और चैनल, पैकेज या पूरी रिपॉज़िटरी	पैकेज और चैनल
अंतिम N	पिछले N बिल्ड (डिफ़ॉल्ट)	प्रति काउंटर कितने बिल्ड रखने हैं, 1–100 000	10
चैनल	चैनलों के लिए अलग मान: लेबल=N, हर पंक्ति में एक	किसी लेबल के लिए अपना N, label=N के रूप में, प्रति पंक्ति एक, अधिकतम 32। केवल समूहन पैकेज और चैनल के साथ इस्तेमाल होता है	test=10, staging=10, release=10
न्यूनतम आयु	हटाने से पहले न्यूनतम आयु (घंटे)	इससे छोटा बिल्ड रखा जाता है, घंटों में, 0–87 600	24
संरक्षित लेबल	सुरक्षित लेबल (अल्पविराम से अलग करें)	इनमें से किसी लेबल वाले बिल्ड कभी नहीं हटाए जाते, अधिकतम 32, अल्पविराम से अलग	bse, release
अंतराल	क्लीनअप अंतराल (मिनट)	रनों के बीच मिनट, 1–10 080	60

लेबल 1 से 64 अक्षर, अंक या _ . : - वर्णों का होता है।

बिल्ड कैसे चुने जाते हैं

1. सर्वर हर काउंटर के बिल्ड को प्रकाशन समय से क्रमबद्ध करता है, सबसे नया पहले। यह क्रम संस्करणों का SemVer क्रम नहीं है।
2. काउंटर समूहन पर निर्भर करता है। पैकेज और चैनल के साथ, एक बिल्ड प्रति पैकेज (group/name) उन सभी कॉन्फ़िगर किए गए चैनल लेबलों के लिए अलग-अलग गिना जाता है जो वह रखता है। बिना कॉन्फ़िगर किए लेबल वाला बिल्ड डिफ़ॉल्ट N के साथ पैकेज के एक साझा काउंटर में जाता है। पैकेज के साथ, हर पैकेज का एक काउंटर होता है। पूरी रिपॉज़िटरी के साथ, सभी बिल्ड एक काउंटर साझा करते हैं। पैकेज नाम केस की उपेक्षा करते हैं, लेबल नहीं।
3. कोई बिल्ड तब रहता है जब वह उन किसी भी काउंटर के अंतिम N में हो जिनसे उसका संबंध है।
4. न्यूनतम आयु से छोटा बिल्ड रहता है।
5. संरक्षित लेबल वाला बिल्ड रहता है। उसके लेबल वर्तमान एनोटेशन से आते हैं, या जब एनोटेशन न हो तो अपलोड से। संरक्षित बिल्ड अब भी रैंकिंग में हिस्सा लेते हैं, इसलिए रखी गई संख्या N से अधिक हो सकती है।

कोई बिल्ड तब तक कभी नहीं हटाया जाता जब तक उसकी किसी को ज़रूरत हो:

• कोई बाहरी सेवा उसका संदर्भ रखती है।
• कोई फ़ाइल पथ, वर्तमान या इतिहास से, उसे इस्तेमाल करता है।
• कोई अन्य बिल्ड उसे अटैचमेंट के रूप में सूचीबद्ध करता है, अभी या इतिहास में।
• उसे किसी स्टेज पर प्रमोट किया गया है। पहले स्टेज हटाएँ।
• कोई कंटेनर इमेज, Git LFS या npm प्रविष्टि उसे इस्तेमाल करती है।

बिल्ड हटाना तार्किक है: वह सूचियों से हट जाता है और नए डाउनलोड 404 के साथ विफल हो जाते हैं। बाइट बाद में डिस्क से जाते हैं, भौतिक क्लीनअप में। पैकेज संस्करण आरक्षित रहता है, इसलिए वही संस्करण दूसरी सामग्री के साथ दोबारा प्रकाशित नहीं किया जा सकता।

नीति सुरक्षित रूप से चालू करें

पहले पूर्वावलोकन करें, फिर चालू करें। पूर्वावलोकन दिखाता है कि सहेजी गई नीति क्या हटाएगी, और यह कुछ भी नहीं हटाता।

1. चारों कार्रवाइयाँ वाली कुंजी से कनेक्ट करें, और रिपॉज़िटरी का स्टोरेज पैनल खोलें।
2. फ़ील्ड सेट करें और स्वचालित क्लीनअप सक्षम करें बंद छोड़ें। नीति सहेजें चुनें।
3. सहेजी गई नीति का पूर्वावलोकन करें चुनें। सूची अधिकतम 100 बिल्ड दिखाती है जिन्हें सहेजी गई नीति एक बैच में हटाएगी। अगर और उम्मीदवार बचे हैं, तो कंसोल यह बताता है।
4. अगर सूची सही है, तो स्वचालित क्लीनअप सक्षम करें और पुष्टि मुझे पता है कि सक्षम नीति सहेजने से स्वचालित रूप से हटाने की अनुमति मिल जाती है। पर टिक करें, फिर दोबारा सहेजें। इसके लिए artifact.delete चाहिए।

नोट्स:

• पूर्वावलोकन किसी एक क्षण को दिखाता है। जब नीति चलती है, वह फिर रैंकिंग करती है और निर्भरताएँ फिर जाँचती है।
• नीति एक संशोधन के साथ सहेजी जाती है। अगर किसी और ने इसे बदल दिया, तो दोबारा लोड करें और सहेजें।
• सेटिंग्स और उपयोग फिर से लोड करें सेटिंग्स और उपयोग दोबारा लोड करता है।

यह कैसे चलता है

जो API प्रोसेस लिखता है (रीड गेटवे नहीं) वह हर 60 सेकंड में जाँचता है और अधिकतम 20 देय नीतियाँ संभालता है। एक बैच अधिकतम 100 बिल्ड हटाता है। अगर उम्मीदवार बचे हैं, तो अगला बैच एक मिनट बाद शुरू होता है। वरना अगला रन अंतराल के बाद आता है। शेड्यूल डेटाबेस में सहेजा जाता है और रीस्टार्ट के बाद बना रहता है।

आप API ऑपरेशन runStoragePolicy से खुद भी एक बैच चला सकते हैं। उपयोग, पूर्वावलोकन और इवेंट के ऑपरेशन उसी Storage API reference में हैं।

भौतिक क्लीनअप

किसी आर्टिफ़ैक्ट को हटाना, किसी व्यक्ति द्वारा या किसी नीति द्वारा, उसे केवल कैटलॉग से हटाता है। भौतिक क्लीनअप उसके बाइट डिस्क से हटाता है, पृष्ठभूमि में और API, वर्कर या रीड गेटवे को रोके बिना। यह यह भी करता है:

• बिना पूरे हुए समाप्त हो चुके अपलोड रद्द करता है, और उनके भाग हटाता है।
• तैयार अपलोड के अस्थायी भाग हटाता है।

यह हटाने के लिए बिल्ड नहीं चुनता। यह केवल वही हटाता है जो पहले ही हटाया या रद्द किया जा चुका है।

भौतिक क्लीनअप डिफ़ॉल्ट रूप से बंद है, और यह प्रति रिपॉज़िटरी सेट होता है। जिस भी रिपॉज़िटरी का आप इस्तेमाल करते हैं उसमें इसे चालू करें। तब तक, हटाई गई फ़ाइलें, समाप्त हो चुके अपलोड और तैयार अपलोड के भाग डिस्क पर रहते हैं, और कोटा हटाई गई फ़ाइलें गिनता है।

सेटिंग्स

रिपॉज़िटरी के पैनल में, भौतिक क्लीनअप खोलें:

सेटिंग	कंसोल फ़ील्ड	अर्थ	डिफ़ॉल्ट	श्रेणी
चालू करें	पृष्ठभूमि क्लीनअप सक्षम करें	पृष्ठभूमि क्लीनअप चालू करता है	बंद
छूट अवधि	हटाने के बाद छूट अवधि (घंटे)	हटाई गई फ़ाइल कितनी देर डिस्क पर रहती है, घंटों में	24	0–8760
बैच	प्रति बैच फ़ाइलें	एक बैच में संभाली जाने वाली फ़ाइलें	25	1–100
अंतराल	बैचों के बीच अंतराल (सेकंड)	बैचों के बीच सेकंड	60	5–86 400
विलंब	फ़ाइलों के बीच विलंब (मिलीसेकंड)	फ़ाइलों के बीच रुकावट के मिलीसेकंड	50	0–1000

इन्हें लागू करने के लिए सेटिंग्स लागू करें चुनें। बदलाव तुरंत लागू होता है। अगर आप क्लीनअप बंद करते हैं, तो यह वर्तमान फ़ाइल के बाद रुक जाता है। एक बैच का अनुरोध करें जल्द एक बैच माँगता है, यह तुरंत नहीं हटाता। अंतिम बैच का परिणाम देखने के लिए क्लीनअप की स्थिति रीफ़्रेश करें चुनें।

छूट अवधि रीसायकल बिन नहीं है। मान 0 के साथ, कोई फ़ाइल हटाए जाने के तुरंत बाद और कोई पाठक उसे खोले बिना जा सकती है। Arkvory हटाए गए आर्टिफ़ैक्ट को पुनर्स्थापित नहीं कर सकता।

क्लीनअप क्या करता है और क्या छोड़ता है

• यह केवल उन फ़ाइलों को हटाता है जो रद्द या हटाई गई हैं, छूट अवधि के बाद। यह फिर जाँचता है कि उन्हें कुछ भी इस्तेमाल नहीं करता: कोई संदर्भ, फ़ाइल पथ इतिहास या अटैचमेंट इतिहास नहीं।
• खुला हुआ डाउनलोड, लिखा जा रहा अपलोड और चल रहे बैकअप को चाहिए कोई फ़ाइल, क्लीनअप को उस फ़ाइल को छोड़ने पर मजबूर करते हैं। अगला बैच फिर कोशिश करता है। अंतिम परिणाम दिखाता है कि उसने कितनी फ़ाइलें संभालीं, छोड़ीं और विफल रहीं, और कितने बाइट मुक्त किए।
• कोटा और तार्किक क्षमता फ़ाइलों के डिस्क से हटाए जाने के बाद ही मुक्त होती हैं।
• बैच बैच आकार और विलंब से सीमित होता है, जो डिस्क लोड घटाता है। यह कठोर डिस्क थ्रूपुट की गारंटी नहीं देता, और अन्य अनुरोधों की विलंबता पर शून्य प्रभाव का वादा नहीं कर सकता।
• क्लीनअप writer API में चलता है, प्रति डेटाबेस एक बार। writer हर 5 सेकंड में एक देय रिपॉज़िटरी जाँचता है। चालू writer के बिना, कुछ भी साफ़ नहीं होता।
• क्लीनअप तभी चालू करें जब आप हर Arkvory प्रोसेस अपडेट कर चुके हों, गेटवे और वर्कर सहित। क्लीनअप प्रोटोकॉल के बिना पुराना प्रोसेस क्लीनअप को उसका काम टालने पर मजबूर करता है।

आर्टिफ़ैक्ट हटाएँ

आप एक प्रकाशित आर्टिफ़ैक्ट हाथ से हटा सकते हैं। आपको रिपॉज़िटरी पर artifact.delete चाहिए।

1. आर्टिफ़ैक्ट का विवरण में आर्टिफ़ैक्ट खोलें, और आर्टिफ़ैक्ट हटाएँ ढूँढें।
2. निर्भरताएँ जाँचें चुनें। कंसोल दिखाता है कि आर्टिफ़ैक्ट को अब भी क्या इस्तेमाल करता है। अगर कुछ विलोपन रोकता है, तो पहले वह निर्भरता हटानी होगी।
3. पुष्टि के लिए आर्टिफ़ैक्ट की ID चिपकाएँ, फिर यह आर्टिफ़ैक्ट हटाएँ चुनें।

इस तरह हटाने पर संरक्षित लेबल नहीं जाँचे जाते, क्योंकि वस्तु आप खुद चुनते हैं। निर्भरताएँ हमेशा जाँची जाती हैं। विलोपन के बाद:

• आर्टिफ़ैक्ट सूचियों और खोजों से हट जाता है। नया डाउनलोड 404 के साथ विफल हो जाता है। जो डाउनलोड पहले से चल रहा है वह पूरा हो सकता है।
• पैकेज संस्करण आरक्षित रहता है।
• बाइट डिस्क पर तब तक रहते हैं जब तक छूट अवधि के बाद भौतिक क्लीनअप उन्हें न हटा दे।
• आप इसे कंसोल या API में पूर्ववत नहीं कर सकते।

कई आर्टिफ़ैक्ट के लिए, API previewRetention और applyRetention देता है। पूर्वावलोकन किसी तिथि से पहले प्रकाशित उम्मीदवारों को उनके अवरोधक कारणों के साथ सूचीबद्ध करता है। Apply केवल आपके दिए ID हटाता है, प्रति कॉल अधिकतम 100, और हर ID के लिए परिणाम लौटाता है: deleted, already_deleted, protected, changed, not_eligible या not_found। हर परिणाम जाँचें, केवल HTTP स्टेटस नहीं।

स्टोरेज डायग्नोस्टिक्स और इवेंट

अनुभाग चेतावनियाँ, त्रुटियाँ और स्टोरेज इवेंट रिपॉज़िटरी में क्या हुआ, यह सूचीबद्ध करता है, सबसे पुराना पहले, 100 प्रति पेज। अगले पेज के लिए अगले इवेंट लोड करें चुनें। इसे पढ़ने के लिए diagnostics.read चाहिए। API ऑपरेशन getStorageEvents है, स्तर (info, warning, error) से फ़िल्टर के साथ।

इवेंट	स्तर	अर्थ
storage.policy_updated	info	प्रतिधारण नीति सहेजी गई
retention.completed	info	एक बैच ने बिल्ड हटाए। इवेंट गिनती रखता है
retention.failed	error	स्वचालित विलोपन रुक गया, उदाहरण के लिए क्योंकि अधिकृत करने वाली कुंजी निरस्त कर दी गई
cleanup.configured	info	क्लीनअप सेटिंग्स सहेजी गईं
cleanup.completed	info या error	एक क्लीनअप बैच ने फ़ाइलें संभालीं, छोड़ीं या विफल रहीं। यह गिनतियाँ और मुक्त बाइट सूचीबद्ध करता है
capacity.normal, capacity.warning, capacity.critical, capacity.exceeded, capacity.unlimited	info, warning या error	कोटा स्थिति बदली
HTTP error codes	warning या error	इस रिपॉज़िटरी को किसी प्रबंधित कुंजी का अनुरोध विफल हुआ। इवेंट अनुरोध ID, रूट और स्टेटस रखता है

इतिहास सीमित है: प्रति रिपॉज़िटरी 1000 इवेंट और कुल 20 000, और सबसे पुराने हटा दिए जाते हैं। यह best-effort डायग्नोस्टिक्स है, गारंटीकृत डिलीवरी वाला लॉग नहीं। जो चाहिए उसे समय पर निर्यात करें, और दीर्घकालिक प्रमाण के लिए सर्वर लॉग इस्तेमाल करें। निगरानी देखें।

पैनल उपयोग भी दिखाता है: प्रकाशित बाइट, अधूरे अपलोड, क्लीनअप की प्रतीक्षा कर रहे बाइट, और कोटा के विरुद्ध कुल। API ऑपरेशन getStorageUsage है।

जब डिस्क भर जाए

संकेत: अपलोड HTTP 507 और कारण storage_full के साथ विफल होते हैं, GET /health/ready writable: false दिखाता है, या ऑपरेटिंग सिस्टम मुक्त स्थान नहीं होने की सूचना देता है। डाउनलोड काम करते रहते हैं। आपके स्थान मुक्त करने के बाद क्लाइंट अपने अपलोड जारी रख सकते हैं।

1. कारण ढूँढें। स्टोरेज वॉल्यूम, डेटाबेस वॉल्यूम और vault वॉल्यूम का मुक्त स्थान जाँचें। स्टोरेज पैनल के उपयोग आँकड़ों की तुलना करें। बड़े "क्लीनअप की प्रतीक्षा" आँकड़ों का मतलब है कि हटाया गया डेटा अब भी डिस्क पर है। बड़ा "अधूरे अपलोड" आँकड़ा छोड़े गए अपलोड दर्शाता है।
2. क्लीनअप चलाएँ। अगर क्लीनअप बंद है, तो हर रिपॉज़िटरी में इसे चालू करें, छोटी छूट अवधि जैसे 0 के साथ अगर आप स्वीकार करते हैं कि हटाई गई फ़ाइलें तुरंत चली जाएँ। एक बैच का अनुरोध करें चुनें। यह तैयार अपलोड के अस्थायी भाग और समाप्त हो चुके अपलोड भी हटाता है। बैचों की प्रतीक्षा करें और अंतिम परिणाम पढ़ें। क्लीनअप इस्तेमाल में रही फ़ाइलें छोड़ देता है, इसलिए इसे दोहराएँ।
3. जो ज़रूरत न हो हटाएँ। प्रतिधारण नीति लागू करें, या आर्टिफ़ैक्ट हटाएँ। यह स्थान तभी मुक्त करता है जब क्लीनअप बाइट हटा दे।
4. स्थान बढ़ाएँ। वॉल्यूम या डिस्क बढ़ाएँ। अगर vault या अन्य डेटा वही वॉल्यूम साझा करते हैं तो उन्हें हटाकर दूसरी जगह ले जाएँ।
5. रिकवरी जाँचें। स्थान मुक्त होने के बाद, writable वापस true हो जाता है और अपलोड फिर काम करते हैं।

blobs/, staging/ या parts/ में हाथ से फ़ाइलें न हटाएँ: इससे डेटाबेस और डिस्क के बीच का संबंध टूट जाता है। अगर उसी वॉल्यूम पर आपके लॉग और डेटाबेस के लिए रिज़र्व बहुत छोटा है, तो ARKVORY_STORAGE_RESERVE_BYTES बढ़ाएँ।

अगर कोई अपलोड कारण storage_quota या catalog_limit के साथ विफल होता है, तो डिस्क समस्या नहीं है। कोटा या वैश्विक सीमा बढ़ाएँ, या डेटा हटाएँ।

सीमाएँ

• प्रतिधारण नीति केवल पंजीकृत UPack बिल्ड संभालती है। यह कभी अन्य फ़ाइलें नहीं हटाती।
• प्रतिधारण क्रम प्रकाशन समय है, संस्करण संख्या नहीं।
• स्टोरेज, कोटा और क्लीनअप के लिए सेवा कुंजी की स्पष्ट कार्रवाइयाँ चाहिए। पासवर्ड खातों और पुनर्प्राप्ति कुंजी के पास ये नहीं होतीं।
• भौतिक क्लीनअप डिफ़ॉल्ट रूप से बंद है और हर रिपॉज़िटरी के लिए सेट होता है।
• हटाया गया आर्टिफ़ैक्ट पुनर्स्थापित नहीं किया जा सकता। डेटा बैकअप से पुनर्स्थापित करें। बैकअप देखें।
• मिरर की गई रिपॉज़िटरी कोई स्टोरेज नीति नहीं चलातीं। मिरर देखें।
• स्टोरेज स्थानीय फ़ाइल सिस्टम होना चाहिए। नेटवर्क शेयर या कई स्टोरेज बैकएंड का कोई समर्थन नहीं है।

संबंधित पेज

• बैकअप
• मिरर
• निगरानी
• समस्या निवारण
• एनवायरनमेंट वेरिएबल
• रिपॉज़िटरी