मुझे ग्नू टार में एक बग कैसे मिला

टोरंटो विश्वविद्यालय में क्रिस सिबेनमैन , यूनिक्स सिस्टम प्रशासक द्वारा पोस्ट किया गया

समय-समय पर मेरे काम में कुछ अजीब होता है जो मुझे सोचने पर मजबूर कर देता है। यहां तक ​​कि अगर यह तुरंत स्पष्ट नहीं है कि कौन से निष्कर्ष का पालन करें। मैंने हाल ही में उल्लेख किया है कि हमें ग्नू टार में एक बग मिला है, और यह कैसे हुआ इसकी कहानी एक ऐसा मामला है।

बैकअप फ़ाइल सर्वर के लिए, हम अमांडा और GNU टार का उपयोग करते हैं। समय के साथ, हमारे पास कभी-कभी एक दुर्लभ समस्या थी, जहां टार पागल हो गया था जब /var/mail निर्देशिका के साथ फ़ाइल सिस्टम का बैकअप लेते हुए, बड़ी मात्रा में आउटपुट का उत्पादन करता था। आमतौर पर यह प्रक्रिया अनंत तक चली गई और डंप को मारना पड़ा; अन्य मामलों में, यह अभी भी डेटा के टेराबाइट्स जारी करने से समाप्त हो गया था जो पूरी तरह से संपीड़ित लग रहा था। जब मैं एक बार फिर इतनी विशालकाय टार फाइल में आया, तो मैंने इसकी जाँच की - और पाया कि इसमें आंशिक रूप से शून्य बाइट्स हैं, जो tar -t परीक्षण टीम को वास्तव में नापसंद है, जिसके बाद सब कुछ सामान्य हो जाता है।

(इस वजह से, मैं सोच रहा था कि मेलबॉक्स में लोगों में स्वाभाविक रूप से अशक्त बाइट्स दिखाई देते हैं। यह पता चला है कि पाठ फ़ाइलों में नल बाइट्स ढूंढना इतना सरल नहीं है और हाँ, वे वहां हैं)।

हमने हाल ही में उबंटू 18.04 के तहत फ़ाइल सिस्टम को नए लिनक्स फ़ाइल सर्वरों से /var/mail से स्थानांतरित किया है और इसलिए ओएमएनओएस मशीनों पर GNU टार के बाद के और अधिक मानक संस्करण पर स्विच किया गया है। हमें उम्मीद थी कि इससे हमारी समस्याओं का समाधान हो जाएगा, लेकिन वही घटना लगभग तुरंत हुई। इस बार जीएनयू टार ने एक उबंटू मशीन पर काम किया, जहां मैं सभी डिबगिंग टूल्स के साथ अच्छी तरह से परिचित हूं, इसलिए मैंने रनिंग प्रक्रिया की जांच की। परीक्षण से पता चला कि tar read() की एक अंतहीन स्ट्रीम का उत्पादन करता है read() 0 बाइट्स लौटाता है:

 read(6, "", 512) = 0 read(6, "", 512) = 0 [...] read(6, "", 512) = 0 write(1, "\0\0\0\0\0"..., 10240) = 10240 read(6, "", 512) = 0 [...] 

lsof ने कहा कि फाइल डिस्क्रिप्टर 6 किसी और का मेलबॉक्स है।

apt-get source tar का उपयोग करते हुए apt-get source tar मैंने स्रोत कोड डाउनलोड किया और उसमें read() सिस्टम कॉल की तलाश शुरू की, जो फ़ाइल पूर्णता के लिए जाँच नहीं करता था। अप्रत्यक्ष संबोधन के कई स्तरों की जांच करने के बाद, मुझे एक स्पष्ट स्थान मिला, जहां ऐसा लगता है कि इस तरह के एक चेक को छोड़ दिया गया था, अर्थात् स्पार्स.एक्स फ़ाइल से sparse_dump_region फ़ंक्शन में। और फिर मुझे कुछ याद आया।

कुछ महीने पहले, हमने अल्पाइन में एक एनएफएस समस्या का सामना किया । इस बग पर काम करते समय, मैंने अल्पाइन प्रक्रिया का पता लगाया और अन्य बातों के अलावा, यह देखा कि मेलबॉक्सेज़ को आकार देने के लिए यह ftruncate() का उपयोग करता है; कभी-कभी यह उन्हें विस्तारित करता है, अस्थायी रूप से फ़ाइल के एक विरल खंड का निर्माण करता है जब तक कि वह इसे भरता नहीं है, और शायद कभी-कभी इसे संपीड़ित करता है। यह वर्तमान स्थिति के साथ मेल खाना प्रतीत होता है: विरल क्षेत्र जुड़े हुए हैं, और ftruncate() का उपयोग करके फ़ाइल का आकार कम करने से एक ऐसी स्थिति ftruncate() है जहां टार अप्रत्याशित रूप से एक फ़ाइल पूर्णता से सामना करती है।

(यह भी बताता है कि टार को कभी-कभी क्यों बहाल किया जाता है; यदि नया मेल अचानक मेलबॉक्स में बाद में आता है, तो यह अपेक्षित आकार में लौटता है, और टार अब अप्रत्याशित फ़ाइल समाप्ति का सामना नहीं करता है)।

मैंने उबंटू डिबगिंग प्रतीकों और मेरे द्वारा प्राप्त टार पैकेज स्रोत कोड के साथ जीडीबी में थोड़ा गड़बड़ कर दिया, और त्रुटि को पुन: उत्पन्न करने में सक्षम था, हालांकि यह मेरे मूल सिद्धांत से कुछ अलग था। यह पता चला कि sparse_dump_region फ़ाइल के विरल क्षेत्रों को रीसेट नहीं करता है, लेकिन गैर-विरल क्षेत्रों (निश्चित रूप से) को रीसेट करता है, और अगर आप --sparse तर्क के साथ टार चलाते हैं, तो सभी फ़ाइलों (विरल या नहीं) के लिए उपयोग किया जाता है। इस प्रकार, वास्तविक त्रुटि यह है कि यदि आप GNU टार को --sparse तर्क से --sparse हैं और फ़ाइल को संपीड़ित किया जाता है जैसा कि पढ़ा जा रहा है, टार सही ढंग से अपेक्षा से पहले प्राप्त फ़ाइल के अंत को संभाल नहीं सकता है । यदि फ़ाइल फिर से बढ़ती है, टार पुनर्स्थापित करता है।

(सिवाय जब फ़ाइल केवल अंत में विरल हो और केवल इस स्थान पर संपीड़ित हो। इस मामले में, सब कुछ क्रम में है)।

मैंने सोचा था कि वही सब मैं कई साल पहले हमारे ओमनीओएस फ़ाइल सर्वर पर देख सकता था। प्रोग्राम के सिस्टम कॉल और lsof एनालॉग्स को ट्रेस करने के तरीके हैं, और मैं जीएनयू टार के मेरे संस्करण के स्रोत कोड को खोज और देख सकता हूं और इसे ओमनीओएस डिबगर के साथ चला सकता हूं (हालांकि हमारे पास वहां GDB स्थापित नहीं है, और इसी तरह)। लेकिन मैंने नहीं किया। इसके बजाय, हम सिकुड़ गए और आगे बढ़ गए। यह मुझे उबंटू के तहत फाइल सिस्टम को स्थानांतरित करने के लिए ले गया ताकि मैं अपनी उंगली को स्थानांतरित कर दूं और समस्या का पता लगा सकूं।

(यह सिर्फ औजारों और पर्यावरण के बारे में नहीं है; हमने स्वचालित रूप से मान लिया था कि ओमनीओएस के पास जीएनयू टार का कुछ पुराना असमर्थित संस्करण है, जिसकी जांच करने का कोई मतलब नहीं है, क्योंकि निश्चित रूप से समस्या नए संस्करण में हल की गई थी)।

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

पीपीएस: मैंने ग्नू टार डेवलपर्स को बग रिपोर्ट करने की कोशिश नहीं की, क्योंकि मैंने इसे केवल शुक्रवार को ही खोजा था, और विश्वविद्यालय अब शीतकालीन अवकाश पर है। बेझिझक मेरे सामने करो।