क्या LTO टेप में अतिरिक्त / अप्रयुक्त क्षमता है?


13

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

हालाँकि मैंने देखा है कि जब आप एक टेप के अंत में जाते हैं, तो ड्राइव ऐसा लगता है कि यह अंतिम आवरण के माध्यम से लगभग आधा रास्ता है, और इसलिए यह ड्राइव टेप को खारिज करने से पहले कुछ समय बिताती है, भले ही यह रिपोर्ट किया हो। टेप का अंत हो गया है।

क्या ऐसा इसलिए है क्योंकि टेप पर कुछ आरक्षित क्षमता है, पुनर्लेखन में विफल ब्लॉक जैसी चीजों की अनुमति देने के लिए या अपनी क्षमता को कम किए बिना टेप के खराब वर्गों को छोड़ने के लिए? या इस टेप के स्पष्ट रूप से जल्दी खत्म होने का कोई और कारण है?

जवाबों:


13

यदि आपकी ड्राइव नई है और टेप अच्छी गुणवत्ता का है, तो आप आधिकारिक क्षमता की तुलना में टेप को अधिक बाइट्स लिखने में सक्षम होने की उम्मीद कर सकते हैं। कुछ अर्थों में आप उस अतिरिक्त क्षमता को कॉल कर सकते हैं, लेकिन यह अप्रयुक्त नहीं है।

जैसे-जैसे आपका ड्राइव हेड कम होता जाएगा, क्षमता कम होती जाएगी। यदि आप जोड़ते हैं कि महान गुणवत्ता के रूप में नहीं टेप के साथ क्षमता और भी कम हो सकती है।

क्योंकि क्षमता इस तरह बदलती है कि आपके बैकअप एप्लिकेशन को संकेत देने के लिए कुछ तरीका होना चाहिए जो आप क्षमता से बाहर हैं। यदि यह टेप के अंत तक पहुँच जाता है और इसे तैयार नहीं किया गया था तो यह बैकअप एप्लिकेशन के लिए समस्याग्रस्त हो सकता है। यह कुछ अग्रिम चेतावनी के साथ आवेदन के लिए बेहतर है कि यह शेष स्थान का उपयोग करने के लिए लपेट सकता है कि यह क्या कर रहा है।

यदि आपका ओएस लिनक्स होता है तो एपीआई ऐसा होता है कि टेप के अंतिम भाग तक पहुंचने के बाद हर दूसरी writeप्रणाली कॉल विफल हो जाएगी ENOSPC। यदि आपके बैकअप एप्लिकेशन को इस सुविधा के बारे में पता नहीं है तो यह ENOSPCअंत के रूप में पहला इलाज करेगा , और टेप पर कुछ अप्रयुक्त स्थान होगा।

मैं सोच सकता हूं कि ऐसा ही कुछ अन्य ओएस पर भी हो सकता है।


2

@Kasperd के लिए धन्यवाद मैंने कुछ और जांच की और यह वास्तव में समस्या थी। इस सुविधा को बदलकर EWEOM (मीडिया का आरंभिक चेतावनी अंत) कहा जाता है और यह टेप निर्माता द्वारा टेप पर रखे एक मार्कर को संदर्भित करता है, इसलिए यह ट्रैक नहीं रखता है कि कितना टेप स्पूल किया गया है।

मैंने उस mbufferप्रोग्राम के लिए एक पैच लिखा जिसे मैं टेप पर लिखने के लिए उपयोग कर रहा हूं, और निश्चित रूप से पर्याप्त है, उस बिंदु पर जहां मैं टेप के अंत तक पहुंच रहा था मुझे ENOSPCवैकल्पिक write()कॉल पर त्रुटियां मिलती हैं , लेकिन मैं और अधिक डेटा लिखना जारी रख सकता हूं। मेरे मामले में, बहुत अधिक डेटा - 8 और 19 GiB के बीच, मेरे नहीं-बहुत-संकुचित डेटा के संपीड़न पर निर्भर करता है।

दिलचस्प है कि ईडब्ल्यूओएम मार्कर पहुंचने के बाद, टेप राइट स्पीड नाटकीय रूप से कम हो जाती है। यह लगभग 80MB / सेकंड से लगभग 47MB / सेकंड तक कम हो जाता है। यह एक डेटा समस्या नहीं है क्योंकि ड्राइव ने इस बिंदु से पहले घंटे के लिए 80 एमबी / सेकंड बनाए रखा है। आप धीमी गति से चलने वाली ड्राइव मोटर को सुन सकते हैं, और एक पूरे टेप पर फिर से लिख सकते हैं ताकि यह खंड फिर से लिखा जाए, इससे गति में वृद्धि नहीं होती है (इसलिए यह पहले लिखने का मामला धीमा नहीं है जैसे कि यह एक शुरुआत में हो सकता है नया टेप।)

मुझे इस बारे में कोई दस्तावेज नहीं मिल सकता है कि टेप पर ईडब्ल्यूओएम मार्कर कब दिखना चाहिए, इसलिए यदि यह मानकीकृत है तो मुझे यकीन नहीं है। सभी मुझे मिल सकता है LTO-6/7 ड्राइव का एक अस्पष्ट संदर्भ है, जिससे यह टेप स्थान के 5% तक बढ़ गया है, जो बहुत कुछ लगता है। शायद यह टेप के उच्च लिखने की गति के कारण बड़े बफ़र्स को फ्लश करने की अनुमति देने के लिए है।

जहां तक ​​लिनक्स एपीआई जाता है, संबंधित लाइन st.c SCSI टेप ड्राइवर स्रोत कोड में है और इस व्यवहार की व्याख्या stड्राइवर प्रलेखन में है


यह सुनिश्चित करने के लिए कि जब यह भौतिक अंत तक पहुंचने से पहले पूरी तरह से बंद हो जाए, तो टेप धीमा हो जाता है।
Zac67

1
मुझे नहीं लगता कि एलटीओ टेप के साथ ऐसा ही है, अन्यथा उन्हें फिर से खोलना धीरे-धीरे आगे बढ़ेगा, लेकिन एक टेप को रीवाइंड करना पिछले कुछ सेकंड तक उच्च गति (लिखने के मुकाबले तेज) पर होता है। EWEOM मार्क के बाद ड्राइव कई मिनट के लिए धीमी हो जाती है। तो ड्राइव निश्चित रूप से जानता है कि यह धीमा होने की आवश्यकता के बिना टेप के भौतिक प्रारंभ / अंत के पास है। कम गति के लिए कुछ अन्य कारण होना चाहिए।
माल्विनस

मुझे लगता है कि टेप के सिरों को भी उनके तनाव के कारण संरक्षित किया जाना चाहिए, लेकिन यह शुद्ध अटकलें हैं।
Zac67

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

2
@ Zac67 यदि ड्राइव तक पहुँचने के पहले धीमे धीमे चलने के यांत्रिक कारण थे तो आप उम्मीद करेंगे कि हर रैप पर ऐसा हो और केवल अंतिम न हो।
kasperd
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.