मैंने एक तेज़ वैकल्पिक रिटर्माउंट लिखा , जो "मेरे लिए काम करता है", क्योंकि यह समस्या मुझे परेशान करती रही।
आप इसे इस तरह से उपयोग कर सकते हैं:
pip3 install --user ratarmount
ratarmount my-huge-tar.tar mount-folder
ls -la mount-folder # will show the contents of the tar top-level
जब आप कर रहे हैं आप इसे किसी भी FUSE माउंट की तरह unmount कर सकते हैं:
fusermount -u mount-folder
यह आर्कमाउंट से तेज क्यों है?
यह इस बात पर निर्भर करता है कि आप क्या मापते हैं।
यहां मेमोरी फ़ुटप्रिंट का एक बेंचमार्क है और पहले माउंटिंग के लिए आवश्यक समय है, साथ ही एक साधारण cat <file-in-tar>कमांड और एक साधारण findकमांड के लिए एक्सेस टाइम भी है ।
प्रत्येक 1k फ़ाइलों वाले फ़ोल्डर बनाए गए थे और फ़ोल्डरों की संख्या विविध है।
निचले बाएं प्लॉट में cat <file>10 बेतरतीब ढंग से चुनी गई फ़ाइलों के लिए न्यूनतम और अधिकतम मापा बार को इंगित करने में त्रुटि बार दिखाई देते हैं ।
फ़ाइल का समय
हत्यारा तुलना वह समय है जिसे cat <file>समाप्त करने में समय लगता है । किसी कारण से, यह तीतर फ़ाइल आकार (लगभग बाइट्स प्रति फ़ाइल x संख्या की बाइट्स) के साथ रेखीय रूप से रिटर्माउंट में निरंतर समय के दौरान संग्रह के लिए होता है। इससे ऐसा लगता है कि आर्काइवमाउंट बिल्कुल भी चाहने का समर्थन नहीं करता है।
संकुचित TAR फ़ाइलों के लिए, यह विशेष रूप से ध्यान देने योग्य है।
cat <file>पूरे .tar.bz2 फ़ाइल को बढ़ते हुए दोगुना से अधिक समय लेता है! उदाहरण के लिए, 10k खाली (!) फ़ाइलों के साथ TAR को आर्कमाउंट के साथ माउंट करने के लिए 2.9 s लगते हैं लेकिन जो फ़ाइल एक्सेस की जाती है, उसके आधार पर cat3ms और 5s के बीच का उपयोग होता है। समय लगता है TAR के अंदर फ़ाइल की स्थिति पर निर्भर करता है। TAR के अंत में मौजूद फ़ाइलों की तलाश में अधिक समय लगता है; यह दर्शाता है कि "तलाश" का अनुकरण किया गया है और फ़ाइल से पहले टीएआर में सभी सामग्री को पढ़ा जा रहा है।
फ़ाइल की सामग्री प्राप्त करने में दोगुना से अधिक समय लग सकता है क्योंकि पूरे TAR को बढ़ाना अपने आप में अप्रत्याशित है। कम से कम, यह बढ़ते समय के रूप में उसी समय में समाप्त होना चाहिए। एक स्पष्टीकरण यह होगा कि फ़ाइल का अनुकरण एक से अधिक बार किया जा रहा है, शायद तीन बार भी।
Ratarmount प्रतीत होता है कि फ़ाइल प्राप्त करने में हमेशा एक ही समय लगता है क्योंकि यह सही मांग का समर्थन करता है। Bzip2 संकुचित TARs के लिए, यह bzip2 ब्लॉक को भी ढूंढता है, जिसके पते भी इंडेक्स फ़ाइल में संग्रहीत हैं। सैद्धांतिक रूप से, फ़ाइलों की संख्या के साथ स्केल करने वाला एकमात्र हिस्सा इंडेक्स में लुकअप है और इसे ओ (लॉग (एन)) के साथ स्केल करना चाहिए क्योंकि यह फ़ाइल पथ और नाम से सॉर्ट किया गया है।
स्मृति पदचिह्न
सामान्य तौर पर, अगर आपके पास TAR के अंदर 20k से अधिक फाइलें हैं, तो ratarmount की मेमोरी फुटप्रिंट छोटी होगी क्योंकि इंडेक्स को डिस्क के रूप में लिखा जाता है क्योंकि यह बनाया गया है और इसलिए मेरे सिस्टम पर लगभग 30MB की निरंतर मेमोरी फुटप्रिंट है।
एक छोटा अपवाद gzip डिकोडर बैकेंड है, जो किसी कारण से अधिक यादों की आवश्यकता होती है क्योंकि gzip बड़ा हो जाता है। यह मेमोरी ओवरहेड टीएआर के अंदर मांगने के लिए आवश्यक सूचकांक हो सकता है लेकिन आगे की जांच की आवश्यकता है क्योंकि मैंने उस बैकएंड को नहीं लिखा था।
इसके विपरीत, आर्कमाउंट पूरे इंडेक्स को रखता है, जो कि 2M फाइलों के लिए 4GB है, पूरी तरह से मेमोरी में जब तक TAR माउंट है।
बढ़ते समय
मेरी पसंदीदा विशेषता किसी भी बाद की कोशिश पर बिना किसी देरी के टीएआर को माउंट करने में सक्षम है। इसका कारण यह है कि सूचकांक, जो फ़ाइल नाम को मेटाडेटा और TAR के अंदर की स्थिति में मैप करता है, TAR फ़ाइल के बगल में बनाई गई एक इंडेक्स फ़ाइल को लिखा जाता है।
बढ़ते समय के लिए आवश्यक समय आर्कमाउंट में थोड़े अजीब व्यवहार करता है। लगभग 20k फाइलों से शुरू होकर यह फाइलों की संख्या के संबंध में रैखिक रूप से बजाय चतुष्कोणीय पैमाने पर शुरू होती है। इसका मतलब है कि मोटे तौर पर 4M फाइलों से शुरू होकर, रिटर्माउंट, आर्कमाउंट की तुलना में बहुत तेज होना शुरू होता है, जबकि TAR की छोटी फाइलों के लिए यह 10 गुना तक धीमी होती है! फिर फिर से, छोटी फ़ाइलों के लिए, यह ज्यादा फर्क नहीं पड़ता कि टार को माउंट करने के लिए 1s या 0.1s लगते हैं (पहली बार)।
Bz2 संपीड़ित फ़ाइलों के लिए बढ़ते समय हर समय सबसे तुलनीय हैं। यह बहुत संभावना है क्योंकि यह bz2 डिकोडर की गति से बंधा है। रैटमाउंट लगभग 2 गुना धीमा है। मैं निकट भविष्य में bz2 डिकोडर को समानांतर करके स्पष्ट विजेता बनाने की उम्मीद करता हूं, जो कि मेरे 8 वर्षीय सिस्टम के लिए भी 4x स्पीडअप प्राप्त कर सकता है।
मेटाडेटा प्राप्त करने का समय
जब findटीएआर के साथ सभी फाइलों को सूचीबद्ध करते हैं (प्रत्येक फ़ाइल के लिए स्टेट कॉल करने के लिए भी लगता है!?), सभी परीक्षण किए गए मामलों के लिए रिटर्माउंट 10x धीमी है। मैं भविष्य में इस पर सुधार की उम्मीद करता हूं। लेकिन वर्तमान में, यह शुद्ध सी प्रोग्राम के बजाय पायथन और SQLite का उपयोग करने के कारण एक डिज़ाइन समस्या की तरह दिखता है।