क्या उबंटू यूएसबी ड्राइव को नुकसान पहुंचाता है?

74

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

(इस स्क्रीनशॉट में ऐसा ही संदेश)

विंडोज़ के साथ काम करने वाले 10+ वर्षों के लिए मेरे पास कभी भी एक भ्रष्ट या क्षतिग्रस्त यूएसबी ड्राइव नहीं था, लेकिन पिछले दो वर्षों के दौरान मेरे तीन यूएसबी ड्राइव निष्क्रिय हो गए, इसलिए मैं इसे साबित नहीं कर सकता, लेकिन यह स्पष्ट है कि यह उबंटू (संयुक्त राष्ट्र) के माउंट व्यवहार से संबंधित है ।

एक मित्र ने मुझे बताया कि मैं udisks और सिंक का उपयोग करके इस तरह की क्षति को रोक सकता हूं, लेकिन मुझे उम्मीद है कि यह ऐसा करने का तरीका नहीं है, 2016 में शेल कमांड के साथ बढ़ते ड्राइव।

— jan6352781
स्रोत

1

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

— अरीफ्ल

2

विश्वास न करें कि जब लोग आपको बताएंगे कि लिनक्स आपके ड्राइव को दूषित नहीं करेगा। यह। उबंटू 15 पर, केवल रिबूट द्वारा पीछा की गई फ़ाइल की प्रतिलिपि ने मुझे इस तरह chkdsk में त्रुटियां दीं:

Stage 2: Examining file name linkage ...     Found corrupt basic file structure for "<0x32,0x1e63>"         ... queued for offline repair.     Found an unneeded link ($FILE_NAME: ???) in index "$I30" of directory "\ <0x5,0x5>"         ... queued for offline repair.     Found missing Index entry for file "<0x32,0x1e63>" from index "\??\D:\found.000" of directory "$I30"         ... queued for offline repair.

— मेहरदाद

1

^ ... उल्लेख करने के लिए नहीं, यह फ्लैश ड्राइव पर भी नहीं था, यह मेरे मुख्य एसएसडी पर था। एक नया एसएसडी। और यह हर बार हुआ कि मैंने फ़ाइल कॉपी के बाद एक टन अतिरिक्त I / O नहीं जोड़ा। दूसरे शब्दों में, NTFS के लिनक्स के कार्यान्वयन है टूट, जितना अपने प्रशंसकों इससे इंकार और विश्वास से बचने के लिए चाहते हैं।

— मेहरदाद

12

यह एक NTFS फाइलसिस्टम है? FAT32? क्या आप इसे मज़बूती से पुन: पेश कर सकते हैं?

— ब्रायन

2

शेल कमांड के साथ बढ़ते ड्राइव के साथ इतना बुरा क्या है ? ¯＼(o_o)/¯

— ulidtko

104

कोई चिंता नहीं उबंटू ने आपके यूएसबी ड्राइव को नुकसान नहीं पहुंचाया। लेकिन हम एक FAT32, FAT16, या NTFS फाइल सिस्टम के खराब दस्तावेज वाले झंडे का उपयोग नहीं करते हैं। विंडोज पर ये झंडे संभवत: दूषित फाइलसिस्टम को इंगित करते हैं जब हमने ड्राइव को ठीक से अनमाउंट नहीं किया था या I / O त्रुटि उत्पन्न हुई थी।

वे बिट्स FAT विभाजन तालिका की आरक्षित प्रविष्टि में स्थित हैं। 2004 के एक आंतरिक Microsoft पेपर के अनुसार इन बिट्स का उद्देश्य है:

ClnShutBitMask:
यदि बिट 1 है, तो वॉल्यूम "साफ" है। पहुंच के लिए वॉल्यूम बढ़ सकता है। यदि बिट 0 है, तो वॉल्यूम "गंदा" है जो दर्शाता है कि एक एफएटी फाइल सिस्टम ड्राइवर वॉल्यूम को ठीक से हटाने में असमर्थ था (एक पूर्व माउंट ऑपरेशन के दौरान)। फ़ाइल सामग्री मेटाडेटा को किसी भी क्षति के लिए वॉल्यूम सामग्री को स्कैन किया जाना चाहिए।

HrdErrBitMask:
यदि यह बिट 1 है, तो कोई डिस्क रीड / राइट त्रुटियों का सामना नहीं किया गया था। यदि यह बिट 0 है, तो फ़ाइल सिस्टम ड्रायवर कार्यान्वयन को पिछली बार माउंट किए गए वॉल्यूम पर डिस्क I / O त्रुटि का सामना करना पड़ा, जो एक संकेतक है कि कुछ सेक्टर खराब हो सकते हैं। वॉल्यूम सामग्री को डिस्क मरम्मत उपयोगिता के साथ स्कैन किया जाना चाहिए जो नए बुरे क्षेत्रों की तलाश में इस पर सतह विश्लेषण करता है।

इस पर काबू पाने के बारे में कुछ साल पहले कर्नेल फ़ाइल सिस्टम डेवलपर्स के साथ कुछ चर्चा हुई थी लेकिन मैं परिणामों का पालन करने में असमर्थ था। जाहिरा तौर पर यह हाल के गुठली में नहीं बना।

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

— Takkat
स्रोत

3

जब मैंने वास्तव में सुरक्षित रूप से ड्राइव को अनमाउंट किया है, तो क्या मुझे इन ड्राइवों में ये त्रुटियां नहीं हुई हैं - क्या आपको यकीन है कि इन बिट्स के लिए समर्थन गायब है?

— थॉमस वार्ड

5

@ThomasW। ये बिट्स काफी अस्पष्ट हैं, लेकिन मुझे कभी-कभी अपने कार्यस्थल विंडोज 7 पर अपने उबंटू-स्वरूपित यूएसबी ड्राइव के साथ ये त्रुटियां होती हैं। अब तक मैंने कोई उपयोगी पैटर्न नहीं देखा है। केवल एक चीज मैं कह सकता हूं कि मैं ड्राइव को हमेशा ठीक से अनमाउंट / इजेक्ट करता हूं। परीक्षण आसान नहीं है क्योंकि घर पर कोई विंडोज नहीं है, काम पर कोई उबंटू नहीं है।

— ताकत

शीर्षक गलत है।

— मत्तीरॉक

@ मैथ्यू रॉक: बेहतर?

— तकक

हाँ, यह बेहतर है।

— मैथ्यूॉक

74

यह ज्यादातर विंडोज के साथ एक मुद्दा है। यह सोचता है कि यह दुनिया का एकमात्र ओएस है और अगर यह कुछ समझ पाता है तो यह कार्य करता है।

सिर्फ इसलिए कि विंडोज कहता है कि आपको ड्राइव की मरम्मत करनी चाहिए यह सच नहीं है।

उबंटू के साथ उपयोग किए गए मेरे किसी भी ड्राइव को विंडोज से यह संदेश मिलता है, मैं बस कहता हूं noऔर वे विंडोज के साथ ठीक काम करते हैं।

संक्षेप में, ड्राइव में कुछ भी गलत नहीं है, यह सिर्फ वहाँ पर कुछ है जो विंडोज़ को समझ में नहीं आता है और इसकी प्रतिक्रिया इसे नष्ट कर रही है।

repairड्राइव मत करो , यह आपको बताए बिना इसे प्रारूपित करेगा और आप ड्राइव पर सभी डेटा खो देंगे।

— मार्क किर्बी
स्रोत

40

1. मरम्मत प्रारूप नहीं करता है, मरम्मत एक फ़ोल्डर में आवंटित डेटा को बचाता है। मेरे लिए ऐसा लगता है जैसे उबंटू लेखन प्रक्रिया को ठीक से पूरा नहीं करता है।

— Jan6352781

10

2. अधिकांश USB ड्राइव FAT32 स्वरूपित होते हैं, जिसे Microsoft द्वारा विकसित किया गया था, इसलिए विंडोज को "somethin" न समझने की एकमात्र प्रणाली क्यों होनी चाहिए ??

— Jan6352781

17

-1 क्योंकि यह निराधार और गलत है। मैंने Ubuntu 15 भ्रष्ट मेरे NTFS वॉल्यूम को देखा है (हाँ, मुझे पता है कि आप मुझ पर विश्वास नहीं करेंगे, लेकिन मैंने इसे अपनी आँखों से देखा है और खुद पर विश्वास करने से पहले इसे लगातार 3-4 बार दोहराया है), और यह मेरे सभी बफ़र्स को स्पष्ट रूप से सिंक करने के बावजूद भी हुआ है। मैं @ jn6352781 के साथ सहमत हूं कि मुझे यह भी संदेह था कि यह लिखने की प्रक्रिया को पूरा नहीं करने के कारण था, और मैं अभी भी करता हूं। वास्तव में, यदि आप उबंटू को रिबूट करने से पहले लिखने के बाद लंबे समय तक प्रतीक्षा करते हैं, तो यह ठीक काम करता है। हमारे पास यह मानने का कोई कारण नहीं है कि विंडोज यहां गलती पर है, और हर कारण उबंटू को मानना है।

— मेहरदाद

7

ड्राइव को रिपेयर करना इसका प्रारूप नहीं है। यह चॉक चलाता है। यह डिस्क की तुलना में डिस्क को और अधिक फॉरमेट नहीं करता है।

— जर्नीमैन गीक

16

यह संपूर्ण उत्तर केवल शून्य प्रमाण (उपाख्यान को छोड़कर) के साथ एक विंडोज शेख़ी है।

— मिल्ली स्मिथ

18

जैसा कि आपने एक टिप्पणी में सुझाव दिया है, यह संभवतः फ्लैश ड्राइव को हटाने से पहले उबंटू लिखने की प्रक्रिया को पूरा करने से संबंधित नहीं है। उबंटू नकल की प्रक्रिया के दौरान रैम को फाइलें लिखता है, और इन फाइलों को बफर से यूएसबी ड्राइव पर कॉपी डायलॉग बंद होने के बाद बैकग्राउंड में लिखता है। नहीं है एक और उत्तरयह सुझाव देता है कि यह विशेष रूप से बड़ी मात्रा में मेमोरी वाले मशीनों के लिए एक समस्या है, लेकिन यह संभावना है कि आप पृष्ठभूमि लेखन पूरा होने से पहले ड्राइव को हटा रहे हैं। जब आप एक ड्राइव को अस्वीकार करते हैं, तो यह बफर को डिस्क पर लिखने के लिए मजबूर करता है, लेकिन यह बताना मुश्किल है कि लेखन वास्तव में कब पूरा होता है। इस उपाय को करने के लिए नए संस्करणों (15.10 के लिए कुछ, संभवतः 15.04) में एक पॉप-अप है - एक बैंगनी चेतावनी कुछ (आम तौर पर कम) समय के बाद दिखाई देती है जो "[ड्राइव] की तर्ज पर कुछ कहती है, अब एक बार" हटाया जा सकता है लेखन समाप्त हो गया है।

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

— alex_d
स्रोत

जब भी मैं USB ड्राइव को अस्वीकार करता हूं, मुझे 14.04 (लिनक्स मिंट केडीई संस्करण) में पॉपअप मिलता है, और मेरी 15.10 कुबंटू मशीनें भी। 15.04 के बारे में निश्चित नहीं है, लेकिन मैं ऐसा मानूंगा।

— जॉन बेंटले

1

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

— इजाकाता

1

@Izkata वेनिला उबंटू 14.04 पर, जब आप Nautilus में बेदखल प्रतीक पर क्लिक करते हैं तो यह तुरंत गायब हो जाता है। आंतरिक ड्राइव के विपरीत, हालांकि, USB ड्राइव पूरी तरह से अनमाउंट होने के बाद साइडबार से गायब हो जाते हैं (यानी लिखना समाप्त हो जाता है), इसलिए कुछ समय ऐसा होता है, जिसके दौरान USB ड्राइव लिखा जा रहा है, लेकिन बेदखल हो जाता है।

— एलेक्स_ड

5

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

यदि यह एक हार्डवेयर समस्या थी, तो ext3 (या 4) के साथ विभाजन को प्रारूपित करने में मदद नहीं करनी चाहिए, लेकिन ext3 / 4 फाइल सिस्टम को वास्तव में बुलेटप्रूफ बनाता है। (ext2 भी कुछ महीनों में भ्रष्ट हो गया था, मैंने इसे आज़माया था; फ्लैश ड्राइव के लिए इतना लंबा जीवन कम लिखना चाहिए था, मुख्यतः किसी पत्रिका से नहीं)।

इसलिए, उबंटू को शारीरिक रूप से यूएसबी ड्राइव को नुकसान नहीं पहुंचाना चाहिए , लेकिन मुझे अभी भी 100% FAT फाइल सिस्टम के साथ भरोसा नहीं है।

मुझे लगता है कि फाइल सिस्टम भ्रष्टाचार से सबसे अच्छा बचा जा सकता है:

कभी भी USB ड्राइव को अनप्लग न करें जब तक कि वह अनमाउंट / umount/ बेदखल न हो जाए। यहां तक कि अगर ड्राइव वर्तमान में कुछ भी नहीं लिख रहा है (यदि इसमें रोशनी है तो यह चमकती नहीं है) और यहां तक कि अगर आपने किया है syncतो फाइल सिस्टम हो सकता है
umountअनप्लग करने से पहले कम से कम कुछ सेकंड रुकें / बाहर निकालें। ऐसा लगता है कि umountड्राइव की गतिविधि के बाद भी प्रकाश कभी-कभी थोड़ी देर तक चमकता रहता है। इस उपयोगकर्ता के अन्य उपयोगकर्ता कहते हैं कि यह एक मिनट तक चल सकता है।
केवल उस व्यक्ति पर ही निर्भर न रहें sync, जैसे इस व्यक्ति को फ़ाइल भ्रष्टाचार मिला।

संबंधित (आम तौर पर) लिंक:

— Xen2050
स्रोत

3

यह किसी भी ऑपरेटिंग सिस्टम के साथ बहुत कम है। यह एक फ़ाइल सिस्टम त्रुटि है, जो ज्यादातर मामलों में इंगित करता है कि ड्राइव ठीक से अनमाउंट नहीं किया गया था (उपयोगकर्ता त्रुटि)। यह क्षति का पूर्ण संकेत नहीं है, यह केवल क्षति की संभावना को इंगित करता है। यदि मौजूद है, तो नुकसान आमतौर पर अंतिम लिखित फ़ाइल (नों) तक सीमित होता है। इस मामले में विंडोज "मरम्मत" कमांड "कब्जा" के रूप में चिह्नित क्षेत्रों के लिए ड्राइव को स्कैन करता है, लेकिन किसी भी फाइल को नहीं सौंपा गया है और फिर इस स्क्रैप और टुकड़ों को नई फाइलों को असाइन करता है।

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

इस संदेश को देखने का मतलब है कि ड्राइव ठीक से अनमाउंट नहीं था।

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

— Agent_L
स्रोत

2

मैं दोहरे बूट के साथ कई वर्षों के ubuntu और खिड़कियों का उपयोग करता हूं, और जब मैं ड्राइव को सही तरीके से अनमाउंट करता हूं, तो खिड़कियों में हमेशा त्रुटि संदेश दिखाई देता है, लेकिन कभी भी मेरी यूएसबी ड्राइव पर त्रुटि नहीं थी। W10 में आप इस पॉप-अप त्रुटि संदेश को बंद कर सकते हैं।

— tviragh
स्रोत

1

किसी भी ओएस के लिए लगभग कोई रास्ता नहीं है यूएसबी ड्राइव को नुकसान पहुंचा सकता है, एक सामान्य प्रारूप (त्वरित नहीं) के बाद, कोई निशान नहीं छोड़ा जाना चाहिए कि ड्राइव कभी उबंटू के साथ उपयोग किया गया था।

"H2testw" या "USB फ्लैश ड्राइव परीक्षक" के साथ ड्राइव की जांच करें - खराब क्षेत्र कई अजीब त्रुटियों का स्रोत हो सकते हैं।

— user158037
स्रोत

4

ओपी को बुरी तरह से शब्द दिया गया है, लेकिन इसका अर्थ है "फ़ाइल सिस्टम", न कि "फ्लैश रोम"।

— wizzwizz4

ऐसा प्रतीत होता है कि ओपी का मतलब वास्तविक यूएसबी ड्राइव क्षति हो सकता है , वे कहते हैं "मेरे पास कभी भी एक भ्रष्ट या क्षतिग्रस्त यूएसबी ड्राइव नहीं था, लेकिन पिछले दो वर्षों के दौरान मेरे यूएसबी ड्राइव में से तीन निष्क्रिय हो गए " यदि उनका मतलब सिर्फ भ्रष्ट होता है तो वे शायद भ्रष्ट हो जाते, इसके बजाय "निष्क्रिय" @ wizzwizz4

— Xen2050

3

@ Xen2050 फिर भी सभी अन्य जवाब, और टिप्पणियाँ धागे सहित jan6352781, या राज्य, फ़ाइल सिस्टम समस्या है, और "टूटी हुई डिवाइस" उनमें से एक एक्सट्रपलेशन है जो ठीक से काम नहीं कर रहा है।

— wizzwizz4

@ wizzwizz4 ठीक है, मार्क किर्बी के जवाब में, ओपी टिप्पणी करता है "3. पिछले साल मैंने क्षतिग्रस्त फ़ाइलों और यूएसबी ड्राइव के साथ समाप्त होने वाले लगभग हर दिन मरम्मत को छोड़ दिया था ।" मैं अनुमान लगा रहा हूं कि यह पुरानी ड्राइव से बस है जो विफल हो गई होगी, खिड़कियां। या नहीं, लेकिन वे अभी भी ओपी ने कहा

— Xen2050

@ Xen2050 या शायद ओपी पुराने संदेश का उल्लेख कर रहा था "डिवाइस क्षतिग्रस्त है। क्या आप चाहते हैं कि विंडोज इसे ठीक करे?" (paraphrased) जो कभी-कभी आता है जब एक अलग dll मुद्दे को संभालता है। (मैंने पाया है कि यह स्वयं प्रकट होता है, हालांकि मुझे यकीन नहीं है कि अंतिम वाक्य सही है।)

— wizzwizz4

1

अगर ड्राइव "क्षतिग्रस्त" था, तो मैं नहीं कह सकता कि शायद यह था और शायद यह नहीं था। लेकिन जैसा कि कोई कह सकता है कि: "विंडोज़ के साथ काम करने वाले 10+ वर्ष ...", मैं आपको बता सकता हूं कि यदि आप विंडोज 10 चला रहे हैं तो यह आपकी नई समस्याओं का स्रोत हो सकता है। मैं 10 को अपने पहले दिन एक नई समस्या में भाग गया: 10 में 10 बाहरी ड्राइव के लिए एक डेटाबेस बनाया गया है (यह अनुक्रमण डेटाबेस हो सकता है, मुझे याद नहीं है)। यदि वह डेटाबेस ड्राइव से मेल नहीं खाता है, तो यह आपको बताएगा कि आपका ड्राइव क्षतिग्रस्त है, कभी-कभी आप इस चेतावनी को अनदेखा कर सकते हैं और कभी-कभी आप (किस्सा नहीं देख सकते हैं)। "मरम्मत" चलाने से डेटाबेस ठीक हो जाएगा।

किस्सा:

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

दौड़ना syncभी बुरा विचार नहीं है।

— काली
स्रोत