क्या "डिवाइस पर कोई स्थान नहीं बचा है" के लिए कोई अन्य कारण है?

Question

मैं एक बाहरी USB 3.0 ड्राइव के लिए एक HD बैकअप के लिए Ubuntu सर्वर प्रणाली पर Dirvish का उपयोग कर रहा हूँ। कुछ दिनों पहले तक, सब कुछ ठीक काम करता था, लेकिन अब हर बैकअप "डिवाइस (28)" और "फाइल सिस्टम फुल" पर कोई स्थान नहीं बचा है। दुर्भाग्य से यह इतना आसान नहीं है: डिवाइस पर> 500 जीबी मुफ्त है।

विवरण:

rsync_error:

rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename1>.eDJiD9": No space left on device (28)
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename2>.RHuUAJ": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename3>.9tVK8Z": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename4>.t3ARSV": No space left on device (28)
[... some more files ...]
rsync: connection unexpectedly closed (2712185 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

जब तक यह हिट नहीं होता तब तक लॉग बहुत सामान्य दिखता है:

<SomeFilename1>
<SomeFilename2>
<SomeFilename3>
<SomeFilename4>
<PartOfAFilename>filesystem full
write error, filesystem probably full
broken pipe
RESULTS: warnings = 0, errors = 1

लेकिन, जैसा कि ऊपर कहा गया है, डिवाइस पर बहुत जगह है:

df -h
/dev/sdg1       2.7T  2.0T  623G  77% /mnt/backupsys/shd

और भी बहुत सारे इनोडे शेष हैं:

df -i
/dev/sdg1      183148544 2810146 180338398    2% /mnt/backupsys/shd

डिवाइस को आरडब्ल्यू के रूप में रखा गया है:

mount
/dev/sdg1 on /mnt/backupsys/shd type ext3 (rw)

प्रक्रिया जड़ के रूप में चल रही है।

मैं यह कहने वाला था कि मैंने कुछ भी नहीं बदला है, लेकिन यह बिल्कुल सच नहीं है: मैंने ड्राइव के लिए एसीएल पर स्विच किया है जो मैं वापस कर रहा हूं:

/dev/md0 on /mnt/md0 type ext4 (rw,acl)

क्या यह समस्या हो सकती है? यदि हाँ, तो कैसे? रूट में अभी भी फाइलों तक पूरी पहुंच है।

संपादित करें:

मैंने अभी-अभी अस्थायी निर्देशिकाओं की जाँच की है:

• / tmp में केवल .webmin फ़ोल्डर है जो खाली है
• / var / tmp खाली है

फ़ाइल सिस्टम जहाँ इन निर्देशिकाओं का निवास खाली स्थान और इनोड्स से भरपूर है:

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       289G   55G  220G  20% /

df -i
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
/dev/sda1       19202048  167644  19034404    1% /

EDIT2:

निर्देशिकाएं काफी बड़ी हैं, लेकिन> 2 जीबी नहीं। जहां बैकअप विफल रहता है, वह सबसे बड़ा भी नहीं है, इसमें 7530 फाइलें हैं।

EDIT3:

एक जानकारी जिसे मैंने इस प्रश्न को पोस्ट करते समय प्रासंगिक नहीं माना था:

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

आज एक खाली डिस्क का पूर्ण बैकअप त्रुटिपूर्ण रूप से काम करता है। मैं एक वृद्धिशील बैकअप की कोशिश करूँगा। यह दिखाएगा कि क्या एक्टीवेटिंग ऐक्सेस समस्या का कारण था।

Comments

संबंधित: stackoverflow.com/questions/24671621/no-space-left-on-device

— Ciro Santilli 新疆 .com/ .com/ .com/ 事件

Answer 1

मेरा संदेह (EDIT3 देखें) जाहिरा तौर पर सही था: फ़ाइल सिस्टम में acl समर्थन जोड़ना rsync / dirvish को लगता है कि सभी फाइलें बदल गई थीं। इसलिए एक वृद्धिशील बैकअप बनाने और केवल पहले से मौजूद फ़ाइलों के लिए कड़ी बनाने के बजाय, इसने एक पूर्ण बैकअप बनाने की कोशिश की, जो निश्चित रूप से विफल रहा क्योंकि हार्ड डिस्क में उसके लिए पर्याप्त जगह नहीं थी।

इसलिए त्रुटि संदेश वास्तव में सही था।

एक खाली बैकअप डिस्क के साथ फिर से शुरू करने के बाद, वृद्धिशील बैकअप ने पहले की तरह काम किया।

Answer 2

बचे हुए 2% इनोड्स को देखकर मुझे लगता है कि EXT फाइल सिस्टम लगाता है जो रूट रिजर्व के बारे में सोचते हैं। आप इनकी जांच कर सकते हैं:

1. " एक फाइल सिस्टम पर रूट के लिए आरक्षित स्थान - क्यों? "
2. " गैर-ओएस डिस्क के लिए" फाइल सिस्टम आरक्षित ब्लॉक "का उचित आकार? "

मैं .tar.gz कुछ पुराने बैकअप की उम्मीद करूँगा कि यह उपयोग में इनोड की संख्या को कम करेगा।

Comments

dfआउटपुट के पहले-अंतिम कॉलम में उपयोग किए गए इनोड्स का प्रतिशत है, इसलिए 2% इनोड का उपयोग किया जाता है, और 98% बचे हैं।

— देवर

Answer 3

मैं देख रहा हूं कि डमज़ेउच उसकी समस्या का हल ढूंढता है, लेकिन वास्तव में एक और मामला है जिसमें मैंने पाया कि डिस्क में पर्याप्त इनोडेस / खाली स्थान हो सकता है और फिर भी कुछ निर्देशिकाओं को स्थानांतरित करने का प्रयास करते हुए "डिवाइस पर कोई स्थान नहीं छोड़ा"।

यह ext4 फ़ाइल सिस्टम के साथ स्वरूपित ब्लॉक डिवाइसेस पर हैश टकराव के कारण होता है जहाँ निर्देशिका अनुक्रमण को विशेष रूप से सक्षम किया जाता है जहाँ एकल निर्देशिका इसमें 100k से अधिक फ़ाइलों को होस्ट करती है और फ़ाइलों का नाम समान एल्गोरिथ्म (कैश फ़ाइलें, md5xum फ़ाइल नाम आदि) से उत्पन्न होता है। ।)

समाधान एक और निर्देशिका अनुक्रमण एल्गोरिथ्म के साथ प्रयास करने के लिए है:

tune2fs -E "hash_alg=tea" /dev/blockdev_name

या उस ब्लॉक डिवाइस के लिए पूरी तरह से निर्देशिका अनुक्रमण को अक्षम करने के लिए (प्रदर्शन को नुकसान पहुंचा सकता है)

tune2fs -O ^dir_index /dev/blockdev_name

एक अन्य समाधान यह देखना है कि निर्देशिका को ऐसी फ़ाइलों के साथ क्या भरना है और सॉफ़्टवेयर को ठीक करना है।

संभावित समाधान फ़ोल्डर की सामग्री को कई अलग-अलग सबफ़ोल्डर में फ़ाइलों की विशाल मात्रा के साथ विभाजित करता है।

समस्या का पूरा विवरण एक्सल वैगनर द्वारा यहां प्रस्तुत किया गया है

http://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

चीयर्स।

Answer 4

निर्देशिका पर ही 2GB आकार सीमा है - यानी यदि आपके पास इतनी फ़ाइलें हैं कि निर्देशिका का आकार> 2GB (निर्देशिका में फ़ाइलों का आकार नहीं है), तो आपके पास एक समस्या होगी। कहा जा रहा है कि, केवल 2.8M इनकोड का उपयोग किया है, जो एक मुद्दा नहीं होना चाहिए। आमतौर पर 15M इनोड के आसपास होता है।

तो यह बहुत मदद नहीं हो सकता है - लेकिन अपने बैकअप डिवाइस पर ext4 का प्रयास करें?

Comments

निर्देशिकाएं इतनी बड़ी नहीं हैं। बीज का संपादन।

— dummzeuch

आपके संपादन निर्देशिकाओं का वास्तविक आकार नहीं दिखाते हैं। इसे आज़माएँ: find /mnt/backupsys/shd -type d -exec ls -ld {} \;निर्देशिकाओं के वास्तविक आकार को देखने के लिए।

— जेनी डी

Answer 5

Sysctl में अपनी Inotify वॉचर्स सीमा बढ़ाएँ:

fs.inotify.max_user_watches = 100000 

और रिबूट, या उस के sysctl -wसंस्करण भी करते हैं।

वह आमतौर पर करूँगा। कुछ में कर्नेल में बहुत सी फाइलें खुली हैं, और त्रुटि पूरी तरह से भ्रामक है। ड्रॉपबॉक्स इसका एक उत्कृष्ट उदाहरण है।

Comments

आप सही कह रहे होंगे। दुर्भाग्य से मैंने आपके सुझाव को पढ़ने से पहले ही कर्नेल अपडेट के कारण कंप्यूटर को पहले ही रिबूट कर दिया था। बाद में मैंने बैकअप शुरू किया और यह अभी भी खुशी से चल रहा है। मैं देखूंगा कि क्या यह पूरा होता है और अगले शेड्यूल के साथ भी होता है।

— dummzeuch

यह एक समस्या है जो मुझे दिखाई दे रही थी - मेरे पास ड्रॉपबॉक्स है और "इन स्पेस नहीं डिवाइस" संदेश के साथ विफल हो जाएगा।

— स्टीव

Answer 6

मैं आपको कुछ अन्य चीजों की जांच करने का सुझाव दूंगा:

1. देखें कि क्या आपका अस्थायी डायर पूरा नहीं भर पा रहा है। कभी-कभी इसका उपयोग मध्यवर्ती भंडारण के लिए किया जाता है और यह आसानी से पूर्ण हो जाता है।
2. जांचें कि क्या कोई ऐसी प्रक्रिया है जो अभी भी हटाए गए फ़ाइल के लिए एक डिस्क्रिप्टर को पकड़े हुए है। संभावना कम है क्योंकि df उचित आकार की रिपोर्ट करता है लेकिन फिर भी यह चोट नहीं पहुंचाएगा।

Comments

जाँच / tmp और / var / tmp। संपादन देखें।

— dummzeuch

कोटा (उपयोगकर्ता सीमा) भी देखें। सुनिश्चित नहीं हैं कि आप स्थानीय बैकअप के लिए rsync का उपयोग क्यों कर रहे हैं, हालांकि। : ~ /

— डेनिस

Answer 7

मैंने अपनी समस्या का हल खोजते हुए बस इस विषय को पाया।

वास्तव में ENOSPC के लिए कम से कम अन्य कारण है। और मैं इसे rsync के साथ भी शौकीन हूं, जबकि एक ZFS फाइल सिस्टम से एक EXT4 में कॉपी करता हूं:

rsync: rsync_xal_set: lsetxattr(""/my/file/path"","example.xattr.attribute") failed: No space left on device (28)

इस मामले में:

   ENOSPC - There is insufficient space remaining to store the extended attribute.

man 7 xattr बताते हैं:

   In the current ext2, ext3, and ext4 filesystem implementations, the total bytes used by the names and values of all of a file's extended attributes
   must fit in a single filesystem block (1024, 2048 or 4096 bytes, depending on the block size specified when the filesystem was created).

मेरे मामले में, इसका मतलब है कि मुझे पूरी फाइल प्रणाली को सुधारना होगा। :-(