جدول المحتوى

.

ओपनएआई कोडेक्स कमांड-लाइन इंटरफेस (CLI) में अत्यधिक डेटा लेखन से संबंधित एक गंभीर बग सामने आया है, जो सीधे तौर पर एसएसडी के भौतिक जीवनकाल को खतरे में डाल रहा है। तकनीकी रिपोर्टों के अनुसार, लॉगिंग सिस्टम में एक गलत कॉन्फ़िगरेशन के कारण सॉफ़्टवेयर प्रति वर्ष ड्राइव पर 640 TB तक डेटा लिख ​​सकता है, जो अधिकांश मौजूदा उपभोक्ता एसएसडी की भार वहन क्षमता से कहीं अधिक है।.

तकनीकी जगत से एक चौंकाने वाली खोज।

यह समस्या सबसे पहले तब सामने आई जब जून के मध्य में 1996fanrui नामक एक GitHub उपयोगकर्ता ने अपने सिस्टम पर असामान्य रूप से उच्च डिस्क गतिविधि देखी। गहन विश्लेषण करने के बाद, उन्होंने पाया कि OpenAI Codex लगातार ~/.codex/logs_2.sqlite पथ पर स्थित एक स्थानीय SQLite डेटाबेस में डेटा लिख ​​रहा था।.

वास्तविक डेटा से पता चलता है कि लगातार 21 दिनों तक चलने के बाद हार्ड ड्राइव में लगभग 37 TB डेटा जमा हो गया। अगर इसकी गणना वार्षिक आधार पर की जाए, तो यह संख्या लगभग 640 टेराबाइट्स (TB) तक पहुँच जाती है। इसे समझने के लिए, एक सामान्य 1 TB SSD की कुल लिखित क्षमता (TBW) लगभग 600 TB होती है। इसलिए, यह सॉफ़्टवेयर बग अकेले ही एक नए SSD की पूरी जीवन अवधि को 12 महीने से भी कम समय में खत्म कर सकता है।.

तकनीकी कारण: जब लॉगिंग का स्तर नियंत्रण से बाहर हो जाता है।

समस्या की जड़ लॉगिंग कॉन्फ़िगरेशन में है, जिसे ओपनएआई ने अंतिम उपयोगकर्ताओं के लिए जारी करते समय अनजाने में नज़रअंदाज़ कर दिया था। कोडेक्स का SQLite प्रतिक्रिया सिस्टम डिफ़ॉल्ट रूप से वैश्विक TRACE स्तर पर काम करता है। प्रोग्रामिंग में यह सबसे शोरगुल वाला स्तर है, जहाँ छोटी से छोटी घटनाओं को भी लॉग किया जाता है।.

यह सिस्टम वेबसॉकेट पैकेट से लेकर सिस्टम कॉन्फ़िगरेशन फ़ाइलें (passwd या ld.so.cache) खोलने जैसी सामान्य फ़ाइल सिस्टम घटनाओं तक, सब कुछ लॉग करता है। खास बात यह है कि सॉफ़्टवेयर मानक पर्यावरण चर RUST_LOG अनदेखा करता प्रतीत होता है, जिससे उपयोगकर्ताओं के पास पारंपरिक तरीकों से लॉगिंग के स्तर को कम करने का कोई आसान तरीका नहीं बचता है।.

आगे के विश्लेषण से पता चला कि रिकॉर्ड किए गए डेटा का लगभग 71% हिस्सा TRACE-स्तर के शोर से बना था, जिसका औसत उपयोगकर्ता के लिए कोई व्यावहारिक नैदानिक ​​मूल्य नहीं था।.

लेखन प्रवर्धन प्रभाव

समस्या केवल लॉग फ़ाइल के आकार में वृद्धि ही नहीं थी। इस मामले में SQLite डेटाबेस की प्रकृति ही अत्यधिक डेटा लेखन प्रवर्धन का कारण बनी। सिस्टम ने केवल अधिक डेटा लिखने के बजाय प्रति मिनट हजारों इंसर्ट और डिलीट ऑपरेशन किए।.

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

उपयोगकर्ताओं के लिए अस्थायी समाधान

हालांकि OpenAI ने हाल ही में SQLite की स्थिरता के संबंध में अपडेट जारी किए हैं, लेकिन अत्यधिक उच्च डेटा राइट स्पीड की समस्या अभी भी अनसुलझी है। आधिकारिक पैच की प्रतीक्षा करते हुए, Linux और macOS उपयोगकर्ता अपनी हार्ड ड्राइव को सुरक्षित रखने के लिए निम्नलिखित विधि का उपयोग कर सकते हैं:

~/.codex/logs_2.sqlite फ़ाइल को /tmp/ निर्देशिका में रीडायरेक्ट करने के लिए एक सिंबॉलिक लिंक (symlink) का उपयोग करें। /tmp/ डायरेक्टरी आमतौर पर RAM (tmpfs) से मैप की जाती है, जिसका अर्थ है कि लॉग डेटा SSD के बजाय RAM में लिखा जाता है। चूंकि इस फाइल में महत्वपूर्ण वार्तालाप डेटा नहीं है, इसलिए कंप्यूटर को पुनः आरंभ करने पर लॉग डेटा के नष्ट होने से उपयोगकर्ता अनुभव प्रभावित नहीं होगा।.

विशेषज्ञों का सुझाव है कि कोडेक्स सीएलआई उपयोगकर्ता तुरंत अपनी ड्राइव गतिविधि की जांच करें और अपने स्टोरेज डिवाइस को अनावश्यक भौतिक क्षति से बचाने के लिए डेटा रीडायरेक्शन उपाय लागू करें।.

स्रोत: https://baodanang.vn/loi-openai-codex-cli-am-tham-bao-mon-ssd-nguy-co-hong-o-cung-trong-chua-day-mot-nam-3341429.html