लिनक्स उपनिर्देशिका संख्या सीमा कैसे हल करें?

Question

मेरे पास एक वेबसाइट है जो उपयोगकर्ता प्रोफ़ाइल छवियों को संग्रहीत करेगी। प्रत्येक छवि उपयोगकर्ता के लिए विशिष्ट निर्देशिका (लिनक्स) में संग्रहीत की जाती है। वर्तमान में मेरे पास 30+ का ग्राहक आधार है, जिसका अर्थ है कि मेरे पास 30+ फ़ोल्डर होंगे। लेकिन मेरा वर्तमान लिनक्स बॉक्स (ext2 / ext3) 32000 से अधिक निर्देशिका बनाने का समर्थन नहीं करता है। मैं इसे कैसे पा सकता हूं? यहां तक ​​कि YouTube लोगों को भी वीडियो थंबनेल के साथ यही समस्या मिली है। लेकिन उन्होंने इसे ReiserFS में ले जाकर हल किया। क्या हमारे पास बेहतर समाधान नहीं हो सकता है?

अपडेट: IRC में पूछे जाने पर, लोग इसे ext4 में अपग्रेड करने के बारे में पूछ रहे थे, जिसकी सीमा 64k है और निश्चित रूप से आप इसे भी प्राप्त कर सकते हैं । या सीमा बदलने के लिए कर्नेल हैकिंग।

अपडेट: यूजर बेस के आधार पर यूजर बेस को फोल्डर में विभाजित करने के बारे में। एक फोल्डर में 1-1000 मतलब, दूसरे में 1000-2000। यह सरल प्रतीत होता है। आप क्या कहते हैं, दोस्तों?

सच कहूँ तो, वहाँ कोई रास्ता नहीं है?

Comments

आप फाइल सिस्टम क्यों नहीं बदलना चाहते हैं? यदि यह ext2 / 3 की सीमा है, तो आपके पास फ़ाइल सिस्टम को बदलने या वर्तमान FS को अधिक छोटे FSs (अधिक भिन्न माउंट बिंदु) में विभाजित करने के अलावा कोई अन्य परिवर्तन नहीं होगा।

— मैनुअल फ़ुक्स

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

— काइल ब्रान्ड

Answer 1

यह सीमा प्रति-निर्देशिका है, संपूर्ण फाइलसिस्टम के लिए नहीं, इसलिए आप इसके बारे में आगे की सब-डिवाइडिंग चीजों द्वारा काम कर सकते हैं। उदाहरण के लिए एक ही निर्देशिका में सभी उपयोगकर्ता उपनिर्देशिका होने के बजाय उन्हें नाम के पहले दो पात्रों में विभाजित करें ताकि आपके पास कुछ ऐसा हो:

top_level_dir
|---aa
|   |---aardvark1
|   |---aardvark2
|---da
|   |---dan
|   |---david
|---do
    |---don

इससे भी बेहतर होगा कि नामों के कुछ प्रकार के हैश का निर्माण करें और विभाजन के लिए इसका उपयोग करें। इस तरह से आपको प्रारंभिक अक्षरों के उदाहरण के बजाय निर्देशिकाओं के बीच बेहतर प्रसार मिलेगा, "दा" बहुत भरा हुआ है और "zz" पूरी तरह से खाली है। उदाहरण के लिए यदि आप CRC या MD5 का नाम लेते हैं और पहले 8 बिट्स का उपयोग करते हैं, तो आप कुछ इस तरह प्राप्त करेंगे:

top_level_dir
|---00
|   |---some_username
|   |---some_username
|---01
|   |---some_username
...
|---FF
|   |---some_username

उदाहरण के लिए आवश्यकतानुसार इसे और अधिक गहराई तक बढ़ाया जा सकता है, जैसे कि यदि उपयोगकर्ता नाम हैश मान का उपयोग नहीं कर रहा है:

top_level_dir
|---a
|   |---a
|       |---aardvark1
|       |---aardvark2
|---d
    |---a
    |   |---dan
    |   |---david
    |---o
        |---don

इस विधि का उपयोग कई स्थानों पर किया जाता है जैसे कि स्क्विड का कैश, लुडविग के उदाहरण को कॉपी करने के लिए, और वेब ब्राउज़र के स्थानीय कैश में।

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

Comments

इसे शामिल करने के लिए बस प्रश्न का विवरण अपडेट किया गया: "अपडेट: उपयोगकर्ता आधार पर फ़ोल्डर में उपयोगकर्ता आधार को विभाजित करने के बारे में। एक फ़ोल्डर में 1-1000, दूसरे में 1000-2000 की तरह। यह सरल प्रतीत होता है। तुम कहते हो?"

— कोई-दा

यह अच्छी तरह से काम करेगा, और हैश की तुलना में अधिक कुशल होगा, अगर उपयोगकर्ताओं को आमतौर पर उपयोगकर्ता आईडी (या साथ ही) उपयोगकर्ता नाम से पहचाना जाता है। यद्यपि यदि आप हमेशा उन्हें सिस्टम में कहीं और नाम से संदर्भित करते हैं, तो आपको जगह में अतिरिक्त नाम-> आईडी लुकअप जोड़ना होगा।

— डेविड स्पिल्ट्ट

थैंक्यू डेविड! मैंने अलग-अलग उपाय भी आजमाए। मैंने १-३००००, ३००००-६०००० आदि के साथ मुश्किल से ४ फोल्डर बनाए हैं। मुझे लगता है कि इतनी बड़ी डायरेक्टरी से फाइल मिलने में एक डायरेक्टरी से ज्यादा समय लगेगा, जिसमें १००० फाइल्स (पिछला अप्रोच) है। आप क्या कहते हैं?

— कोई नहीं-दा

यह फाइलसिस्टम पर निर्भर करता है। यदि आप ext2 या ext3 का उपयोग कर रहे हैं तो मैं प्रति निर्देशिका 30,000 से बहुत कम की सिफारिश करूंगा। कुछ उपकरण 10,000 के बारे में चेतावनी जारी करते हैं। आप मदद करने के लिए ext3 / 4 में डायरेक्टरी इंडेक्सिंग को चालू कर सकते हैं: tune2fs -O dir_index / dev / <volumename> लेकिन सिर्फ डायरेक्टरी में ऑब्जेक्ट्स की संख्या कम (हज़ार या उससे कम?) रखने से क्या होता है? ।

— डेविड स्पिललेट जुले

@ मैडी, आप इस समाधान को अन्य सीमाओं के कारण चाहते हैं कि Ext2 / 3 बड़ी संख्या में फ़ाइलों को कैसे संभालता है। कुछ विवरण के लिए serverfault.com/questions/43133/… देखें । बाल्टियों-अस-उपनिर्देशिकाओं में नामों को तोड़ना अन्य मुद्दों को कम करता है जिन्हें आप अंततः चलाएंगे। ध्यान दें कि यह वही रणनीति है जिसका उपयोग स्क्विड तब करता है जब वह ऑब्जेक्ट कैश को पहली बार सेट करता है - उदाहरण के लिए, 64 निर्देशिकाएं जिनमें से प्रत्येक के अंदर 64 निर्देशिकाएं हैं, उदाहरण के रूप में।

— एवरी पायने

Answer 2

यदि आप ext2 / ext3 के लिए बाध्य हैं, तो मुझे केवल वही संभावना दिखाई देती है जो आपके डेटा को विभाजित करने के लिए है। एक मानदंड खोजें जो आपके डेटा को समान आकार के प्रबंधनीय विखंडू में विभाजित करता है।

यदि यह केवल उन प्रोफ़ाइल छवियों के बारे में है जो मैं करूंगा:

1. छवि का हैश (जैसे SHA1) का उपयोग करें
2. SHA1 का उपयोग फ़ाइल और निर्देशिका नाम के रूप में करें

उदाहरण के लिए SQUID कैश इसे इस तरह करता है:

f / 4 बी / 353ac7303854033

शीर्ष स्तर निर्देशिका पहली हेक्स-अंक है, दूसरा स्तर अगले दो हेक्स-अंक है, और फ़ाइल का नाम शेष हेक्स-अंक है।

Answer 3

कठबोली हम एक बेहतर समाधान है?

आपके पास एक बेहतर समाधान है - एक अलग फाइल सिस्टम का उपयोग करें, बहुत सारे उपलब्ध हैं, जिनमें से कई अलग-अलग कार्यों के लिए अनुकूलित हैं। जैसा कि आपने बताया ReiserFS एक निर्देशिका में बहुत सारी फ़ाइलों को संभालने के लिए अनुकूलित है।

फाइलसिस्टम की तुलना के लिए यहां देखें ।

बस खुशी है कि आप NTFS के साथ फंस नहीं रहे हैं जो वास्तव में एक निर्देशिका में बहुत सारी फ़ाइलों के लिए संक्षिप्त है। यदि आप अपेक्षाकृत नए (लेकिन स्पष्ट रूप से स्थिर) ext4 FS का उपयोग करके कल्पना नहीं करते हैं तो मैं JFS को एक प्रतिस्थापन के रूप में सुझाऊंगा।

Comments

क्या आपके पास NTFS फाइलसिस्टम के प्रदर्शन के लिए अच्छे संबंध हैं?

— थोरबजोरन रावन एंडरसन

हां, एक ऐप के साथ व्यक्तिगत अनुभव के अलावा, जो एक निर्देशिका में नई फ़ाइलों को बनाने में बहुत लंबा था। .. (सभी को हटाने के लिए घंटों लग गए), और एक निर्देशिका में फ़ाइलों की संख्या 1000 तक सीमित करके तोड़फोड़ प्रदर्शन को बढ़ावा देता है। या पढ़ें : support.microsoft.com/kb/130694 मुझे नहीं लगता कि उन्होंने कभी इसे "निश्चित" किया क्योंकि यह अभी भी एक पूर्ण के रूप में नोट किया गया है। NTFS के लिए ट्वीक करें।

— gbjbaanb

Answer 4

क्या प्रोफ़ाइल छवि छोटी है? शेष प्रोफ़ाइल डेटा के साथ इसे डेटाबेस में रखने के बारे में क्या? यह आपके लिए सबसे अच्छा विकल्प नहीं हो सकता है, लेकिन विचार करने लायक ...

इस विषय पर एक (पुराना) Microsoft श्वेतपत्र है: BLOB या BLOB को नहीं ।

Answer 5

मैंने एक छोटी वेब गैलरी को एक साथ हैक कर लिया है, जहाँ मैं इस समस्या का एक बदलाव के साथ समाप्त हुआ; मैं "केवल" कैश निर्देशिका में 30.000 छवियां थी, जो काफी धीमी हो गई (ext2 निर्देशिका सूचकांकों के लिए लिंक की गई सूचियों का उपयोग करता है, जैसा कि मुझे याद है)।

मैंने इन पंक्तियों के साथ कुछ करना समाप्त किया:

def key2path(key):
    hash = md5(key)
    return os.path.join(hash[0], hash[1], key)

यह डेटा को 256 निर्देशिकाओं में विभाजित करेगा, जो तीन स्तरों में से प्रत्येक के लिए एक तेज़ निर्देशिका खोज देता है।

• मैंने SHA-1 पर MD5 का उपयोग करने के लिए चुना है, क्योंकि यदि आप 32 में से किसी भी 12 बिट्स को बदलते हैं, तो MD5 एक अलग आउटपुट की गारंटी देता है, इसलिए मुझे यह हैश उपयोगकर्ता नाम, निर्देशिका और अन्य छोटे सामान के लिए एक अच्छा फिट लगता है। और यह तेज़ भी है ...
• मैं पूरे हैश को शामिल नहीं करता हूं, क्योंकि यह बहुत अधिक निर्देशिकाओं का उत्पादन करेगा और डिस्क-कैशे को प्रभावी ढंग से खत्म कर देगा।

Comments

आप शायद CRC की तरह एक सरल हैश का उपयोग कर सकते हैं, क्योंकि hash को क्रिप्टोग्राफिक रूप से MD5 या SHA की तरह मजबूत होने की आवश्यकता नहीं है ... लेकिन प्रदर्शन अंतर शायद वैसे भी नगण्य है ...

— 10-28 पर

Answer 6

आपकी समस्या का तत्काल उत्तर नहीं है, लेकिन भविष्य के संदर्भ के लिए देखने के लिए कुछ है ओपनबीडी से जुड़ी परियोजना जिसे 'एपिटोम' कहा जाता है ।

एपिटोम एक इंजन है जो सिंगल इंस्टेंस स्टोरेज, कंटेंट एड्रेसेबल स्टोरेज और डेडुप्लीकेशन सेवाएं प्रदान करता है।

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

एपिटोम वर्तमान में प्रायोगिक है, लेकिन भविष्य के लिए कुछ देखना है।

Answer 7

आम तौर पर आप बड़ी संख्या में फाइलों / निर्देशिकाओं वाली निर्देशिकाओं से बचना चाहते हैं। प्राथमिक कारण यह है कि कमांड लाइन पर वाइल्डकार्ड का विस्तार, इन निर्देशिकाओं के लिए काम करने की कोशिश करते समय "बहुत सारे तर्क" त्रुटियों के परिणामस्वरूप बहुत दर्द होगा।

एक ऐसे समाधान के लिए जाएं जो दूसरों की तरह वर्णित सबफ़ोल्डर बनाकर एक गहरा लेकिन संकरा पेड़ बनाता है।

Answer 8

हमारे पास एक समान समस्या थी, समाधान - जैसा कि पहले उल्लेख किया गया है - निर्देशिकाओं का एक पदानुक्रम बनाना है।

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

Answer 9

टाइमस्टैम्प दृष्टिकोण का उपयोग क्यों न करें, और फिर एक अतिप्रवाह विकल्प है।

उदाहरण के लिए

तो मान लीजिए कि आपका टाइमस्टैम्प है: 1366587600

अंतिम 2 अंकों को छोड़ें (या यह सिर्फ थोड़ा हास्यास्पद हो जाता है)। स्टैम्प को 4 के सेट में अलग करें (निर्देशिका गणना 9999 से अधिक नहीं होनी चाहिए - यदि आप चाहते हैं कि आप इसे अलग तरीके से अलग कर सकें)।

यह आपको कुछ इस तरह छोड़ना चाहिए:

/files/1366/5876/

फिर अपलोड करने से पहले डीआईआर के भीतर राशि की भी जांच करें, अगर यह बड़ी संख्या में अपलोड हो रहा है (यानी 32000 + प्रति 100 सेकंड), तो उदाहरण के लिए दूसरे या पत्र द्वारा निर्देशिका को पुन: व्यवस्थित करें:

/files/1366/5876/a/file.txt

या

/files/1366/5876/00/file.txt

फिर टाइमस्टैम्प + पत्र या पूर्ण पथ कोड को उपयोगकर्ता के साथ एक डीबी में लॉग इन करें और आपको सेट किया जाना चाहिए।

pathstamp: 1366587600 या 13665876a (यदि आपके पत्र का उपयोग कर रहे हैं)।

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

Answer 10

मैं यह निर्धारित करने का सुझाव दूंगा कि आपके पास माता-पिता के फ़ोल्डर में कितने अधिकतम उपनिर्देशिकाएँ हैं (या कर सकते हैं)।

फिर आपको अपनी यूजर आईडी बदलने की जरूरत है, ताकि वे 1 से शुरू हों।

तो आप कर सकते हैं: modulo = currentId % numberOfSubdirectories

moduloअब आपका उपनिर्देशिका नंबर होगा जो numberOfSubdirectoriesआपके द्वारा चुने गए से अधिक कभी नहीं होगा ।

उदाहरण के लिए, जो कुछ भी आप चाहते हैं उसे modulo के साथ करें।

इसके अलावा इस तरह से उपनिर्देशिका रैखिक रूप से भरी जाएगी।