क्या फाइलें क्रमिक रूप से डिस्क पर सहेजी जाती हैं?

Question

जैसा कि मैंने समझा, "विरल फ़ाइल" का अर्थ है कि फ़ाइल में 'अंतराल' हो सकता है, इसलिए वास्तविक उपयोग किया गया डेटा तार्किक डेटा आकार से छोटा हो सकता है।

लिनक्स फ़ाइल सिस्टम डिस्क पर फ़ाइलों को कैसे सहेजते हैं? मुझे मुख्य रूप से ext4 में दिलचस्पी है। परंतु:

1. क्या किसी फाइल को डिस्क पर क्रमिक रूप से नहीं सहेजा जा सकता है ? उसके द्वारा, मेरा मतलब है कि फ़ाइल का हिस्सा भौतिक पते X पर स्थित है और अगला भाग भौतिक पते Y पर है जो X + ऑफसेट के करीब नहीं है)।
2. क्या मैं किसी तरह फ़ाइल अनुक्रमिकता को नियंत्रित कर सकता हूं?
   मैं 10GB की एक फाइल आवंटित करना चाहता हूं। मैं चाहता हूं कि यह डिस्क पर अनुक्रमिक हो और विभिन्न ऑफसेट के बीच विभाजित न हो।
3. क्या यह विभिन्न प्रकारों के बीच अलग-अलग कार्य करता है?

Comments

आप ext4.wiki.kernel.org/index.php/Main_Page

— roaima

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

— wvxvw

यह फाइलसिस्टम का कार्यान्वयन विवरण है। लगभग सभी फाइलसिस्टम डिफ़ॉल्ट रूप से खंडित फाइल करते हैं; केवल iso9660और romfsऐसा करने में असमर्थ हैं और निरंतर भंडारण की आवश्यकता है (इनमें से मैं ऑफ-हेड को सूचीबद्ध कर सकता हूं)।

— मिराबिलोस

फ़ाइल डिस्क पर सन्निहित है या नहीं, डेटा रीड / राइट हमेशा सन्निहित होगा जब तक आप फ़ाइल के दूसरे भाग की तलाश नहीं करते। तो आप इस बारे में परवाह क्यों करते हैं? जब तक विखंडन एक गंभीर समस्या नहीं है जो प्रदर्शन को प्रभावित करती है

— phuclv

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

— यूकेको

Answer 1

क्या किसी फाइल को डिस्क पर क्रमिक रूप से नहीं सहेजा जा सकता है ? मेरा मतलब है, फ़ाइल का हिस्सा भौतिक पता X के तहत और दूसरा भाग भौतिक पता Y के अंतर्गत स्थित है जो X + ऑफसेट के करीब नहीं है)।

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

क्या मैं किसी तरह फ़ाइल अनुक्रमिकता को नियंत्रित कर सकता हूं? मैं 10GB की बड़ी फाइल आवंटित करना चाहता हूं। मैं चाहता हूं कि यह डिस्क में अनुक्रमिक हो और विभिन्न ऑफसेट के बीच विभाजित न हो।

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

क्या यह विभिन्न प्रकारों के बीच अलग-अलग कार्य करता है?

विभिन्न फाइल सिस्टम अलग-अलग व्यवहार करते हैं, हां। एनआईएलएफएस 2 जैसे लॉग-आधारित फाइलसिस्टम उसी तरह भंडारण को आवंटित नहीं करते हैं जैसे एक्सटे 4 जैसे सीमा-आधारित फाइल सिस्टम, और यह केवल भिन्नता का एक उदाहरण है।

Comments

fallocate(3)फाइल सीक्वेंटीएलिटी का उपयोग करना सुनिश्चित करेगा ? या सिर्फ फाइलसिस्टम संकेत देगा? मैं इसे पूरी तरह से मैन पेजों से नहीं समझ सकता।

— hudac

यह अनुक्रमिक आवंटन सुनिश्चित नहीं कर सकता, यह सिर्फ एक संकेत है। लेकिन अगर आप 10GiB फाइल लिख रहे हैं तो आपको इसका इस्तेमाल जरूर करना चाहिए!

— स्टीफन किट

अनिवार्य रूप से सभी फ़ाइल सिस्टम FAT की तुलना में अधिक परिष्कृत हैं - यह सभी तरह से मूल बर्कले यूएफएस पर वापस जाता है - जानबूझकर बड़ी फ़ाइलों को तोड़ देगा और उन्हें कई "आवंटन समूहों" में फैला देगा; इससे उन्हें डिस्क के समग्र विखंडन को कम करने में मदद मिलती है । यह कैसे काम करता है, इसे समायोजित करने का एक तरीका हो सकता है, लेकिन ऐसा करने के लिए आपको फ़ाइल सिस्टम को स्क्रैच से फिर से बनाना होगा, और इसमें कोई बाधा नहीं है, और संभवतः इसे पूरी तरह से बंद करने का कोई तरीका नहीं है।

— zwol

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

— मुजेर

यह भी ध्यान दें कि ऐसी परिस्थितियाँ हैं, जैसे RAID सिस्टम, जहाँ सन्निहित फाइलें कम कुशल हैं, यदि यह संभव है। मुझे लगता है कि यह वास्तव में एक डिस्क / स्टोरेज सबसिस्टम कंट्रोलर का उद्देश्य है: फाइलों को स्टोर करने के सभी कामों को उतने ही बेहतर तरीके से करना जितना कि अपेक्षित हो सकता है।

— jamesqf

Answer 2

कमांड filefragआपको बताएगी कि आपकी फ़ाइल आपके डिवाइस पर भौतिक रूप से कैसे संग्रहीत है:

# filefrag -v /var/log/messages.1 
Filesystem type is: ef53
File size of /var/log/messages.1 is 41733 (11 blocks, blocksize 4096)
 ext logical physical expected length flags
   0       0  2130567               1 
   1       1 15907576  2130568      1 
   2       2 15910400 15907577      1 
   3       3 15902720 15910401      7 
   4      10  2838546 15902727      1 eof
/var/log/messages.1: 5 extents found

यदि आप अपनी फ़ाइल एक पास में लिखते हैं, तो मेरा अनुमान है कि आपकी फ़ाइल खंडित नहीं होगी।

fallocate(1) का मैन पेज बहुत स्पष्ट है:

fallocate एक फाइल को ब्लॉक करने के लिए प्रयोग किया जाता है। फाइलसिस्टम जो fallocateसिस्टम कॉल का समर्थन करते हैं, के लिए यह जल्दी से ब्लॉक को आवंटित करके और उन्हें एकरहित के रूप में चिह्नित किया जाता है, जिसके लिए डेटा ब्लॉकों को कोई IO की आवश्यकता नहीं होती है। यह एक फ़ाइल को शून्य से भरकर बनाने की तुलना में बहुत तेज़ है।

लिनक्स कर्नेल v2.6.31 के रूप में, fallocateसिस्टम कॉल btrfs, ext4, ocfs2 और xfs फाइल सिस्टम द्वारा समर्थित है।

क्या यह अनुक्रमिक है? सिस्टम पहले ब्लॉकों को क्रमिक रूप से आवंटित करने का प्रयास करेगा। यदि यह नहीं हो सकता है, तो यह आपको चेतावनी नहीं देगा।

Comments

टाइप क्या है type ef53 ’। मैंने इसे अपनी फाइलों पर भी देखा। लेकिन मेरे एफएस प्रकार है ext4।

— 16

EF53 ext2, ext3 और ext4 की "SUPER_MAGIC" संख्या है। हर फाइल-सिस्टम के सभी मैजिक नंबरों के लिए कर्नेल स्रोतों में "शामिल / यूपीआई / लिनेक्स / मैजिक.एच" देखें।

— वॉयज

डेबियन पर, filefragमें छिपा हुआ है /usr/sbin। लेकिन यह सामान्य उपयोगकर्ताओं (ext4, कम से कम) के लिए काम करता है। यह straceअपने ऑपरेशन के लिए शिक्षाप्रद हो सकता है कि यह देखने के लिए कि आपके लिए विखंडन कैसे मापें, अगर चेतावनी की कमी आपके लिए एक बाधा है।

— टोबे स्पाइट

Answer 3

आप विरल फ़ाइलों का उल्लेख करते हैं, और अन्य किसी भी उत्तर ने उनका उल्लेख नहीं किया है।

अधिकांश फाइलें विरल नहीं हैं। फ़ाइल बनाने का सबसे आम तरीका यह है कि इसे शुरू से अंत तक एक ही बार में लिखा जाए। वहां कोई छेद नहीं।

हालाँकि, आपको यह कहने की अनुमति दी गई है कि "1,000,000,000,000 की स्थिति में ले जाएँ और वहाँ एक बाइट लिखें।" यह एक फाइल बनाएगा जो ऐसा दिखता है कि यह एक एटैबाइट बड़ा है, लेकिन वास्तव में डिस्क पर केवल (शायद) 4k का उपयोग करता है। यह एक विरल फ़ाइल है।

आप एक ही फ़ाइल के लिए यह कई बार कर सकते हैं, जिससे बड़ी मात्रा में खाली डेटा बिखरा हुआ है।

जबकि यह उपयोगी हो सकता है, दो डाउनसाइड हैं।

पहला यह है कि फ़ाइल खंडित हो जाएगी, जिसके बारे में आप चिंतित हैं।

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

Comments

लेकिन यहां तक ​​कि एक गैर-विरल फ़ाइल भी अक्सर डिस्क पर सन्निहित नहीं होगी।

— बमर

Answer 4

क्या मैं किसी तरह फ़ाइल अनुक्रमिकता को नियंत्रित कर सकता हूं? मैं 10GB की फाइल आवंटित करना चाहता हूं। मैं चाहता हूं कि यह डिस्क पर अनुक्रमिक हो और विभिन्न ऑफसेट के बीच विभाजित न हो।

इसे प्राप्त करने के लिए कम से कम कुछ तरीके हैं।

1. बहुत सारे खाली स्थान के साथ एक फाइल सिस्टम का उपयोग करें और अंतरिक्ष का प्रचार करें (जैसे कि एप्लिकेशन विशिष्ट एंड-ऑफ-डेटा मार्कर का उपयोग करें और यादृच्छिक डेटा को 10GB तक पहुंचने तक संलग्न करें)। यह असंगत डेटा में परिणाम की गारंटी नहीं है।

2. Ext4 आदि के बजाय कच्चे (बिना पके) फाइलसिस्टम का प्रयोग करें । DBMSs कभी-कभी प्रदर्शन कारणों से ऐसा करते हैं। ट्रेडऑफ आपको जरूरत पड़ने पर अपनी खुद की कैशिंग / जर्नलिंग / रिकवरी आदि करने के लिए करना है।

ऐसे उदाहरण जहां आप ऐसा करने से बहुत लाभान्वित होते हैं, अपेक्षाकृत दुर्लभ हैं - मैं पहले प्रदर्शन को अनुकूलित करने के लिए कहीं और देखूंगा।

---

यह भी देखें

क्या यह सच है कि डेटाबेस मैनेजमेंट सिस्टम आमतौर पर फाइल सिस्टम को बायपास करता है?

Answer 5

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

Comments

"डीफ़्रेग्मेंटर चलाएं"? क्या ऐसा कोई कार्यक्रम है? जब मैंने खोजा तो केवल वही चीज मिली aptitude search ~ddefragथी ddrescueviewऔर nidsTCP खंड reassembly पुस्तकालय था। यदि आप यह नहीं कहते हैं कि कार्यक्रम को क्या कहा जाता है, या क्या तर्क पारित करने की आवश्यकता है, तो आपका उत्तर बहुत उपयोगी नहीं है।

— टॉबी स्पीट

@ टॉबीस्पाइट - हाँ एक डीफ़्रेग्मेंटर है; e4defrag।

— ravery