मैं एक निर्देशिका में कितनी फाइलें रख सकता हूं?


561

क्या यह मायने रखता है कि मैं एक निर्देशिका में कितनी फाइलें रखता हूं? यदि हां, तो एक निर्देशिका में कितनी फाइलें बहुत अधिक हैं, और बहुत अधिक फाइलें होने के प्रभाव क्या हैं? (यह एक लिनक्स सर्वर पर है।)

पृष्ठभूमि: मेरे पास एक फोटो एल्बम वेबसाइट है, और अपलोड की गई प्रत्येक छवि का नाम बदलकर 8-हेक्स-डिजिट आईडी (कहना, a58f375c.jpg) है। यह फ़ाइल नाम संघर्ष से बचने के लिए है (यदि "IMG0001.JPG" फ़ाइलों को बहुत सारे उदाहरण के लिए अपलोड किया गया है)। मूल फ़ाइल नाम और किसी भी उपयोगी मेटाडेटा को एक डेटाबेस में संग्रहीत किया जाता है। अभी, मेरे पास चित्र निर्देशिका में लगभग 1500 फाइलें हैं। यह निर्देशिका में फ़ाइलों को सूचीबद्ध करता है (FTP या SSH क्लाइंट के माध्यम से) कुछ सेकंड लेता है। लेकिन मैं यह नहीं देख सकता कि इसके अलावा कोई अन्य प्रभाव है। विशेष रूप से, इस बात का कोई प्रभाव नहीं पड़ता है कि उपयोगकर्ता को छवि फ़ाइल कितनी जल्दी परोसी जाती है।

मैंने 16 उपनिर्देशिकाएँ बनाकर छवियों की संख्या कम करने के बारे में सोचा है: 0-9 और उससे ऊपर। फिर मैं फाइल को उप-प्रकारों में स्थानांतरित करूँगा जो इस बात पर आधारित था कि फ़ाइल नाम का पहला हेक्स अंक क्या था। लेकिन मुझे यकीन नहीं है कि एफ़टीपी / एसएसएच के माध्यम से निर्देशिका की सामयिक सूची को छोड़कर ऐसा करने का कोई कारण है।

जवाबों:


736

FAT32 :

  • फ़ाइलों की अधिकतम संख्या: 268,173,300
  • प्रति निर्देशिका फ़ाइलों की अधिकतम संख्या: 2 16  - 1 (65,535)
  • अधिकतम फ़ाइल आकार: LFS के बिना 2 GiB - 1 , 4 GiB - 1 के साथ

NTFS :

  • फ़ाइलों की अधिकतम संख्या: 2 32  - 1 (4,294,967,295)
  • अधिकतम फ़ाइल आकार
    • कार्यान्वयन: 2 44  - 2 6 बाइट्स (16 टीआईबी - 64 कीबी)
    • सैद्धांतिक: 2 64  - 2 6 बाइट्स (16 ईआईबी - 64 कीबी)
  • अधिकतम मात्रा का आकार
    • कार्यान्वयन: 2 32  - 1 क्लस्टर (256 टीआईबी - 64 कीबी)
    • सैद्धांतिक: 2 64  - 1 क्लस्टर (1 यीबी - 64 कीबी)

ext2 :

  • फ़ाइलों की अधिकतम संख्या: 10 18
  • प्रति निर्देशिका फ़ाइलों की अधिकतम संख्या: ~ 1.3 × 10 20 (प्रदर्शन के मुद्दे पिछले 10,000)
  • अधिकतम फ़ाइल आकार
    • 16 GiB (1 KiB का ब्लॉक आकार)
    • 256 GiB (2 KiB का ब्लॉक आकार)
    • 2 TiB (4 KiB का ब्लॉक आकार)
    • 2 TiB (8 KiB का ब्लॉक आकार)
  • अधिकतम मात्रा का आकार
    • 4 TiB (1 KiB का ब्लॉक आकार)
    • 8 TiB (2 KiB का ब्लॉक आकार)
    • 16 TiB (4 KiB का ब्लॉक आकार)
    • 32 TiB (8 KiB का ब्लॉक आकार)

ext3 :

  • फ़ाइलों की अधिकतम संख्या: न्यूनतम (वॉल्यूम 13/2 13 , नंबरऑफब्लॉक )
  • अधिकतम फ़ाइल आकार: ext2 के समान
  • अधिकतम मात्रा का आकार: ext2 के समान

ext4 :

  • फ़ाइलों की अधिकतम संख्या: 2 32  - 1 (4,294,967,295)
  • प्रति निर्देशिका फ़ाइलों की अधिकतम संख्या: असीमित
  • अधिकतम फ़ाइल आकार: 2 44  - 1 बाइट्स (16 TiB - 1)
  • अधिकतम मात्रा का आकार: 2 48  - 1 बाइट्स (256 TiB - 1)

24
मुझे लगता है कि ये संपूर्ण विभाजन के लिए अधिकतम फाइलें हैं, निर्देशिका नहीं। इस प्रकार, यह जानकारी समस्या के संबंध में बहुत उपयोगी नहीं है, क्योंकि विधि की परवाह किए बिना फ़ाइलों की एक समान संख्या होगी (जब तक आप फ़ाइलों के रूप में निर्देशिकाओं की गिनती नहीं करते)।
प्रातः

19
चूंकि अब हम 2012 में हैं, मुझे लगता है कि इसका समय यह स्पष्ट करने के लिए है कि ext4 में उपनिर्देशिका की संख्या के संबंध में कोई सीमा नहीं है। साथ ही अधिकतम फाइलें 16 टीबी तक बढ़ गईं। इसके अलावा, फाइलसिस्टम का समग्र आकार 1 EB = 1,048,576 टीबी तक हो सकता है।
२३

7
जाहिर है, ext3 में प्रति निर्देशिका 60,000 फ़ाइलों (या निर्देशिका या लिंक) की सीमा भी है। मुझे इस बारे में कठिन रास्ता पता चला।
स्टैक्युलर

8
पुराना उत्तर, मुझे पता है ... लेकिन जब आप EXT4 लिखते हैं - अधिकतम संख्या में फ़ाइलें: 2 1 - 1 (4,294,967,295) और प्रति निर्देशिका फ़ाइलों की अधिकतम संख्या: असीमित आपने वास्तव में मुझे भ्रमित किया क्योंकि 2³² - 1! = "असीमित"। मुझे लगता है कि मुझे अब कॉफी की जरूरत है। ;) फिर भी +1
ई-सुशी

10
हार्ड फ़ाइल सिस्टम सीमाएं इस सवाल का जवाब नहीं देती हैं " क्या यह मायने रखता है कि मैं एक निर्देशिका में कितनी फाइलें रखता हूं? "
Etki

191

मेरे पास एक एकल ext3 निर्देशिका में 8 मिलियन से अधिक फाइलें हैं। libc readdir()जिसका उपयोग किया जाता है find, lsऔर अधिकांश अन्य तरीकों से इस निर्देशिका में चर्चा की जाती है ताकि बड़ी निर्देशिकाओं को सूचीबद्ध किया जा सके।

इस मामले में कारण lsऔर findधीमा है कि readdir()केवल एक समय में 32K निर्देशिका प्रविष्टियों को पढ़ता है, इसलिए धीमी डिस्क पर इसे निर्देशिका को सूचीबद्ध करने के लिए कई कई रीड्स की आवश्यकता होगी। इस गति की समस्या का एक समाधान है। मैंने इसके बारे में एक विस्तृत लेख लिखा है: http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with- ls /

कुंजी दूर ले जाती है: getdents()सीधे उपयोग करें - http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html जो कुछ भी libc पर आधारित है, उसके बजाय readdir()आप बफर को निर्दिष्ट कर सकते हैं डिस्क से निर्देशिका प्रविष्टियों को पढ़ते समय आकार।


6
दिलचस्प पढ़ा! क्या मैं पूछ सकता हूं कि एक निर्देशिका में आपके पास 8 लाख फाइलें किस स्थिति में हैं? हाहा
Aha

मेरा भी यही था। मैंने एक तालिका के बूँद कॉलम को माइग्रेट किया है, प्रत्येक बूँद कॉलम को मैंने एक फ़ाइल के रूप में निर्यात किया है। यह लगभग 8 मिलियन फाइलें है :)
स्पाइक

65

मेरे पास 88,914 फाइलों वाली एक निर्देशिका है। अपने आप की तरह यह थंबनेल और लिनक्स सर्वर पर स्टोर करने के लिए उपयोग किया जाता है।

एफ़टीपी या एक php फ़ंक्शन के माध्यम से सूचीबद्ध फ़ाइलें धीमी गति से हाँ हैं, लेकिन फ़ाइल को प्रदर्शित करने पर एक प्रदर्शन हिट भी है। जैसे www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg पर 200-400 एमएस का प्रतीक्षा समय है। किसी अन्य साइट पर तुलना के रूप में मेरे पास एक निर्देशिका में लगभग 100 फाइलें हैं, छवि केवल ~ 40ms के इंतजार के बाद प्रदर्शित होती है।

मैंने यह उत्तर दिया है क्योंकि ज्यादातर लोगों ने लिखा है कि निर्देशिका खोज फ़ंक्शन कैसे प्रदर्शन करेंगे, जिसे आप अंगूठे के फ़ोल्डर पर उपयोग नहीं करेंगे - बस सांख्यिकीय रूप से प्रदर्शित फाइलें, लेकिन प्रदर्शन में रुचि होगी कि फाइलें वास्तव में कैसे उपयोग की जा सकती हैं ।


6
यह एकमात्र उपयोगी उत्तर है। हमने ऐसे ही अनुभव किए हैं। बैकअप के साथ समस्याओं को कम करने के लिए हमारी सीमा 1.000 फाइलें है (बहुत अधिक निर्देशिका धीमा हो जाती है, भी)।
mgutt

1
यह noatime के साथ एक ड्राइव माउंट करने के लिए उपयोगी हो सकता है: howtoforge.com/… और इसे भी पढ़ें: serverfault.com/questions/354017/…
mgutt

2
क्या फाइलसिस्टम आप उपयोग कर रहे हैं जहाँ यह इतना धीमा हो जाता है? XFS, उदाहरण के लिए, किसी भी ध्यान देने योग्य मंदी के बिना आसानी से एक निर्देशिका में 100,000 फ़ाइलों को संभालने में सक्षम होना चाहिए।
एथन

1
अधिकांश अन्य लोगों की राय का विरोध करते हुए, मैं इस उत्तर की पुष्टि करना चाहता हूं। हमारी सोशल नेटवर्क वेबसाइट में हमारे पास हजारों हजारों इमेज हैं। प्रदर्शन को बेहतर बनाने के लिए हमें 100 (या कुछ फ़ाइलों के लिए 1000) उप निर्देशिकाओं के लिए मजबूर किया गया और फाइलों को उनमें वितरित किया (ext3 on linux + Apache)।
wmac

57

यह लिनक्स सर्वर पर उपयोग में आने वाले विशिष्ट फाइल सिस्टम पर थोड़ा निर्भर करता है। आजकल डिफ़ॉल्ट dir_index के साथ ext3 है, जो बड़ी निर्देशिकाओं को बहुत तेजी से खोजता है।

तो गति एक समस्या नहीं होनी चाहिए, आपके द्वारा पहले ही नोट किए गए के अलावा, जो कि लिस्टिंग में अधिक समय लगेगा।

एक निर्देशिका में फ़ाइलों की कुल संख्या की एक सीमा है। मुझे याद है कि यह निश्चित रूप से 32000 फाइलों तक काम कर रहा है।


4
सूक्ति और केडीई बड़े निर्देशिकाओं को एक घोंघे की गति से लोड करते हैं, खिड़कियां निर्देशिका को उचित रूप से कैश करेंगी। मुझे लिनक्स बहुत पसंद है, लेकिन kde और gnome खराब लिखे गए हैं।
बदमाश

1
और ext4 को डिफ़ॉल्ट रूप से dir_index के बराबर लगता है।
प्रो। फल्केन अनुबंध ने

22
Ext3 में एक निर्देशिका में लगभग 32K उपनिर्देशिका की सीमा है , लेकिन ओपी छवि फ़ाइलों के बारे में बात कर रहा है। डीआर इंडेक्स सक्षम वाली एक्स 3 फाइल सिस्टम में फाइलों पर कोई (व्यावहारिक) सीमा नहीं है।
पीटर एन लुईस

1
यह उत्तर पुराना है, आजकल डिफ़ॉल्ट ext4 है
बोरिस

1
"डार इंडेक्स सक्षम के साथ एक ext3 फाइल सिस्टम में फाइलों पर कोई (व्यावहारिक?) सीमा नहीं है" - मैं सक्षम के साथ एक 4TB ext4 फाइल सिस्टम पर एक निर्देशिका में फ़ाइल स्थान से बाहर भाग गया dir_index। मेरे पास निर्देशिका में लगभग 17 मिलियन फाइलें थीं। इसका उत्तर large_dirट्यून 2 एफए को चालू करना था ।
20

49

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

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

या

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

33
@ देखें, इन मामलों के लिए (1) और / या xargs (1) का उपयोग करें। इसी कारण से कमांड लाइन विस्तार के बजाय स्क्रिप्ट में ऐसे टूल का उपयोग करना एक अच्छा विचार है।
डेव सी

3
जब आप फ़ोल्डर में फ़ाइलों की संख्या बढ़ाते हैं, तो क्या आप प्रदर्शन को कम करते हुए देखते हैं? या कोई संबंध नहीं है?
पचेरियर

6
यह एक अच्छा बिंदु है लेकिन नाइटपिक के लिए, दिया गया कारण गलत है। तर्क सूची बहुत लंबा खोल के न कि सीमित है, लेकिन प्रणाली के execकार्यान्वयन। शेल आमतौर पर वाइल्डकार्ड को ठीक प्रकार से विस्तारित कर सकता है - यह execउस कई तर्कों के साथ कॉल है जो त्रुटि देता है।
jw013

मुझे कल रात (फेडोरा 15) "आरएम" (somefiles *) के साथ एक निर्देशिका में लगभग 400,000 फ़ाइलों के साथ एक ही त्रुटि थी। मैं पुरानी फाइलों को "खोज" के साथ उस बिंदु पर ट्रिम करने में सक्षम था जहां मैं वाइल्डकार्ड के साथ "आरएम" कर सकता था।
पीजे ब्रुनेट

ETx4 पर एक निर्देशिका के लिए 10.000.000 फाइलें ठीक काम करती हैं। पहुँच के दौरान कोई प्रदर्शन हिट नहीं। लेकिन वाइल्डकार्ड के साथ धीमी गति से। फ़ाइल नाम को सॉर्ट करने के लिए पसंद करने वाले शेल प्रोग्राम का उपयोग करते समय सावधान रहें! :)
साइमन रिगेट

25

मैं अभी इसी तरह की समस्या पर काम कर रहा हूं। हमारे पास एक पदानुक्रमित निर्देशिका संरचना है और फ़ाइल नाम के रूप में छवि आईडी का उपयोग करें। उदाहरण के लिए, के साथ एक छवि id=1234567में रखा गया है

..../45/67/1234567_<...>.jpg

फ़ाइल कहाँ जाती है यह निर्धारित करने के लिए अंतिम 4 अंकों का उपयोग करना।

कुछ हजार छवियों के साथ, आप एक-स्तरीय पदानुक्रम का उपयोग कर सकते हैं। हमारे sysadmin ने दक्षता / बैकअप / जो भी अन्य कारणों को ध्यान में रखा, उनके लिए किसी भी निर्देशिका (ext3) में कुछ हज़ार से अधिक फ़ाइलों का सुझाव नहीं दिया।


1
यह एक बहुत अच्छा समाधान है। फ़ाइल के नीचे आपकी निर्देशिका के हर स्तर पर अधिकतम 100 प्रविष्टियाँ होंगी यदि आप 2 अंकों के टूटने के साथ चिपके रहते हैं, और सबसे नीचे की निर्देशिका में केवल 1 फ़ाइल होगी।
रॉबोह्र

PHP कार्यान्वयन: stackoverflow.com/a/29707920/318765
एमजीयूटी

21

इसके लायक क्या है, मैंने बस एक ext4फाइल सिस्टम पर 1,000,000 फ़ाइलों के साथ एक निर्देशिका बनाई है , फिर वेब सर्वर के माध्यम से उन फ़ाइलों को बेतरतीब ढंग से एक्सेस किया है। मैंने उन 10 तक पहुँचने पर कोई प्रीमियम नहीं देखा (कहते हैं) केवल 10 फाइलें थीं।

यह वह जगह है मौलिक मेरे अनुभव के ऐसा करने से अलग ntfsकुछ साल पहले।


किस प्रकार की फाइलें? पाठ या चित्र? मैं ext4 पर हूं और वर्डप्रेस के तहत एक ही निर्देशिका में 80000 छवियों को आयात करना चाहता हूं और जानना चाहता हूं कि क्या यह ठीक होगा
यवॉन हुइन्ह

1
@YvonHuynh: फ़ाइल का प्रकार पूरी तरह से अप्रासंगिक है। फ़ाइल की लिस्टिंग / ट्रैकिंग की निर्देशिका में ओवरहेड समान रूप से समान है।
टीजे क्राउडर

14

मैंने जो सबसे बड़ा मुद्दा चलाया है वह 32-बिट सिस्टम पर है। एक बार जब आप एक निश्चित संख्या पास कर लेते हैं, तो 'ls' जैसे उपकरण काम करना बंद कर देते हैं।

उस निर्देशिका के साथ कुछ भी करने की कोशिश करते हुए एक बार जब आप उस बाधा को पार कर लेते हैं तो यह एक बड़ी समस्या बन जाती है।


9

मैं एक ही मुद्दा रहा है। Ext4 में एक Ubuntu सर्वर में लाखों फाइलों को स्टोर करने की कोशिश की जा रही है। अपने स्वयं के बेंचमार्क चलाना समाप्त कर दिया। पता चला कि फ्लैट डायरेक्टरी उपयोग करने के लिए सरल होने के दौरान बेहतर तरीके से प्रदर्शन करती है:

बेंचमार्क

एक लेख लिखा ।


किसी समाधान का लिंक स्वागत योग्य है, लेकिन कृपया सुनिश्चित करें कि आपका उत्तर इसके बिना उपयोगी है: लिंक के चारों ओर संदर्भ जोड़ें ताकि आपके साथी उपयोगकर्ताओं को कुछ अंदाजा हो कि यह क्या है और यह क्यों है, तो पृष्ठ के सबसे प्रासंगिक हिस्से को उद्धृत करें ' लक्ष्य पृष्ठ अनुपलब्ध होने की स्थिति में पुनः लिंक करना। एक लिंक से थोड़ा अधिक उत्तर देने वाले उत्तर हटाए जा सकते हैं।
शमूएल एलवाई

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

7

यदि निर्देशिका विभाजन योजना को लागू करने में शामिल समय कम से कम है, तो मैं इसके पक्ष में हूं। पहली बार आपको एक समस्या को डीबग करना होगा जिसमें कंसोल के माध्यम से 10000-फ़ाइल निर्देशिका को हेरफेर करना शामिल होगा जिसे आप समझेंगे।

एक उदाहरण के रूप में, एफ-स्पॉट फोटो फ़ाइलों को YYYY \ MM \ DD \ filename.ext के रूप में संग्रहीत करता है, जिसका अर्थ है कि मुझे सबसे बड़ी निर्देशिका से निपटना है जबकि मैन्युअल रूप से मेरे ~ 20000-फोटो संग्रह में हेरफेर करने में लगभग 800 फाइलें हैं। यह तृतीय पक्ष एप्लिकेशन से फ़ाइलों को अधिक आसानी से ब्राउज़ करने योग्य बनाता है। यह कभी न मानें कि आपका सॉफ़्टवेयर एकमात्र ऐसी चीज़ है जो आपके सॉफ़्टवेयर की फ़ाइलों तक पहुँच प्राप्त करेगी।


6
मैं तिथि के हिसाब से विभाजन के खिलाफ विज्ञापन देता हूं क्योंकि थोक आयात एक निश्चित तिथि में फाइलों को जमा कर सकता है।
अधिकतम

एक अच्छा बिंदु। विभाजन योजना चुनने से पहले आपको अपने उपयोग के मामलों पर विचार करना चाहिए। मैं अपेक्षाकृत व्यापक वितरण में कई दिनों तक फ़ोटो आयात करता हूं, और जब मैं एफ-स्पॉट की तारीख के बाहर की तस्वीरों को हेरफेर करना चाहता हूं, तो उन्हें खोजने का सबसे आसान तरीका है, इसलिए यह मेरे लिए दोहरी जीत है।
Sparr

7

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

यहां तक ​​कि अगर फाइलसिस्टम सही करता है, तो यह अभी भी उन प्रोग्रामों के लिए पूरी तरह से संभव है जो निर्देशिका सामग्री को गड़बड़ाने के लिए और एक ओ (एन ^ 2) सॉर्ट करते हैं, इसलिए सुरक्षित पक्ष पर रहने के लिए, मैं हमेशा प्रति फ़ाइलों की संख्या को सीमित करता हूं निर्देशिका 500 से अधिक नहीं।


7

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

उदाहरण के लिए, ext3 में कई हजारों फाइलें हो सकती हैं; लेकिन हजारों लोगों के बाद, यह बहुत धीमा हुआ करता था। ज्यादातर एक निर्देशिका को सूचीबद्ध करते समय, लेकिन एक फ़ाइल को खोलने पर भी। कुछ साल पहले, इसने 'htree' विकल्प प्राप्त किया, जिसने नाटकीय रूप से एक फाइल नाम दिया गया एक इनोड प्राप्त करने के लिए आवश्यक समय को छोटा कर दिया।

व्यक्तिगत रूप से, मैं एक या अधिक वस्तुओं के तहत अधिकांश स्तरों को रखने के लिए उपनिर्देशिका का उपयोग करता हूं। आपके मामले में, मैं आईडी के दो आखिरी हेक्स अंकों के साथ 256 निर्देशिकाएं बनाऊंगा। अंतिम और पहले अंकों का उपयोग करें, ताकि आपको लोड संतुलित मिले।


6
यदि फ़ाइलनाम पूरी तरह से यादृच्छिक थे, तो इससे कोई फर्क नहीं पड़ता कि कौन से अंक का उपयोग किया गया था।
strager

वास्तव में, ये फ़ाइल नाम बेतरतीब ढंग से उत्पन्न होते हैं।
किप

2
या फ़ाइल नाम के SHA-1 डाइजेस्ट के पहले एन बाइट्स का उपयोग करें।
गावी

6

ext3 की वास्तव में निर्देशिका आकार सीमाएं हैं, और वे फाइल सिस्टम के ब्लॉक आकार पर निर्भर करते हैं। फ़ाइलों की प्रति-निर्देशिका "अधिकतम संख्या" नहीं है, लेकिन प्रति-निर्देशिका "फ़ाइल प्रविष्टियों को संग्रहीत करने के लिए उपयोग किए जाने वाले ब्लॉक की अधिकतम संख्या" है। विशेष रूप से, निर्देशिका का आकार ऊंचाई 3 के बी-ट्री से आगे नहीं बढ़ सकता है, और पेड़ का फैनआउट ब्लॉक आकार पर निर्भर करता है। कुछ विवरणों के लिए यह लिंक देखें।

https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html

मुझे हाल ही में 2k ब्लॉक के साथ फॉर्मेट किए गए एक फाइल सिस्टम पर काट दिया गया था, जो कि अनावश्यक रूप से निर्देशिका-पूर्ण कर्नेल संदेश प्राप्त warning: ext3_dx_add_entry: Directory index full!कर रहा था जब मैं दूसरे एक्स 3 फाइल सिस्टम से कॉपी कर रहा था। मेरे मामले में, मात्र 480,000 फ़ाइलों वाली एक निर्देशिका को गंतव्य पर कॉपी नहीं किया जा सका।


5

सवाल नीचे आता है कि आप फ़ाइलों के साथ क्या करने जा रहे हैं।

विंडोज के तहत, 2k से अधिक फ़ाइलों वाली कोई भी निर्देशिका एक्सप्लोरर में मेरे लिए धीरे-धीरे खुलने लगती है। यदि वे सभी छवि फ़ाइलें हैं, तो 1k से अधिक थंबनेल दृश्य में बहुत धीरे-धीरे खुलते हैं।

एक समय में, सिस्टम-इम्पोज़्ड लिमिट 32,767 थी। अब यह अधिक है, लेकिन यहां तक ​​कि ज्यादातर परिस्थितियों में एक समय में संभालने के लिए बहुत अधिक फाइलें हैं।


5

ऊपर दिए गए अधिकांश उत्तर यह दिखाने में विफल हैं कि मूल प्रश्न का उत्तर "वन साइज़ फ़िट्स ऑल" नहीं है।

आज के परिवेश में हमारे पास विभिन्न हार्डवेयर और सॉफ्टवेयर का एक बड़ा समूह है - कुछ 32 बिट है, कुछ 64 बिट है, कुछ अत्याधुनिक है और कुछ आजमाया हुआ और सत्य है - विश्वसनीय और कभी नहीं बदलने वाला। जोड़ा गया है कि पुराने और नए हार्डवेयर, पुराने और नए OSes, विभिन्न विक्रेताओं (Windows, Unixes, Apple, आदि) और उपयोगिताओं और सर्वरों के असंख्य जो साथ चलते हैं। जैसा कि हार्डवेयर में सुधार हुआ है और सॉफ्टवेयर को 64 बिट संगतता में बदल दिया गया है, आवश्यक रूप से परिवर्तनों की तीव्र गति के साथ अच्छी तरह से खेलने के लिए इस बहुत बड़े और जटिल दुनिया के सभी टुकड़ों को प्राप्त करने में काफी देरी हुई है।

IMHO एक समस्या को ठीक करने का कोई एक तरीका नहीं है। इसका समाधान संभावनाओं पर शोध करना है और फिर परीक्षण और त्रुटि से पता चलता है कि आपकी विशेष आवश्यकताओं के लिए सबसे अच्छा काम क्या है। प्रत्येक उपयोगकर्ता को यह निर्धारित करना चाहिए कि कुकी कटर दृष्टिकोण का उपयोग करने के बजाय उनके सिस्टम के लिए क्या काम करता है।

उदाहरण के लिए मेरे पास कुछ बहुत बड़ी फ़ाइलों के साथ एक मीडिया सर्वर है। परिणाम केवल 3 टीबी ड्राइव भरने वाली लगभग 400 फाइलें हैं। इनोड का केवल 1% उपयोग किया जाता है लेकिन कुल अंतरिक्ष का 95% उपयोग किया जाता है। अंतरिक्ष भरने के लिए पास आने से पहले कोई और छोटी फ़ाइलों के साथ बहुत सी छोटी फ़ाइलों को इनोड से बाहर चला सकता है। (अंगूठे के नियम के रूप में ext4 फाइल सिस्टम पर, प्रत्येक फाइल / डायरेक्टरी के लिए 1 इनोड का उपयोग किया जाता है।) जबकि सैद्धांतिक रूप से एक निर्देशिका के भीतर समाहित की जा सकने वाली फ़ाइलों की कुल संख्या लगभग अनंत है, व्यावहारिकता यह निर्धारित करती है कि समग्र उपयोग यथार्थवादी इकाइयों को निर्धारित करता है, न कि बस फाइल सिस्टम क्षमताओं।

मुझे उम्मीद है कि ऊपर दिए गए सभी अलग-अलग उत्तरों ने प्रगति के लिए एक अड़ियल बाधा पेश करने के बजाय विचार और समस्या को हल करने को बढ़ावा दिया है।


4

मुझे याद है कि एक प्रोग्राम चल रहा है जो आउटपुट पर बड़ी मात्रा में फाइल बना रहा है। फ़ाइलों को 30000 प्रति निर्देशिका में सॉर्ट किया गया था। मुझे याद नहीं है कि किसी भी पढ़ी हुई समस्या है जब मुझे उत्पादित आउटपुट का पुन: उपयोग करना पड़ा। यह 32-बिट उबंटू लिनक्स लैपटॉप पर था, और यहां तक ​​कि नॉटिलस ने कुछ सेकंड के बाद, निर्देशिका सामग्री को प्रदर्शित किया।

ext3 फाइलसिस्टम: 64-बिट सिस्टम पर समान कोड 64000 फाइलों के साथ प्रति निर्देशिका अच्छी तरह से निपटा जाता है।


4

"फाइलसिस्टम पर निर्भर करता है"
कुछ उपयोगकर्ताओं ने उल्लेख किया कि प्रदर्शन प्रभाव प्रयुक्त फाइल सिस्टम पर निर्भर करता है। बेशक। EXT3 जैसे फाइलसिस्टम बहुत धीमे हो सकते हैं। लेकिन यहां तक ​​कि अगर आप EXT4 या XFS का उपयोग करते हैं, तो आप उस फ़ोल्डर को एक बाहरी कनेक्शन के माध्यम से lsया findFTP के माध्यम से सूचीबद्ध करने से रोक नहीं सकते हैं जैसे कि एफ़टीपी धीमा हो जाएगा।

समाधान
मैं @armandino की तरह ही पसंद करता हूं । उसके लिए मैं PHP में इस छोटे से फ़ंक्शन का उपयोग आईडी को एक फ़ाइलपथ में बदलने के लिए करता हूं, जिसके परिणामस्वरूप प्रति निर्देशिका 1000 फाइलें होती हैं:

function dynamic_path($int) {
    // 1000 = 1000 files per dir
    // 10000 = 10000 files per dir
    // 2 = 100 dirs per dir
    // 3 = 1000 dirs per dir
    return implode('/', str_split(intval($int / 1000), 2)) . '/';
}

या यदि आप अल्फा-न्यूमेरिक वर्णों का उपयोग करना चाहते हैं, तो आप दूसरे संस्करण का उपयोग कर सकते हैं:

function dynamic_path2($str) {
    // 26 alpha + 10 num + 3 special chars (._-) = 39 combinations
    // -1 = 39^2 = 1521 files per dir
    // -2 = 39^3 = 59319 files per dir (if every combination exists)
    $left = substr($str, 0, -1);
    return implode('/', str_split($left ? $left : $str[0], 2)) . '/';
}

परिणाम:

<?php
$files = explode(',', '1.jpg,12.jpg,123.jpg,999.jpg,1000.jpg,1234.jpg,1999.jpg,2000.jpg,12345.jpg,123456.jpg,1234567.jpg,12345678.jpg,123456789.jpg');
foreach ($files as $file) {
    echo dynamic_path(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
1/123.jpg
1/999.jpg
1/1000.jpg
2/1234.jpg
2/1999.jpg
2/2000.jpg
13/12345.jpg
12/4/123456.jpg
12/35/1234567.jpg
12/34/6/12345678.jpg
12/34/57/123456789.jpg

<?php
$files = array_merge($files, explode(',', 'a.jpg,b.jpg,ab.jpg,abc.jpg,ddd.jpg,af_ff.jpg,abcd.jpg,akkk.jpg,bf.ff.jpg,abc-de.jpg,abcdef.jpg,abcdefg.jpg,abcdefgh.jpg,abcdefghi.jpg'));
foreach ($files as $file) {
    echo dynamic_path2(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
12/123.jpg
99/999.jpg
10/0/1000.jpg
12/3/1234.jpg
19/9/1999.jpg
20/0/2000.jpg
12/34/12345.jpg
12/34/5/123456.jpg
12/34/56/1234567.jpg
12/34/56/7/12345678.jpg
12/34/56/78/123456789.jpg
a/a.jpg
b/b.jpg
a/ab.jpg
ab/abc.jpg
dd/ddd.jpg
af/_f/af_ff.jpg
ab/c/abcd.jpg
ak/k/akkk.jpg
bf/.f/bf.ff.jpg
ab/c-/d/abc-de.jpg
ab/cd/e/abcdef.jpg
ab/cd/ef/abcdefg.jpg
ab/cd/ef/g/abcdefgh.jpg
ab/cd/ef/gh/abcdefghi.jpg

जैसा कि आप देख सकते हैं $int-version के लिए हर फ़ोल्डर में 1000 फाइलें और 99 तक 1000 फाइलें और 99 निर्देशिकाएं होती हैं ...

लेकिन यह मत भूलो कि कई निर्देशिकाओं में एक ही प्रदर्शन समस्याओं का कारण बनता है!

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


3

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


3

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

मैंने अपने लिए ऐसा करने के लिए थोड़ा php स्क्रिप्ट सोचा और ब्राउज़र में इसे समय से रोकने के लिए एक तरीका जानने की कोशिश की।

इस मुद्दे को हल करने के लिए मैंने लिखा php स्क्रिप्ट निम्नलिखित है।

एफ़टीपी के लिए बहुत सी फाइलों के साथ एक निर्देशिका में फ़ाइलें सूचीबद्ध करना

यह किसी की मदद कैसे करता है


1

जवाब नहीं, बल्कि सिर्फ कुछ सुझाव।

अधिक उपयुक्त FS (फ़ाइल सिस्टम) का चयन करें। एक ऐतिहासिक दृष्टिकोण से, आपके सभी मुद्दे पर्याप्त रूप से बुद्धिमान थे, एक बार दशकों से विकसित हो रहे एफएस के लिए केंद्रीय होने के लिए। मेरा मतलब है कि अधिक आधुनिक एफएस आपके मुद्दों का बेहतर समर्थन करते हैं। सबसे पहले एफएस सूची से अपने अंतिम उद्देश्य के आधार पर एक तुलनात्मक निर्णय तालिका बनाएं ।

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

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

हार्डवेयर सीमा को पार करने के लिए आप RAID-0 का उपयोग कर सकते हैं।


1

कोई एकल आंकड़ा नहीं है जो "बहुत अधिक" है, जब तक कि यह ओएस की सीमा से अधिक न हो। हालाँकि, OS की परवाह किए बिना, एक निर्देशिका में जितनी अधिक फाइलें हैं, किसी भी व्यक्तिगत फ़ाइल को एक्सेस करने में अधिक समय लगता है, और अधिकांश OS पर, प्रदर्शन गैर-रैखिक होता है, इसलिए 10,000 में से एक फ़ाइल को खोजने के लिए अधिक 10 बार अधिक समय लगता है। फिर 1,000 में एक फ़ाइल खोजने के लिए।

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

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