💯 🎅 🗣️ हमने लिनक्स कर्नेल में दो सप्ताह एनएफएस बग का शिकार कैसे किया 🈂️ 🤸🏽 🗳️

बग का विस्तृत विवरण GitLab कार्य से खोजता है जिसके कारण लिनक्स कर्नेल के लिए पैच होता है

14 सितंबर को, GitLab समर्थन ने हमारे ग्राहकों में से एक के लिए एक महत्वपूर्ण समस्या की सूचना दी: पहले, GitLab ठीक काम करता है, और फिर उपयोगकर्ताओं को एक त्रुटि मिलती है। उन्होंने Git के माध्यम से कुछ रिपॉजिटरी को क्लोन करने की कोशिश की, और अचानक एक अप्रचलित फ़ाइल के बारे में एक अस्पष्ट संदेश दिखाई दिया: Stale file error । त्रुटि लंबे समय तक बनी रही और तब तक काम नहीं किया जब तक कि सिस्टम एडमिनिस्ट्रेटर ने मैन्युअल रूप से निर्देशिका में ही शुरू नहीं कर दिया।

मुझे Git के आंतरिक तंत्र और NFS नेटवर्क फाइल सिस्टम का अध्ययन करना था। नतीजतन, हमने लिनक्स v4.0 एनएफएस क्लाइंट में एक बग पाया, ट्रोनड माइक्लेबस्ट ने कर्नेल के लिए एक पैच लिखा था , और 26 अक्टूबर से, इस पैच को मुख्य लिनक्स कर्नेल में शामिल किया गया है ।

इस पोस्ट में मैं आपको बताऊंगा कि हमने समस्या का अध्ययन कैसे किया, हमने किस दिशा में सोचा और बग को ट्रैक करने के लिए हमने कौन से उपकरण का उपयोग किया। हम ओलेग देशेवस्की के उत्कृष्ट जासूसी कार्य से प्रेरित थे, जिसका वर्णन "रूबी में एक मेमोरी लीक के लिए दो सप्ताह के लिए शिकार कैसे किया गया था " ।

यह इस बात का एक बड़ा उदाहरण है कि कैसे खुला स्रोत डिबगिंग एक टीम का खेल है जिसमें कई लोग, कंपनियां और देश शामिल हैं। GitLab का आदर्श वाक्य, " हर कोई योगदान कर सकता है " , केवल GitLab के लिए ही नहीं, बल्कि अन्य ओपन सोर्स प्रोजेक्ट्स के लिए भी सही है, जैसे कि लिनक्स कर्नेल।

बग प्रजनन

हमने कई वर्षों तक GFSLab.com पर NFS को रखा, लेकिन फिर अनुप्रयोगों के साथ मशीनों पर रिपॉजिटरी डेटा तक पहुंचने के लिए इसका उपयोग करना बंद कर दिया। हमने सभी Git कॉल को Gitaly में स्थानांतरित कर दिया है । हम उन ग्राहकों के लिए NFS का समर्थन करते हैं जो GitLab पर अपने इंस्टॉलेशन का प्रबंधन करते हैं लेकिन कभी भी उक्त क्लाइंट के समान समस्या का सामना नहीं किया है।

ग्राहक ने कुछ उपयोगी संकेत दिए :

पूर्ण त्रुटि पाठ: fatal: Couldn't read ./packed-refs: Stale file handle ।
जाहिरा तौर पर, समस्या तब उत्पन्न हुई जब क्लाइंट ने गिट में git gc कमांड के साथ मैन्युअल रूप से कचरा संग्रह शुरू किया।
सिस्टम व्यवस्थापक द्वारा निर्देशिका में ls उपयोगिता प्रारंभ करने पर त्रुटि गायब हो गई।
git gc प्रक्रिया से git gc त्रुटि गायब हो गई।

यह स्पष्ट है कि पहले दो बिंदु जुड़े हुए हैं। जब आप Git शाखा में परिवर्तन सबमिट करते हैं, तो Git एक कमजोर लिंक बनाता है - एक लंबी फ़ाइल नाम जो कमिट के लिए शाखा का नाम इंगित करता है। उदाहरण के लिए, master को भेजते समय, रिपॉजिटरी में refs/heads/master नामक एक फाइल बनाई जाएगी:

 $ cat refs/heads/master 2e33a554576d06d9e71bfd6814ee9ba3a7838963

git gc कमांड कई कार्य करता है। उदाहरण के लिए, यह इन कमजोर लिंक (refs) को इकट्ठा करता है और उन्हें packed-refs नामक एकल फ़ाइल में packed-refs । यह काम को थोड़ा तेज करता है, क्योंकि एक बड़ी फ़ाइल को पढ़ना कई छोटे लोगों की तुलना में आसान है। उदाहरण के लिए, git gc कमांड चलाने के बाद, packed-refs फ़ाइल कुछ इस तरह दिख सकती है:

 # pack-refs with: peeled fully-peeled sorted 564c3424d6f9175cf5f2d522e10d20d781511bf1 refs/heads/10-8-stable edb037cbc85225261e8ede5455be4aad771ba3bb refs/heads/11-0-stable 94b9323033693af247128c8648023fe5b53e80f9 refs/heads/11-1-stable 2e33a554576d06d9e71bfd6814ee9ba3a7838963 refs/heads/master

packed-refs फ़ाइल कैसे बनाई जाती है? यह पता लगाने के लिए, हमने strace git gc कमांड को चलाया, जहां हमारे पास एक कमजोर लिंक था। यहां वे पंक्तियां हैं जो प्रासंगिक हैं:

 28705 open("/tmp/libgit2/.git/packed-refs.lock", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0666) = 3 28705 open(".git/packed-refs", O_RDONLY) = 3 28705 open("/tmp/libgit2/.git/packed-refs.new", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0666) = 4 28705 rename("/tmp/libgit2/.git/packed-refs.new", "/tmp/libgit2/.git/packed-refs") = 0 28705 unlink("/tmp/libgit2/.git/packed-refs.lock") = 0

सिस्टम कॉल ने दिखाया कि git gc कमांड:

packed-refs.lock । यह अन्य प्रक्रियाओं को बताता है कि packed-refs फ़ाइल लॉक है और बदल नहीं सकती है।
खोला packed-refs.new ।
मैंने packed-refs.new में कमजोर लिंक packed-refs.new ।
packed-refs.new packed-refs . packed-refs करने के लिए packed-refs.new नाम packed-refs.new ।
हटाए गए packed-refs.lock ।
कमजोर कड़ियों को हटा दिया।

यहां मुख्य बिंदु चौथा है, जिसका नाम है, नामकरण, जहां गिट packed-refs फ़ाइल का परिचय देता है। git gc न केवल कमजोर लिंक एकत्र करता है, बल्कि बहुत अधिक संसाधन-गहन कार्य भी करता है - यह अप्रयुक्त वस्तुओं को खोजता है और हटाता है। बड़े भंडार में, यह एक घंटे से अधिक समय तक रह सकता है।

और हमने खुद से पूछा: बड़े रिपॉजिटरी में git gc सफाई के दौरान फाइल को खुला रखता है? हमने strace लॉग का अध्ययन किया, lsof यूटिलिटी लॉन्च की, और यहाँ हमने git gc प्रक्रिया के बारे में सीखा है:

जैसा कि आप देख सकते हैं, Garbage collect objects की संभावित लंबी प्रक्रिया के बाद packed-refs फ़ाइल बहुत अंत में बंद हो जाती है।

तो निम्न प्रश्न उत्पन्न हुआ: NFS कैसे व्यवहार करता है जब packed-refs फ़ाइल एक नोड पर खुली होती है और दूसरा उस समय इसका नाम बदल देता है?

"वैज्ञानिक उद्देश्यों के लिए," हमने ग्राहक को दो अलग-अलग मशीनों (एलिस और बॉब) पर एक प्रयोग करने के लिए कहा:
1) एनएफएस साझा की गई मात्रा में, दो फाइलें बनाएं: test1.txt और test2.txt विभिन्न सामग्रियों के साथ, ताकि उनके बीच अंतर करना आसान हो:

 alice $ echo "1 - Old file" > /path/to/nfs/test1.txt alice $ echo "2 - New file" > /path/to/nfs/test2.txt

2) ऐलिस की मशीन पर, फ़ाइल test1.txt खुली होनी चाहिए:

 alice $ irb irb(main):001:0> File.open('/path/to/nfs/test1.txt')

3) ऐलिस की मशीन पर, लगातार test1.txt की सामग्री प्रदर्शित करें:

 alice $ while true; do cat test1.txt; done

4) फिर, बॉब की मशीन पर, कमांड चलाएँ:

 bob $ mv -f test2.txt test1.txt

आखिरी चरण यह बताता है कि मौजूदा फ़ाइल को अधिलेखित करने पर packed-refs फाइल के साथ git gc क्या करता है।
ग्राहक की मशीन पर, परिणाम कुछ इस तरह से देखा गया:

 1 - Old file 1 - Old file 1 - Old file cat: test1.txt: Stale file handle

वहाँ है! हमें लगता है कि समस्या को नियंत्रित तरीके से नियंत्रित किया गया है। लेकिन लिनक्स एनएफएस सर्वर पर एक ही प्रयोग में, यह समस्या उत्पन्न नहीं हुई। परिणाम अपेक्षित था - नया नाम बदलने के बाद स्वीकार किया गया था:

 1 - Old file 1 - Old file 1 - Old file 2 - New file <--- RENAME HAPPENED 2 - New file 2 - New file

व्यवहार में यह अंतर कहां से आता है? यह पता चला है कि क्लाइंट ने ईसिलन एनएफएस स्टोरेज का उपयोग किया था, जो केवल एनएफएस v4.0 का समर्थन करता था। जब हमने प्रॉक्सी सेटिंग्स को बदलकर v4.0 में बदल दिया, तो /etc/fstab में vers=4.0 पैरामीटर का उपयोग करके, परीक्षण ने लिनक्स NFS सर्वर के लिए एक अलग परिणाम दिखाया:

 1 - Old file 1 - Old file 1 - Old file 1 - Old file <--- RENAME HAPPENED 1 - Old file 1 - Old file

अप्रचलित Stale file handle बजाय Stale file handle लिनक्स एनएफएस v4.0 सर्वर ने अप्रचलित सामग्री प्रदर्शित की । यह पता चला है कि व्यवहार में अंतर को एनएफएस विनिर्देशों द्वारा समझाया जा सकता है। RFC 3010 से :

फ़ाइल विवरणक पुराना हो सकता है या नाम बदलने पर समाप्त हो सकता है, लेकिन हमेशा नहीं। सर्वर कार्यान्वयनकर्ताओं को यह सुनिश्चित करने के लिए कदम उठाने की सलाह दी जाती है कि फ़ाइल विवरणक समाप्त न हों और इस तरह समाप्त न हों।

दूसरे शब्दों में, एनएफएस सर्वर चुन सकते हैं कि किसी फ़ाइल का नाम बदलने पर कैसे व्यवहार किया जाए, और एनएफएस सर्वर ऐसे मामलों में काफी हद तक Stale file error देता है। हमने सुझाव दिया कि समस्या का कारण एक ही है, हालांकि परिणाम अलग थे। हमें संदेह था कि यह कैश चेक था, क्योंकि निर्देशिका में ls उपयोगिता ने त्रुटि को हटा दिया। अब हमारे पास एक प्रतिलिपि प्रस्तुत करने योग्य परीक्षण परिदृश्य था, और हमने विशेषज्ञों - लिनक्स एनएफएस मेंटेनर्स का रुख किया।

गलत ट्रेस: एक NFS सर्वर पर प्रतिनिधि

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

NFS सर्वर पर प्रतिनिधिमंडल क्या है?

संक्षेप में, NFS v4 संस्करण में फ़ाइल पहुंच को गति देने के लिए एक प्रतिनिधिमंडल समारोह है। सर्वर क्लाइंट के लिए एक्सेस पढ़ या लिख सकता है, ताकि क्लाइंट को सर्वर से लगातार यह पूछने की जरूरत न पड़े कि फाइल दूसरे क्लाइंट से बदल दी गई है या नहीं। सीधे शब्दों में कहें, एक रिकॉर्ड सौंपना किसी को अपनी नोटबुक उधार देने जैसा है और कहा, "आप यहां लिखते हैं, और जब मैं तैयार होता हूं तो मैं इसे उठाऊंगा।" और एक व्यक्ति को हर बार जब आपको कुछ लिखने की आवश्यकता होती है, तो नोटबुक के लिए पूछने की ज़रूरत नहीं है - उसके पास कार्रवाई की पूरी स्वतंत्रता है जब तक कि नोटबुक को दूर नहीं किया जाता है। एनएफएस में, नोटबुक वापस करने के अनुरोध को प्रतिनिधिमंडल निरसन कहा जाता है।

NFS प्रतिनिधि निरसन में एक बग Stale file handle समस्या की व्याख्या कर सकता है। याद रखें कि ऐलिस के test1.txt में test1.txt को कैसे खोला गया था, और फिर test2.txt ने test2.txt बदल test2.txt । हो सकता है कि सर्वर test1.txt के प्रतिनिधिमंडल को रद्द करने में असमर्थ था, और इससे अमान्य स्थिति test1.txt । इस सिद्धांत का परीक्षण करने के लिए, हमने tcpdump उपयोगिता के साथ NFC ट्रैफ़िक रिकॉर्ड किया और Wireshark का उपयोग करके इसे विज़ुअलाइज़ किया।

नेटवर्क ट्रैफ़िक का विश्लेषण करने के लिए, विशेष रूप से कार्रवाई में NFS की खोज के लिए Wireshark एक बेहतरीन ओपन सोर्स टूल है। हमने एनएफएस सर्वर पर निम्नलिखित कमांड का उपयोग करके ट्रेस रिकॉर्ड किया:

 tcpdump -s 0 -w /tmp/nfs.pcap port 2049

यह कमांड उन सभी एनएफएस ट्रैफ़िक को दर्ज करता है जो आमतौर पर टीसीपी पोर्ट 2049 से गुजरते हैं। चूंकि हमारा प्रयोग एनएफएस v4.1 के साथ सफल रहा था, लेकिन एनएफएस v4.0 के साथ नहीं, हम काम और गैर-कार्यशील मामले में एनएफएस के व्यवहार की तुलना कर सकते हैं। Wireshark के साथ, हमने निम्नलिखित व्यवहार देखा:

NFS v4.0 (पदावनत फ़ाइल)

यह आरेख बताता है कि चरण 1 में, ऐलिस test1.txt खोलता है और पहचानकर्ता stateid 0x3000 के साथ एक एनएफएस फ़ाइल विवरणक प्राप्त करता है। जब बॉब फ़ाइल का नाम बदलने की कोशिश करता है, तो एनएफएस सर्वर NFS4ERR_DELAY संदेश भेजकर फिर से कोशिश करने के लिए कहता है, और वह संदेश CB_RECALL (चरण 3) के माध्यम से ऐलिस से प्रतिनिधिमंडल को याद करता है। ऐलिस प्रतिनिधिमंडल (चरण 4 में DELEGRETURN) लौटाता है, और बॉब RENAME संदेश फिर से भेजने की कोशिश करता है (चरण 5)। RENAME को दोनों मामलों में निष्पादित किया जाता है, लेकिन ऐलिस उसी विवरणक द्वारा फ़ाइल को पढ़ना जारी रखता है।

NFS v4.1 (कामकाजी मामला)

यहाँ चरण 6 में अंतर दिखाई दे रहा है। NFS v4.0 (अप्रचलित फ़ाइल के साथ) ऐलिस stateid उसी stateid का उपयोग करने की कोशिश करता है। NFS v4.1 (कामकाजी मामला) में, ऐलिस अतिरिक्त LOOKUP और OPEN ऑपरेशन करता है, इसलिए सर्वर एक अलग stateid देता है। V4.0 में, यह कोई अतिरिक्त संदेश नहीं भेजता है। यह बताता है कि ऐलिस पुरानी सामग्री क्यों देखती है - वह एक पुराने विवरणक का उपयोग करती है।

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

 echo 0 > /proc/sys/fs/leases-enable

हमने प्रयोग दोहराया, लेकिन समस्या दूर नहीं हुई। हमने यह सुनिश्चित किया कि समस्या NFS सर्वर या प्रतिनिधिमंडल में नहीं थी, और कर्नेल में NFS क्लाइंट को देखने का निर्णय लिया।

गहरी खुदाई: लिनक्स एनएफएस क्लाइंट

पहला सवाल जिसका जवाब हमें एनएफएस मेंटेनर्स को देना था:

क्या यह समस्या नवीनतम कर्नेल संस्करण में बनी रहती है?

क्रमशः संस्करण 3.10.0-862.11.6 और 4.4.0-130 के साथ CentOS 7.2 और Ubuntu 16.04 गुठली में समस्या हुई। लेकिन दोनों कोर नवीनतम संस्करण से पिछड़ गए, जो उस समय 4.19-आरसी 2 था।

हमने Google क्लाउड प्लेटफ़ॉर्म (GCP) पर नए उबंटू 16.04 वर्चुअल मशीन को तैनात किया, नवीनतम लिनक्स कर्नेल को क्लोन किया, और कर्नेल विकास वातावरण स्थापित किया। हमने menuconfig का उपयोग करके .config फ़ाइल बनाई और सत्यापित किया कि:

NFS ड्राइवर को एक मॉड्यूल ( CONFIG_NFSD=m ) के रूप में संकलित किया जाता है।
सही GCP कर्नेल पैरामीटर सही ढंग से निर्दिष्ट हैं।

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

हमने सुनिश्चित किया कि अप्रचलित फ़ाइल की समस्या नवीनतम कर्नेल संस्करण में दूर नहीं हुई। हमने खुद से पूछा:

वास्तव में समस्या कहां उत्पन्न होती है?
एनएफएस v4.0 में ऐसा क्यों होता है, लेकिन v4.1 में नहीं?

इन सवालों का जवाब देने के लिए, हमने NFS स्रोत कोड में देरी की। हमारे पास कर्नेल डिबगर नहीं था, इसलिए हमने स्रोत कोड को दो प्रकार के कॉल भेजे:

pr_info() (यह pr_info() )।
dump_stack() : यह वर्तमान फ़ंक्शन कॉल के लिए स्टैक ट्रेस दिखाता है।

उदाहरण के लिए, हमने जो पहला काम किया, वह nfs4_file_open() फ़ंक्शन से fs/nfs/nfs4file.c :

 static int nfs4_file_open(struct inode *inode, struct file *filp) { ... pr_info("nfs4_file_open start\n"); dump_stack();

बेशक, हम लिनक्स डायनामिक डिबगिंग के साथ dprintk को dprintk कर सकते dprintk या rpcdebug उपयोग कर rpcdebug , लेकिन हम परिवर्तनों के लिए जाँच करने के लिए अपने स्वयं के संदेश जोड़ना चाहते हैं।

प्रत्येक परिवर्तन के बाद, हमने मॉड्यूल को फिर से जोड़ दिया और कमांड का उपयोग करके इसे कर्नेल में पुनः इंस्टॉल किया:

 make modules sudo umount /mnt/nfs-test sudo rmmod nfsv4 sudo rmmod nfs sudo insmod fs/nfs/nfs.ko sudo mount -a

एनएफएस मॉड्यूल के साथ, हम एनएफएस कोड को समझने के लिए प्रयोगों को दोहराने और संदेश प्राप्त करने में सक्षम थे। उदाहरण के लिए, आप तुरंत देख सकते हैं कि क्या होता है जब आवेदन open() :

 Sep 24 20:20:38 test-kernel kernel: [ 1145.233460] Call Trace: Sep 24 20:20:38 test-kernel kernel: [ 1145.233462] dump_stack+0x8e/0xd5 Sep 24 20:20:38 test-kernel kernel: [ 1145.233480] nfs4_file_open+0x56/0x2a0 [nfsv4] Sep 24 20:20:38 test-kernel kernel: [ 1145.233488] ? nfs42_clone_file_range+0x1c0/0x1c0 [nfsv4] Sep 24 20:20:38 test-kernel kernel: [ 1145.233490] do_dentry_open+0x1f6/0x360 Sep 24 20:20:38 test-kernel kernel: [ 1145.233492] vfs_open+0x2f/0x40 Sep 24 20:20:38 test-kernel kernel: [ 1145.233493] path_openat+0x2e8/0x1690 Sep 24 20:20:38 test-kernel kernel: [ 1145.233496] ? mem_cgroup_try_charge+0x8b/0x190 Sep 24 20:20:38 test-kernel kernel: [ 1145.233497] do_filp_open+0x9b/0x110 Sep 24 20:20:38 test-kernel kernel: [ 1145.233499] ? __check_object_size+0xb8/0x1b0 Sep 24 20:20:38 test-kernel kernel: [ 1145.233501] ? __alloc_fd+0x46/0x170 Sep 24 20:20:38 test-kernel kernel: [ 1145.233503] do_sys_open+0x1ba/0x250 Sep 24 20:20:38 test-kernel kernel: [ 1145.233505] ? do_sys_open+0x1ba/0x250 Sep 24 20:20:38 test-kernel kernel: [ 1145.233507] __x64_sys_openat+0x20/0x30 Sep 24 20:20:38 test-kernel kernel: [ 1145.233508] do_syscall_64+0x65/0x130

ये do_dentry_open और vfs_open क्या हैं? लिनक्स में एक वर्चुअल फाइल सिस्टम ( VFS ), एक अमूर्त परत है जो सभी फाइल सिस्टम के लिए एक सामान्य इंटरफ़ेस प्रदान करता है। VFS प्रलेखन कहता है:

VFS इम्प्लांट खुले (2), स्टेट (2), chmod (2) और अन्य सिस्टम कॉल। VFS सिस्टम पथ नाम तर्क का उपयोग करता है जो उन्हें निर्देशिका प्रविष्टियों (डेंट्री कैश, या dcache) के लिए कैश की खोज करने के लिए दिया जाता है। यह एक बहुत तेज़ खोज इंजन प्रदान करता है जो पथ नाम (या फ़ाइल नाम) को एक विशिष्ट डेंट्री में परिवर्तित करता है। डेंट्री रैम में रहता है और डिस्क पर कभी भी सहेजा नहीं जाता है - वे केवल प्रदर्शन के लिए मौजूद हैं।

और यह हमारे ऊपर आया - अगर डेंट्री कैश में समस्या है तो क्या होगा?

हमने देखा कि डेंट्री कैश आमतौर पर fs/nfs/dir.c में चेक किया fs/nfs/dir.c हम nfs4_lookup_revalidate() फ़ंक्शन में विशेष रूप से रुचि रखते थे, और एक प्रयोग के रूप में, हमने इसे काम किया:

 diff --git a/fs/nfs/dir.cb/fs/nfs/dir.c index 8bfaa658b2c1..ad479bfeb669 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -1159,6 +1159,7 @@ static int nfs_lookup_revalidate(struct dentry *dentry, unsigned int flags) trace_nfs_lookup_revalidate_enter(dir, dentry, flags); error = NFS_PROTO(dir)->lookup(dir, &dentry->d_name, fhandle, fattr, label); trace_nfs_lookup_revalidate_exit(dir, dentry, flags, error); + goto out_bad; if (error == -ESTALE || error == -ENOENT) goto out_bad; if (error)

और इस प्रयोग में, एक अप्रचलित फ़ाइल समस्या उत्पन्न नहीं हुई! अंत में, हमने निशान पर हमला किया।

यह पता लगाने के लिए कि एनएफएस v4.1 में समस्या क्यों नहीं हुई, हमने इस फ़ंक्शन में ब्लॉक करने के लिए प्रत्येक में pr_info() कॉल जोड़े। हमने NFS v4.0 और v4.1 के साथ प्रयोग किया और संस्करण v4.1 में एक विशेष स्थिति पाई:

 if (NFS_SB(dentry->d_sb)->caps & NFS_CAP_ATOMIC_OPEN_V1) { goto no_open; }

NFS_CAP_ATOMIC_OPEN_V1 क्या है? यह कर्नेल पैच कहता है कि यह NFS v4.1 की एक विशेषता है, और fs/nfs/nfs4proc.c में कोड ने पुष्टि की है कि यह पैरामीटर v4.1 में है, लेकिन v4.0 में नहीं:

 static const struct nfs4_minor_version_ops nfs_v4_1_minor_ops = { .minor_version = 1, .init_caps = NFS_CAP_READDIRPLUS | NFS_CAP_ATOMIC_OPEN | NFS_CAP_POSIX_LOCK | NFS_CAP_STATEID_NFSV41 | NFS_CAP_ATOMIC_OPEN_V1

इसलिए, संस्करण अलग-अलग व्यवहार करते हैं - v4.1 में, goto no_open nfs_lookup_revalidate() फ़ंक्शन में अधिक चेक कॉल करता है, और v4.0 में nfs4_lookup_revalidate() फ़ंक्शन पहले लौटता है। और हमने समस्या का समाधान कैसे किया?

निर्णय

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

यह पता चला है कि NFS v4.0 बग का फिक्स कोड बेस में गहरा था जितना हमने सोचा था। Trond ने इसे पैच में अच्छी तरह से वर्णित किया:

यह सुनिश्चित करने के लिए आवश्यक है कि पहले से ही खोली गई फ़ाइल को खोलने पर इनोड और डेंट्री को सही ढंग से डबल-चेक किया गया हो। अभी हम NFSv4.0 या तो डबल-चेकिंग नहीं कर रहे हैं, क्योंकि खुली फ़ाइल कैश है। आइए इसे ठीक करें और खुली फ़ाइलों को केवल विशेष मामलों में - खुली फ़ाइलों को पुनर्स्थापित करने और प्रतिनिधिमंडल को वापस करने के लिए।

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

हम अच्छी तरह से समझ गए थे कि परिवर्तन अभी तक स्थिर कर्नेल संस्करण में नहीं होंगे, इसलिए हमने इस समस्या का एक अस्थायी समाधान Gitaly में जोड़ा । हमने प्रयोग किया और सत्यापित किया कि packed-refs फ़ाइल में कॉलिंग stat() को कर्नेल डेंट्री कैश में नामांकित फ़ाइल को डबल-चेक करने का कारण बनता है। सादगी के लिए, हमने एनएफएस ही नहीं, बल्कि किसी भी फाइल सिस्टम के लिए गीताली में इसे लागू किया। Gitaly रिपॉजिटरी खोलने से पहले सत्यापन केवल एक बार किया जाता है, और अन्य फ़ाइलों के लिए पहले से ही अन्य stat() कॉल हैं।

हमने क्या सीखा है

एक बग सॉफ्टवेयर स्टैक के किसी भी कोने में छिपा सकता है, और कभी-कभी आपको एप्लिकेशन के बाहर देखने की आवश्यकता होती है। यदि आपके पास खुले स्रोत की दुनिया में उपयोगी कनेक्शन हैं, तो इससे आपका काम आसान हो जाएगा।

समस्या को ठीक करने के लिए, और हमारे सवालों के जवाब देने और एनएफएस का पता लगाने में मदद करने के लिए ब्रूस फील्ड्स को ट्रॉनड मायुकबस्ट के लिए बहुत धन्यवाद। यह ऐसी जवाबदेही और व्यावसायिकता के लिए है कि हम खुले स्रोत डेवलपर्स के समुदाय को महत्व देते हैं।

हमने लिनक्स कर्नेल में दो सप्ताह एनएफएस बग का शिकार कैसे किया