Fsck 30 TB की मात्रा पर कितना समय ले सकती है?


17

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

मैं समझता हूं कि कुछ फ़ाइल सिस्टम के लिए fsck बहुत धीमा हो सकता है, लेकिन क्या यह संभव है कि fsck को 30 TB वॉल्यूम पर 6 महीने का समय लग जाए, या क्या मुझे यह मान लेना चाहिए कि यह होस्टिंग कंपनी मुझसे झूठ बोल रही है ताकि मैं अपने बिल का भुगतान करना जारी रखूँ महीना?


39
वे शायद शुरू से ही आपसे झूठ बोल रहे थे। मैं उम्मीद करूंगा कि घंटे लगेंगे । आपको दिसंबर में भुगतान करना बंद कर देना चाहिए था।
माइकल हैम्पटन

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

34
एक असली क्लस्टर fsck की तरह लगता है!
JMK

2
@ जेएमके अब मैं चाहता हूं कि अतिरिक्त योग्यता के लिए टिप्पणियों को ध्वजांकित करने का एक तरीका था, शायद एक हॉल-ऑफ-फेम में जोड़ें।
पाइप

2
@PeterCordes जो कहता है वह प्रमुख बिंदु है। आप एक सेवा के लिए भुगतान कर रहे हैं। आपको यह सुनकर खेद है कि उन्हें समस्याएँ हो रही हैं, लेकिन आप उस सेवा के बारे में कॉल कर रहे हैं जिसके लिए आप भुगतान कर रहे हैं और नहीं मिल रहा है।
रोब मोइर

जवाबों:


31

fsckगति मुख्य रूप से फाइलों की संख्या पर निर्भर करती है और वे संबंधित निर्देशिका में कैसे फैली हुई हैं। उस ने कहा, एक के लिए 6 महीने fsckबिल्कुल बेतुका है: इसे कुछ घंटों में पूरा करना चाहिए था, खासकर अगर इसका उपयोग xfsतेजी से xfs_repairउपयोगिता है। यहां आप कुछ fsckपैमाने पर दौड़ सकते हैं - सभी एक घंटे (3600) के तहत पूरा किया गया। तो, यह संभव नहीं है कि आपकेfsck अभी भी चल रहा है।

वैसे भी, एक अप्रत्याशित बिजली हानि एक पूर्ण-झटका का कारण नहीं होगी fsck, बल्कि केवल एक बहुत तेज (कुछ सेकंड) जर्नल रिप्ले । हालांकि, अगर कुछ प्रमुख फाइलें क्षतिग्रस्त हो गईं, तो ओएस अप्राप्य हो सकता है।

लेकिन वे शायद आपसे झूठ बोले। आपको तुरंत भुगतान करना बंद कर देना चाहिए, स्पष्टीकरण मांगना चाहिए और कुल धन वापसी के लिए आवेदन करना चाहिए।


8
यदि वे उपयोग कर रहे हैं ext2, तो एक बिजली की विफलता के लिए एक पूर्ण आवश्यकता होगी fsck, और मुझे आश्चर्य नहीं होगा यदि यह एक भारी-उपयोग वाले 30TB वॉल्यूम पर दिन लेता है। दूसरी ओर, यदि वे ext230TB की मात्रा का उपयोग कर रहे हैं, तो यह स्वयं में और होस्टिंग सेवाओं के लिए कहीं और देखने का एक कारण है।
मार्क

14
ext2 में 32-बिट ब्लॉक काउंटर का उपयोग किया गया है, जिसका अधिकतम ब्लॉक आकार 4096 बाइट्स (यानी: एक पृष्ठ) पर x86 और x863-64 पर है। इसका मतलब है कि ext2 (और ext3) 8TB संस्करणों तक सीमित है इसलिए नहीं, OP ext2 / 3 का उपयोग नहीं कर सकता है। वैसे भी, 30-टीबी वॉल्यूम पर किसी भी गैर-जर्नलेड फाइल सिस्टम का उपयोग करना बिल्कुल पागलपन होगा
शोडणशोक

मुझे लगता है कि ext4 fsck थोड़ा बेहतर हो सकता है यदि कोई 30Tb FS है जिसमें बड़ी संख्या में छोटी फाइलें हैं। बनाने के लिए Lunacy, इसलिए अभी भी कहीं और देखने का एक कारण है।
nigel222

7

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

एक खराब स्थिति आउटेज से ऐसी प्रणाली को पुनर्प्राप्त करने का मतलब यह हो सकता है कि आपको "धीमी" fsck / मरम्मत करनी होगी जो वास्तव में सभी फाइलसिस्टम संरचनाओं की जांच करती है जैसे कि वे हैं, जो वास्तव में 30TB के लिए एक या दो दिन ले सकता है .... और यह यह संभावना नहीं है कि आपको कई मरम्मत चक्र चलाने होंगे। इसमें जोड़ें कि कर्मियों को इस पर नज़र रखने के लिए हमेशा उपलब्ध नहीं होना चाहिए, आप आसानी से प्रति सप्ताह किए जा रहे एक fsck के नीचे हो सकते हैं। वे शायद हार मान गए और भूल गए।


1

अधिकांश फाइलसिस्टम के लिए, यह बहुत तेज होगा, यहां तक ​​कि जब त्रुटियां होती हैं, तो आमतौर पर केवल मेटाडेटा की जांच की जाती है।

सबसे खराब स्थिति में, यह पूरी डिस्क को पढ़ सकता है, ( जैसे कुछ ऐसा fsck.ext4 -cc /dev/sda, जो हर ब्लॉक पर एक गैर-विनाशकारी लेखन परीक्षण करता है), जो कि 30 टीबी के लिए कुछ दिन ले सकता है। यदि आप ड्राइव की गति जानते हैं, तो आप आकार / गति की गणना कर सकते हैं । लगभग 100 एमबी / एस के साथ एक उपभोक्ता हार्ड ड्राइव के लिए कुछ टीबी की नकल करने में ज्यादातर लोगों की अपेक्षा अधिक घंटे लग सकते हैं।

यदि यह आपका सर्वर था, तो आपको यह समस्या हो सकती है कि यह तब बूट करता है, जब fsckआपसे कोई त्रुटि ठीक करने के लिए कहता है, तो यह लटका रहता है । लेकिन डेटासेंटर एडमिन नहीं छोड़ेगाfsck सभी वीपीएस ऑफलाइन होने के 6 महीने के लिए फांसी ।

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


4
fsckसभी फाइल सिस्टम संरचनाओं का पता लगाता है, जिसका अर्थ है यादृच्छिक i / o निष्पादित करना। तो अनुक्रमिक हस्तांतरण दर के आधार पर उपरोक्त गणना बहुत उपयोगी नहीं है।
शोदनशोक

@shodanshok वास्तव में फ़ाइल संरचना एक सामान्य ड्राइव चेक में अप्रासंगिक है, जैसा कि मैंने अभी अपने उत्तर में बताया है।
Overmind

@shodanshok मेरी सबसे खराब स्थिति एक बहुत व्यापक fsck पर आधारित थी। उदाहरण के लिए सामान्य एक्सएफएस फेक बहुत कुछ नहीं करता है। ext2 में लंबे समय तक चलने वाला व्यापक चेक होता है और पुराने MS-DOS स्कैंडिस्क का प्रत्येक हार्ड ड्राइव ब्लॉक पर एक रीड-राइट टेस्ट होता है जब इसे पूर्ण मोड में चलाया जाता है। तो आपके पास डिस्क के आकार में एक ऊपरी बाध्य है।
allo

1
@ ऑवरमाइंड और आप का उत्तर उस प्रश्न के लिए अप्रासंगिक है जो fsck के बारे में है, न कि एक सामान्य ड्राइव चेक के बारे में।
ब्लैकजैक

कृपया ध्यान रखें कि एक संकेतक के रूप में विशिष्ट डिस्क थ्रूपुट लेना भ्रामक हो सकता है। मैंने गणित किया है जब एक बार एक सरणी को फिर से सिंक्रनाइज़ किया जा रहा है, जिसे (मेरी राय में) एक दिन से भी कम समय लिया जाना चाहिए, और इसमें दो सप्ताह लग गए! कांटे कुल समय के लिए एक हावी कारक हैं और यहां तक ​​कि जब आपको लगता है कि आप एक सख्त अनुक्रमिक ऑपरेशन कर रहे हैं, तो यह कभी-कभी एक नहीं होता है। अब fsck कड़ाई से गैर-अनुक्रमिक है, इसलिए ... आप सामान्य डिस्क थ्रूपुट से ऑपरेशन की लंबाई (फिर भी, महीनों हास्यास्पद है ... यह एक स्पष्ट झूठ है) का कोई रास्ता नहीं निकाल सकता है ।
डेमोन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.