जब डिवाइस में बहुत अधिक स्थान हो, तो mv के दौरान आंतरायिक "डिवाइस पर कोई जगह नहीं छोड़ी गई" त्रुटियों को कैसे ठीक करें?

21
  • एक डेस्कटॉप पर Ubuntu 14.04
  • सोर्स ड्राइव: / dev / sda1: 5TB ext4 सिंगल
    ड्राइव वॉल्यूम
  • टारगेट वॉल्यूम: / dev / mapper / आर्काइव-लवर्चिव: raid6 (mdadm) 18TB वॉल्यूम के साथ lvm
    पार्टीशन और ext4

स्थानांतरित करने के लिए लगभग 15 मिलियन फाइलें हैं, और कुछ डुप्लिकेट हो सकते हैं (मैं डुप्लिकेट को अधिलेखित नहीं करना चाहता)।

कमांड (स्रोत निर्देशिका से) का उपयोग किया गया था: 

ls -U |xargs -i -t mv -n {} /mnt/archive/targetDir/{}

यह उम्मीद के अनुसार कुछ दिनों से चल रहा है, लेकिन मुझे आवृत्ति बढ़ाने में त्रुटि हो रही है। जब इसने टारगेट ड्राइव शुरू किया तो यह लगभग 70% भरा था, अब इसका लगभग 90% है। यह चालों में से 1/200 के बारे में बताता था और त्रुटि, अब इसके बारे में 1/5 है। कोई भी फ़ाइल 100 mb से अधिक नहीं है, अधिकांश 100k के आसपास हैं

कुछ जानकारी:

$ df -h
Filesystem                     Size  Used Avail Use% Mounted on
/dev/sdb3                      155G  5.5G  142G   4% /
none                           4.0K     0  4.0K   0% /sys/fs/cgroup
udev                           3.9G  4.0K  3.9G   1% /dev
tmpfs                          797M  2.9M  794M   1% /run
none                           5.0M  4.0K  5.0M   1% /run/lock
none                           3.9G     0  3.9G   0% /run/shm
none                           100M     0  100M   0% /run/user
/dev/sdb1                       19G   78M   18G   1% /boot
/dev/mapper/archive-lvarchive   18T   15T  1.8T  90% /mnt/archive
/dev/sda1                      4.6T  1.1T  3.3T  25% /mnt/tmp

$ df -i
Filesystem                       Inodes    IUsed     IFree IUse% Mounted on
/dev/sdb3                      10297344   222248  10075096    3% /
none                            1019711        4   1019707    1% /sys/fs/cgroup
udev                            1016768      500   1016268    1% /dev
tmpfs                           1019711     1022   1018689    1% /run
none                            1019711        5   1019706    1% /run/lock
none                            1019711        1   1019710    1% /run/shm
none                            1019711        2   1019709    1% /run/user
/dev/sdb1                       4940000      582   4939418    1% /boot
/dev/mapper/archive-lvarchive 289966080 44899541 245066539   16% /mnt/archive
/dev/sda1                     152621056  5391544 147229512    4% /mnt/tmp

यहाँ मेरा उत्पादन है:

mv -n 747265521.pdf /mnt/archive/targetDir/747265521.pdf 
mv -n 61078318.pdf /mnt/archive/targetDir/61078318.pdf 
mv -n 709099107.pdf /mnt/archive/targetDir/709099107.pdf 
mv -n 75286077.pdf /mnt/archive/targetDir/75286077.pdf 
mv: cannot create regular file ‘/mnt/archive/targetDir/75286077.pdf’: No space left on device
mv -n 796522548.pdf /mnt/archive/targetDir/796522548.pdf 
mv: cannot create regular file ‘/mnt/archive/targetDir/796522548.pdf’: No space left on device
mv -n 685163563.pdf /mnt/archive/targetDir/685163563.pdf 
mv -n 701433025.pdf /mnt/archive/targetDir/701433025.pd

मैंने इस त्रुटि पर बहुत सारे पोस्ट किए हैं, लेकिन पूर्वानुमान फिट नहीं है। "आपकी ड्राइव वास्तव में पूर्ण है" या "आप इनोड से बाहर चले गए हैं" या यहां तक ​​कि "आपका / बूट वॉल्यूम पूर्ण है" जैसे मुद्दे। ज्यादातर, हालांकि, वे 3 पार्टी सॉफ्टवेयर के साथ सौदा करते हैं, क्योंकि यह फ़ाइलों को कैसे संभालता है, और वे सभी स्थिर हैं, जिसका अर्थ है कि हर कदम विफल रहता है।

धन्यवाद।

संपादित करें: यहां एक नमूना विफल और सफल फ़ाइल है:

विफल (अभी भी स्रोत ड्राइव पर)

ls -lhs 702637545.pdf
16K -rw-rw-r-- 1 myUser myUser 16K Jul 24 20:52 702637545.pdf

SUCCEEDED (लक्ष्य आयतन पर)

ls -lhs /mnt/archive/targetDir/704886680.pdf
104K -rw-rw-r-- 1 myUser myUser 103K Jul 25 01:22 /mnt/archive/targetDir/704886680.pdf

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

संपादित करें: @mjturner द्वारा प्रति अनुरोध कुछ अतिरिक्त आदेश

$ ls -ld /mnt/archive/targetDir
drwxrwxr-x 2 myUser myUser 1064583168 Aug 10 05:07 /mnt/archive/targetDir

$ tune2fs -l /dev/mapper/archive-lvarchive
tune2fs 1.42.10 (18-May-2014)
Filesystem volume name:   <none>
Last mounted on:          /mnt/archive
Filesystem UUID:          af7e7b38-f12a-498b-b127-0ccd29459376
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              289966080
Block count:              4639456256
Reserved block count:     231972812
Free blocks:              1274786115
Free inodes:              256343444
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        512
Flex block group size:    16
Filesystem created:       Thu Jun 25 12:05:12 2015
Last mount time:          Mon Aug  3 18:49:29 2015
Last write time:          Mon Aug  3 18:49:29 2015
Mount count:              8
Maximum mount count:      -1
Last checked:             Thu Jun 25 12:05:12 2015
Check interval:           0 (<none>)
Lifetime writes:          24 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      3ea3edc4-7638-45cd-8db8-36ab3669e868
Journal backup:           inode blocks

$ tune2fs -l /dev/sda1
tune2fs 1.42.10 (18-May-2014)
Filesystem volume name:   <none>
Last mounted on:          /mnt/tmp
Filesystem UUID:          10df1bea-64fc-468e-8ea0-10f3a4cb9a79
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              152621056
Block count:              1220942336
Reserved block count:     61047116
Free blocks:              367343926
Free inodes:              135953194
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      732
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         4096
Inode blocks per group:   256
Flex block group size:    16
Filesystem created:       Thu Jul 23 13:54:13 2015
Last mount time:          Tue Aug  4 04:35:06 2015
Last write time:          Tue Aug  4 04:35:06 2015
Mount count:              3
Maximum mount count:      -1
Last checked:             Thu Jul 23 13:54:13 2015
Check interval:           0 (<none>)
Lifetime writes:          150 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      a266fec5-bc86-402b-9fa0-61e2ad9b5b50
Journal backup:           inode blocks
linux  ubuntu  command-line  ext4 
— Chris.Caldwell
स्रोत
क्या फ़ाइलों को कई निर्देशिकाओं में कॉपी किया जा रहा है, या आप 1.5M फ़ाइलों को एक ही लक्ष्य निर्देशिका में लिखने का प्रयास कर रहे हैं?
— Snoopy
1.5 मी, 15 मी, और हाँ, सभी एक ही निर्देशिका में नहीं। वास्तव में वहाँ पहले से ही 40 मीटर से अधिक है, और कुल जाने के लिए लगभग 30 मीटर अधिक है।
— क्रिस। क्लैडवेल
ओह देखो, बेतरतीब डाउनवोट ट्रोल फिर से मारा। मुझे नहीं लगता कि आप का उल्लेख करने के लिए परवाह है आप नीचे क्यों?
— क्रिस। कैलडेल
1
डाउन वोट शायद इसलिए था क्योंकि आपका प्रश्न यूनिक्स.स्टैकएक्सचेंज या अक्यूबंटू के लिए बेहतर है क्योंकि यह प्रोग्रामिंग से संबंधित नहीं है। अगर आपके टैग में कोई प्रोग्रामिंग लैंग्वेज नहीं है, तो संभवत: इसे डाउन वोट मिलेगा।
— टेक्नोसॉरस
@Chris - एस एफ पर इस समस्या के समान लगता है: serverfault.com/questions/384541/...
— Snoopy

जवाबों:

25

Ext4 सुविधा के कार्यान्वयन में बग dir_indexजो आप अपने गंतव्य फाइल सिस्टम पर उपयोग कर रहे हैं।

समाधान: dir_index के बिना filesytem को फिर से बनाएँ। या ट्यून 2 एफएट का उपयोग करते हुए सुविधा को अक्षम करें (कुछ सावधानी की आवश्यकता है, संबंधित लिंक देखें नोवेल सूएस 10/11: एक्स 3 फाइलसिस्टम पर एच-ट्री इंडेक्सिंग अक्षम करें जो हालांकि एक्स 3 से संबंधित है, समान सावधानी की आवश्यकता हो सकती है।

(get a really good backup made of the filesystem)
(unmount the filesystem)
tune2fs -O ^dir_index /dev/foo
e2fsck -fDvy /dev/foo
(mount the filesystem)

ext4 में डिफ़ॉल्ट रूप से सक्षम dir_index नामक एक सुविधा है, जो हैश-टकराव के लिए अतिसंवेदनशील है।

......

ext4 में अपनी सामग्री के फ़ाइल नाम को रखने की संभावना है। यह प्रदर्शन को बढ़ाता है, लेकिन एक "छोटी" समस्या है: ext4 अपने हैशटेबल को नहीं बढ़ाता है, जब यह भरना शुरू होता है। इसके बजाय यह रिटर्न -ENOSPC या "डिवाइस पर कोई स्थान नहीं बचा है"।

— स्टीव
स्रोत
3
ओह बकवास, यह बिल्कुल ऐसा लगता है, और ठीक करने के लिए एक पूर्ण दर्द की तरह। इसके बारे में एक महीने के लिए पुनरावृत्ति। क्या यह सामग्री खोए बिना किया जा सकता है? बीमार को कल अधिक dir_index आदि पर शोध करना होगा। वाह, ऐसा कभी नहीं सोचा होगा।
— क्रिस। १२/०२
यदि आप कोशिश करना चाहते हैं, तो अनुक्रमणिका को निष्क्रिय करने के लिए tune2fs कमांड को जोड़ा गया।
— स्टीव
6
खैर देखा गया @steve। दुर्भाग्य से बंद करने dir_indexसे संभवतः एक निर्देशिका में 70 मीटर फ़ाइलों के साथ पहुंच प्रदर्शन को मार दिया जाएगा।
— mjturner 13
3
हाँ। Im को चोटी के प्रदर्शन की आवश्यकता नहीं है, लेकिन प्रत्येक फ़ाइल के लिए एफएस खोज भयानक होगी। तो अब Im xfs या 10k या इतने सबफ़ोल्डर्स के एक सरणी को देख रहा हूं। सबफोल्डर्स एक उचित समाधान है, हालांकि ext4 के साथ मैं अभी भी टकराव का जोखिम चलाता हूं। क्या xfs एक ही मुद्दे से पीड़ित है? मैंने पढ़ा है कि यह B + वृक्ष का उपयोग करता है, लेकिन यह मेरे लिए इतना मायने नहीं रखता है जितना कि यह सुनिश्चित करता है कि कभी टक्कर न हो। वहाँ गलत सूचनाओं की दुनिया है, और Ive ने दावा किया है कि यह एक लाख से अधिक फ़ाइलों को धीमा कर देता है, और दावा करता है कि यह बंद नहीं हुआ है।
— क्रिस। कैलडेल
2
मुझे लगता है कि यह एक महान उत्तर है, और आईडी इसे इस तरह चिह्नित करना पसंद करती है, लेकिन मुझे लगता है कि यह अच्छा होगा यदि हम एक निदान पर नहीं, बल्कि एक तय पर आ सकते हैं। किसी को पता है अगर xfs इस तरह से कुछ भी पीड़ित है? Ive मिश्रित समीक्षाएँ पढ़ें कि यह ठीक है, या 1 मी से अधिक नहीं।
— क्रिस। बाल्डवेल
8

छोटी फ़ाइलों के द्रव्यमान के भंडारण के लिए बेहतर-से-अतिरिक्त 4 विकल्पों के लिए सुझाव:

यदि आप फाइल सिस्टम का उपयोग ऑब्जेक्ट स्टोर के रूप में कर रहे हैं, तो आप एक ऐसी फाइल सिस्टम का उपयोग करना चाह सकते हैं जो संभवतः अन्य विशेषताओं के अवरोध के लिए उस में माहिर हो। एक त्वरित Google खोज मिली सेफ को, जो खुला स्रोत प्रतीत होता है, और इसे POSIX फाइल सिस्टम के रूप में माउंट किया जा सकता है, लेकिन अन्य एपीआई के साथ भी एक्सेस किया जा सकता है। मुझे नहीं पता कि यह प्रतिकृति के लाभ के बिना, एकल होस्ट पर उपयोग करने लायक है या नहीं।

एक अन्य ऑब्जेक्ट-स्टोरेज सिस्टम ओपनस्टैक की स्विफ्ट है । इसके डिज़ाइन डॉक्स का कहना है कि यह प्रत्येक ऑब्जेक्ट को एक अलग फ़ाइल के रूप में संग्रहीत करता है, जिसमें मेटाडेटा xattrs के साथ है । यहाँ इसके बारे में एक लेख है। उनकी तैनाती गाइड है कहना है कि उन्होंने पाया कि XFS ने ऑब्जेक्ट स्टोरेज के लिए सबसे अच्छा प्रदर्शन दिया। भले ही वर्कलोड वह नहीं है जो XFS सबसे अच्छा है, यह स्पष्ट रूप से प्रतियोगियों की तुलना में बेहतर था जब रैकस्पेस चीजों का परीक्षण कर रहा था। संभवतः स्विफ्ट एक्सएफएस का पक्षधर है क्योंकि एक्सएफएस में विस्तारित विशेषताओं के लिए अच्छा / तेज समर्थन है। यह हो सकता है कि ext3 / ext4 सिंगल डिस्क पर ऑब्जेक्ट-स्टोर बैकएंड के रूप में ठीक करेगा यदि अतिरिक्त मेटाडेटा की आवश्यकता नहीं थी (या यदि यह बाइनरी फ़ाइल के अंदर रखा गया था)।

स्विफ्ट आपके लिए प्रतिकृति / लोड-बैलेंसिंग करता है, और सुझाव देता है कि आप इसे कच्चे डिस्क पर बने फाइलसिस्टम देते हैं, RAID नहीं । यह इंगित करता है कि इसका कार्यभार मूल रूप से RAID5 के लिए सबसे खराब स्थिति है (जो समझ में आता है अगर हम छोटी फ़ाइलों के साथ कार्यभार के बारे में बात कर रहे हैं। XFS आमतौर पर उन्हें हेड-टू-टेल पैक नहीं करता है, इसलिए आप नहीं करते हैं। पूर्ण-पट्टी लिखता है, और RAID5 को समता पट्टी को अद्यतन करने के लिए कुछ पाठ करना पड़ता है। स्विफ्ट डॉक्स प्रति ड्राइव 100 विभाजन का उपयोग करने के बारे में भी बात करता है। मुझे लगता है कि यह एक स्विफ्ट शब्द है, और प्रत्येक पर 100 अलग-अलग एक्सएफएस फाइल बनाने के बारे में बात नहीं कर रहा है। SATA डिस्क।

हर डिस्क के लिए एक अलग XFS चलाना वास्तव में बहुत बड़ा अंतर है । एक की जगह विशाल फ्री-इनोड मैप के , प्रत्येक डिस्क में अलग-अलग फ्री-सूचियों के साथ एक अलग XFS होगा। इसके अलावा, यह छोटे लेखन के लिए RAID5 जुर्माना से बचा जाता है।

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

लगभग किसी भी सामान्य फाइलसिस्टम के साथ, यह जैसे संरचना का उपयोग करने में मदद करेगा

1234/5678   # nested medium-size directories instead of
./12345678   # one giant directory

संभवतः 10k प्रविष्टियों के बारे में उचित है, इसलिए अपने ऑब्जेक्ट नामों के एक अच्छी तरह से वितरित 4 वर्णों को लेना और निर्देशिकाओं के रूप में उनका उपयोग करना एक आसान समाधान है। यह बहुत अच्छी तरह से संतुलित होने की जरूरत नहीं है। अजीब 100k निर्देशिका शायद एक ध्यान देने योग्य मुद्दा नहीं होगा, और न ही कुछ खाली निर्देशिकाएं होंगी।

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

डेव चिनर ने एक्सएफएस के प्रदर्शन पर कुछ टिप्पणी की जिसमें बड़ी संख्या में इनोड आवंटित किए गए थे , जो धीमी गति से ईश की ओर बढ़ रहे थेtouch प्रदर्शन का । आवंटित करने के लिए एक फ्री इनोड ढूंढना अधिक सीपीयू समय लेना शुरू करता है, क्योंकि फ्री इनोड बिटमैप खंडित हो जाता है। ध्यान दें कि यह एक-बड़ी-निर्देशिका बनाम एकाधिक निर्देशिकाओं का मुद्दा नहीं है, बल्कि पूरे फाइल सिस्टम पर कई उपयोग किए गए इनोड्स का मुद्दा है। अपनी फ़ाइलों को कई निर्देशिकाओं में विभाजित करने से कुछ समस्याओं के साथ मदद मिलती है, जैसे कि ओपी में ext4 घुट गया, लेकिन खाली स्थान पर नज़र रखने की पूरी-डिस्क समस्या नहीं है। RAID5 पर विशाल XFS की तुलना में स्विफ्ट की अलग-फाइल-सिस्टम-प्रति-डिस्क इसकी मदद करती है।

मुझे नहीं पता कि btrfs इस पर अच्छा है, लेकिन मुझे लगता है कि यह हो सकता है। मुझे लगता है कि फेसबुक अपने लीड डेवलपर को एक कारण से नियुक्त करता है। : पी कुछ बेंचमार्क मैंने देखा है, लिनक्स कर्नेल स्रोत को अनट्रेन्ग करने जैसा सामान, शो btrfs अच्छा करता है।

मुझे पता है कि reiserfs को इस मामले के लिए अनुकूलित किया गया था, लेकिन यह बमुश्किल है, अगर बिल्कुल भी, अब भी बनाए रखा गया है। मैं वास्तव में reiser4 के साथ जाने की सिफारिश नहीं कर सकता। यह प्रयोग करने के लिए दिलचस्प हो सकता है, यद्यपि। लेकिन यह अभी तक कम से कम भविष्य के सबूत का विकल्प है। मैंने वृद्ध reiserFS पर प्रदर्शन में गिरावट की रिपोर्ट भी देखी है, और कोई अच्छा डीफ़्रैग टूल नहीं है। (Google filesystem millions of small files, और मौजूदा स्टैकएक्सचेंज उत्तरों में से कुछ को देखें।)

मैं शायद कुछ याद कर रहा हूं, इसलिए अंतिम सिफारिश: सर्वरफॉल्ट पर इसके बारे में पूछें! अगर मुझे अभी कुछ चुनना है, तो मैं कहूंगा कि BTRFS को एक कोशिश दें, लेकिन सुनिश्चित करें कि आपके पास बैकअप है। (esp। यदि आप BTRFS के बिल्ड-इन मल्टीपल डिस्क रिडंडेंसी का उपयोग करते हैं, तो इसे RAID के शीर्ष पर चलाने के बजाय। प्रदर्शन के फायदे बड़े हो सकते हैं, क्योंकि छोटी फाइलें RAID5 के लिए बुरी खबर हैं, जब तक कि यह एक ज्यादातर पढ़ने योग्य वर्कलोड नहीं है।)

— पीटर कॉर्डेस
स्रोत
1
बहुत बहुत धन्यवाद। मैंने बहुत से लोगों को उप-फ़ोल्डर्स का उपयोग करते देखा है, और वास्तव में वर्षों पहले मेरे पास एक अलग सेटअप पर उस प्रकार का समाधान था, लेकिन इसकी एक और परत जिससे मैं बचने की उम्मीद कर रहा था। यह इस तरह से करने से ओवरहेड की तरह दिखता है, हालांकि, एक एफएस खोजने की तुलना में बहुत कम होने जा रहा है जो सिर्फ इस उद्देश्य के लिए काम करता है। पुन :: XFS, इसकी आश्चर्यजनक बात यह है कि इसके घुटने के झटका जवाब देने के बाद से फ़ाइलों की उच्च गिनती में इतना बुरा है। BTRFS, विकी: "निर्देशिका प्रविष्टियाँ निर्देशिका आइटम के रूप में दिखाई देती हैं, जिनके दाहिने हाथ के मुख्य मूल्य उनके फ़ाइल नाम का CRC32C हैश हैं"। है कि हम एक ही समस्या नहीं है?
— क्रिस। कैलडेल
@ Chris.Caldwell: आपको जांच करनी होगी, लेकिन मुझे लगता है कि एनटीपीसी की बजाए एक ही हैश बाल्टी में कई प्रविष्टियों का समर्थन करके BTRFS हैश टकराव को संभालता है। क्या आपने फाइल सिस्टम में अलग-अलग फाइलों के बजाय, डेटाबेस में अपना सामान रखने के बारे में सोचा है? मुझे कभी भी इस तरह के डेटा को संभालने के लिए एक सिस्टम का निर्माण नहीं करना पड़ा है। मैं XFS का उपयोग करता हूं, जो कि मैं इसका उपयोग करने के लिए बहुत अच्छा हूं (वीडियो संग्रहीत करने के लिए, और सामान्य उद्देश्य यूनिक्स स्रोत कोड और सामान।)
— पीटर कॉर्डेस
1
जिस तरह से फाइलसिस्टम डिजाइन किए गए हैं, निर्देशिकाओं का एक स्तर कम उपरि है। छोटी तालिकाओं में दो तेज़ लुकअप एक अतिप्रवाह तालिका में एक धीमी गति से देखने की तुलना में तेज़ होंगे जो इसके लिए अनुकूलित की तुलना में अधिक डेटा संग्रहीत कर रहा है। जैसा कि मैंने कहा, आपको अपनी फ़ाइलों को पूरी तरह से निर्देशिकाओं के बीच वितरित करने की आवश्यकता नहीं है, इसलिए आप अपने फ़ाइल नाम के पहले 4 वर्णों को ले सकते हैं और एक सम्मिलित कर सकते हैं /। उम्मीद है कि आपके कोड में बहुत से स्थानों को प्रभावित नहीं करेगा। (यदि कोई नई फ़ाइल बनाने में विफल रहता है तो आपको यह सुनिश्चित करना होगा कि निर्देशिकाएं बनाई जाएं ENOENT)। अन्य फाइल सिस्टम हैं अगर सर्वरफॉल्ट पर पूछें।
— पीटर कॉर्ड्स
@ Chris.Caldwell: मुझे वास्तव में इस प्रश्न के उत्तर की नकल करनी चाहिए जहां यह प्रासंगिक है। कुछ मौजूदा हैं। मैं उत्सुक था कि ऑब्जेक्ट स्टोरेज के लिए उपयोग करने के लिए "क्या माना जाता है", और स्विफ्ट के बारे में कुछ डॉक्स मिले। जाहिरा तौर पर यह XFS पर अलग-अलग फ़ाइलों के रूप में वस्तुओं को संग्रहीत करता है (लेकिन प्रत्येक डिस्क के लिए एक अलग XFS के साथ, RAID नहीं। यह अतिरेक को संभालता है)।
— पीटर कॉर्डेस
1

नीचे दिए गए इस मुद्दे के लिए मैंने जो किया उसे ठीक करने के लिए (आपको नीचे दिए चरणों के लिए sudo पहुँच की आवश्यकता हो सकती है):

  1. इनोड्स का इस्तेमाल किया गया स्थान 100% था जिसे नीचे दिए गए कमांड का उपयोग करके पुनः प्राप्त किया जा सकता है

    df -i /

फाइलसिस्टम आईनोड आईएफआरई आईयूएस% पर चढ़ा हुआ

/dev/xvda1            524288   524288  o     100% /
  1. आई-नोट को मुक्त करने की आवश्यकता है, इसलिए उन फ़ाइलों को खोजने की आवश्यकता है जिनके पास नीचे कमांड का उपयोग करके आई नोड की संख्या है:

यह खोजने की कोशिश करें कि क्या यह इनोड्स समस्या है:

df -ih

बड़े इनोड की गिनती के साथ रूट फ़ोल्डर खोजने की कोशिश करें:

for i in /*; do echo $i; find $i |wc -l; done

विशिष्ट फ़ोल्डर खोजने का प्रयास करें:

for i in /src/*; do echo $i; find $i |wc -l; done
  1. अब हमने बड़ी संख्या में फाइलों के साथ फ़ोल्डर को शून्य कर दिया है। किसी भी त्रुटि से बचने के लिए नीचे दिए गए कमांड को एक के बाद एक चलाएं (मेरे मामले में वास्तविक फ़ोल्डर था / var / स्पूल / क्लायंटक्यू):
find /var/spool/clientmqueue/ -type f -mtime +1050 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +350 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +150 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +50 -exec rm -f {} +
— बरनी आर
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.