Gnome, nautilus USB पर फ़ाइलों की प्रतिलिपि 100% या उसके पास बंद कर देता है


29

मेरे पास पहले भी इसी तरह के मुद्दे थे लेकिन मुझे याद नहीं है कि मैंने इसे कैसे हल किया।

जब मैं FAT के साथ USB स्टिक में कुछ कॉपी करने की कोशिश करता हूं, तो यह अंत में कभी-कभी 100% पर बंद हो जाता है। और हां, जब मैं मेमोरी स्टिक को कहीं और स्थानांतरित करता हूं, तो इसमें पूरी फाइल नहीं होती है। (फ़ाइल एक फिल्म है!)

मैंने माउंट-फ्लश के साथ डिवाइस को माउंट करने की कोशिश की, लेकिन मुझे एक ही मुद्दा मिलता है।

इसके अलावा, मैंने नए FAT विभाजन के साथ USB स्टिक को प्रारूपित किया ...

किसी भी विचार क्या मैं ठंडा करूँ?

पीएस मेरा मानना ​​है कि यह ओएस से संबंधित नहीं है, जो डेबियन है, और मेरा मानना ​​है कि एसएसडी ड्राइव से मुकाबला करने से यह अटक नहीं जाता है।


3
कहीं मैं इस मामले की व्याख्या के बाद मिला हूँ। मामले में ऑपरेटिंग मेमोरी के माध्यम से प्रतिलिपि बनाई गई थी, और आईडीलेटर ड्राइव से डेटा पढ़ने की प्रक्रिया को दर्शाता है। लेकिन विशेष रूप से यूएसबी-स्टिक के लिए राइटिंग की प्रक्रिया बहुत लंबी है (यह धीरे-धीरे 100 गुना हो सकती है: जैसे 2Mb / सेकंड राइटिंग 200Mb / उदाहरण के लिए पढ़ने की सेकंड) और अधिक यदि आप लिनक्स के तहत FAT या NTFS जैसी नो-देशी फ़ाइल सिस्टम का उपयोग करते हैं तो अधिक । इसलिए 100% पर रोक दिए जाने पर भी अंतिम लेन-देन की प्रतीक्षा करें, लेकिन बंद नहीं होना चाहिए (जो कि समाप्ति का संकेत देना चाहिए)।
कोस्टास

बस सोच रहा था कि क्या उस स्थिति में प्रगति की जांच करना संभव है ???

शून्य के साथ डेटा से बाहर निकलने के विकल्प को अधिलेखित करने के साथ pendrive को प्रारूपित करने का प्रयास करें। यह मेरे ट्रांसड्यूस 8GB पेंड्राइव पर काम करता है
अक्षय

इस मुद्दे पर आने वाले किसी के लिए, बस अपनी ड्राइव को NTFS में फ़ॉर्मेट करें।
रिकी बॉयस

जवाबों:


37

ऐसा होने का कारण यह है कि कार्यक्रम "डेटा लिखता है" कहता है और लिनक्स कर्नेल इसे एक मेमोरी बफर में कॉपी करता है जो डिस्क पर जाने के लिए कतारबद्ध है, और फिर "ठीक है, किया" कहता है। इसलिए प्रोग्राम को लगता है कि उसने सब कुछ कॉपी कर लिया है। फिर प्रोग्राम फ़ाइल को बंद कर देता है, लेकिन अचानक कर्नेल इसे प्रतीक्षा करता है जबकि बफर को डिस्क से बाहर धकेल दिया जाता है।

इसलिए, दुर्भाग्य से कार्यक्रम आपको यह नहीं बता सकता है कि बफर को फ्लश करने में कितना समय लगेगा क्योंकि यह नहीं जानता है।

यदि आप कुछ पॉवर-यूजर ट्रिक आजमाना चाहते हैं, तो आप लिनक्स के कर्नेल पैरामीटर vm.dirty_bytesको सेट करके बफर के आकार को कम कर सकते हैं जैसे 15000000(15 एमबी)। इसका अर्थ है कि एप्लिकेशन अपनी वास्तविक प्रगति के आगे 15MB से अधिक नहीं प्राप्त कर सकता है। (आप के साथ उड़ने पर कर्नेल मापदंडों को बदल सकते हैं, sudo sysctl vm.dirty_bytes=15000000लेकिन उन्हें रिबूट के पार रहने के लिए एक कॉन्फ़िगर फ़ाइल को बदलने की आवश्यकता होती है जैसे /etc/sysctl.confकि आपके डिस्ट्रो के लिए विशिष्ट हो सकती है।)

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

लेकिन, इसे बहुत छोटा न रखें! मैं एक मोटे अनुमान के रूप में 15 एमबी का उपयोग करता हूं कि कर्नेल बफर को एक सामान्य हार्ड ड्राइव में 1/4 या उससे कम में फ्लश कर सकता है। यह "लैगी" महसूस करने से मेरी प्रणाली को बनाए रखता है।


मैं एक साल या उससे अधिक समय से इस समस्या को ठीक करने के लिए देख रहा था, मुझे लगा कि यह सिर्फ लिनक्स में एक बग था। बहुत बहुत धन्यवाद।
सिद्धहैम

1
यहां लिनक्स नोब, क्या कोई व्यक्ति पोस्ट कर सकता है कि <गंदे_बाइट्स> मान कैसे बदलें?
ब्रोफोर

@ ब्रेफ़िकेटर ओह, क्षमा करें, मुझे इसे आधिकारिक नाम से / खरीद विवरण के बजाय वर्णित करना चाहिए था। उत्तर अपडेट किया गया है।
रात १२:२४

1
यह unix.stackexchange.com/questions/107703/… --- के समान है , तय किया जाना चाहिए था, लेकिन मेरा विश्वास करो, यह नहीं है। मुझे अजीब व्यवहार करने से रोकने के लिए इसे उबंटू 18.04 में जोड़ना पड़ा ...
रमनो

फेडोरा 30 पर भी काम करता है। मैं आधुनिक लिनक्स डिस्ट्रोस में भी इस तरह के मूर्ख व्यवहार को देखकर आश्चर्यचकित हूं।
सजीरकुई

0

पुराना सवाल है, लेकिन ऐसा लगता है कि समस्या अभी भी आ रही है। बफ़र को 15MB पर सेट करने का सुझाव दिया गया है क्योंकि यहाँ उबंटू 19.04 पर काम नहीं किया गया था, और मेरे सिस्टम को पीसने के लिए लाया गया।

मैं एक खाली (नए स्वरूपित) FAT32 16GB ड्राइव पर 1.5GB फ़ाइल को कॉपी करने की कोशिश कर रहा था। मैंने इसे लगभग 10 मिनट तक चलने दिया, यह देखने के लिए कि क्या यह खत्म होगा, बिना किसी भाग्य के।

NTFS को रिफ़ॉर्मेट करते हुए ऑपरेशन को 10 सेकंड से कम समय में खत्म करने दें। मुझे नहीं पता कि यह क्यों मायने रखेगा क्योंकि FAT32 को 2GB के तहत कुछ भी अनुमति देनी चाहिए, लेकिन यह ठीक काम करने के लिए लग रहा था। MacOS के साथ आप जिस ड्राइव का उपयोग करना चाहते हैं, उसके लिए एक आदर्श फिक्स नहीं है, लेकिन अन्य सभी उपयोग मामलों के लिए एक आसान समाधान है। मुझे लगता है कि एक्सफ़ैट ने इसी तरह काम किया होगा, लेकिन मैंने इसका परीक्षण नहीं किया।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.