जिस तरह से टीएल, डॉ
आपका आरेख अनिवार्य रूप से सही है।
/dev/<device> फ़ाइलें
मुझे लगता है कि आपके प्रश्न का उत्तर देना शुरू करने का सबसे मूल तरीका क्या /dev/<device>फाइलें हैं। कहते हैं कि आपके पास एक हार्ड डिस्क है। इस हार्ड डिस्क में एक एमबीआर-आधारित विभाजन तालिका है, और इसमें दो विभाजन हैं, एक इस पर कुछ फ़ाइलों के साथ ext4 स्वरूपित है, और दूसरा LVM के लिए सेट किया गया है। ध्यान दें कि यह उत्तर ऑन-द-फ्लाई डिवाइस फ़ाइल निर्माण के बारे में बात करता है, जिसका अर्थ है कि आप लिनक्स कर्नेल का उपयोग कर रहे हैं। अन्य यूनियनों पर चीजें थोड़ी अलग हैं ।
जब आप इस हार्ड डिस्क को प्लग करते हैं (या जब सिस्टम बूट-टाइम पर इसका पता लगाता है) तो /devडायरेक्टरी में एक डिवाइस फाइल बनाई जाएगी - जिसे आम तौर पर /dev/sd*या तो कॉल किया जाता है /dev/hd*(ड्राइव कनेक्ट करने के लिए किस कंट्रोलर के आधार पर इस्तेमाल किया जाता है) - * एक * है पत्र। डिवाइस फ़ाइल पर बाइट्स को अनिवार्य रूप से भौतिक डिस्क पर बाइट्स के लिए रैखिक रूप से मैप किया जाता है: यदि आप डिवाइस फ़ाइल की शुरुआत में लिखने के लिए एक उपकरण का उपयोग करते हैं, तो वह डेटा भौतिक डिस्क की भौतिक शुरुआत के लिए भी लिखा जाएगा।
अब, सिस्टम MBRs और GPT जैसी विभाजन सारणी को भी समझता है। एक बार प्रारंभिक डिवाइस फ़ाइल बन जाने के बाद, यह निर्धारित करने के लिए पढ़ा जाएगा कि उसमें विभाजन तालिका है या नहीं। यदि ऐसा होता है, तो इन विभाजनों का प्रतिनिधित्व करने वाली डिवाइस फाइलें बनाई जाएंगी। इसलिए यह मानते हुए कि मूल डिवाइस फ़ाइल को कॉल किया गया था /dev/sda, नामक एक डिवाइस फ़ाइल /dev/sda1बनाई जाएगी (पहले, एक्सटेट 4 स्वरूपित विभाजन का प्रतिनिधित्व), साथ ही एक /dev/sda2डिवाइस (दूसरा एलवीएम विभाजन का प्रतिनिधित्व)। इन्हें पूरे ड्राइव की तरह ही उनके संबंधित विभाजनों में रैखिक रूप से मैप किया जाता है - अर्थात, यदि आप एक उपकरण का उपयोग करते हैं (उदाहरण के लिए) लिखने की शुरुआत के लिए /dev/sda2, तो लिखा गया डेटा भौतिक रूप से दूसरे विभाजन की शुरुआत में लिखा जाएगा। , जो वास्तव में मध्य है पूरी डिस्क की, क्योंकि दूसरा विभाजन शुरू होता है।
ब्लॉक और सेक्टर
यह ब्लॉकों और क्षेत्रों के बारे में बात करने के लिए एक सुविधाजनक समय है: ये सिर्फ एक भौतिक डिस्क पर अंतरिक्ष का माप हैं, इससे अधिक और कुछ नहीं (कम से कम अगर मैं सही ढंग से)। एक सेक्टर हार्ड ड्राइव पर एक भौतिक क्षेत्र है; यह आमतौर पर 512 बाइट्स - नए हार्ड ड्राइव पर 4 केबी है। एक ब्लॉक भी माप की एक इकाई है, यह लगभग हमेशा 8 KB है। जब कोई ब्लॉक को पढ़ने और लिखने के बारे में बात करता है, तो इसका मतलब है कि प्रत्येक बाइट को व्यक्तिगत रूप से पढ़ने के बजाय, वे 8 केबी के आंकड़ों में डेटा को पढ़ते हैं और लिखते हैं।
फाइलसिस्टम और इनोडेस
अगला, फाइलसिस्टम और इनोडेस। एक फाइलसिस्टम एक काफी सरल अवधारणा है: उस क्षेत्र की शुरुआत में जिसमें फाइल सिस्टम रहता है (यह क्षेत्र आमतौर पर एक विभाजन होता है), फाइल सिस्टम पर जानकारी का एक गुच्छा होता है। यह शीर्षलेख (जिसे सुपरब्लॉक के रूप में भी जाना जाता है, मेरा मानना है) का उपयोग सबसे पहले यह निर्धारित करने के लिए किया जाता है कि फाइल सिस्टम को पढ़ने के लिए किस फाइलसिस्टम ड्राइवर का उपयोग किया जाना चाहिए, और फिर इसका उपयोग फाइलों को पढ़ने के लिए चुने गए फाइलसिस्टम चालक द्वारा किया जाता है। यह एक सरलीकरण है, ज़ाहिर है, लेकिन यह मूल रूप से दो चीजों को संग्रहीत करता है (जो डिस्क पर दो अलग-अलग डेटा संरचनाओं के रूप में संग्रहीत किया जा सकता है या नहीं, एफएस प्रकार के आधार पर): निर्देशिका ट्री और इनोड्स की सूची। निर्देशिका ट्री वह है जो आप देखते हैं जब आप एक lsया एक करते हैंtree। डायरेक्टरी ट्री में कहा गया है कि कौन सी फाइलें और डायरेक्टरी हैं जो अन्य डायरेक्टरी के बच्चे हैं। फ़ाइल / डायरेक्टरी पैरेंट-चाइल्ड रिलेशनशिप UNIX डायरेक्टरी ट्री बनाती है जैसा कि हम जानते हैं।
लेकिन डायरेक्टरी ट्री में केवल नाम शामिल हैं। वे नाम अतिरिक्त रूप से इनोड संख्या के साथ जुड़े हुए हैं। एक इनकोड संख्या में जानकारी होती है जैसे कि फ़ाइल के टुकड़े डिस्क पर भौतिक रूप से संग्रहीत हैं। अपने आप में एक एनोड केवल एक फ़ाइल है जिसका कोई नाम नहीं है; एक इनकोड डायरेक्टरी ट्री के माध्यम से एक नाम के साथ जुड़ा हुआ है। यह भी देखें कि एक सुपरब्लॉक, इनोड, डेंट्री और एक फाइल क्या है?
अब तक, हमारे पास निम्नलिखित स्पष्टीकरण है: /dev/sd*फाइल हार्ड ड्राइव पर /dev/sd*#मैप्स , फाइल मैप पर पार्टीशन नंबर #पर /dev/sd*। एक फाइलसिस्टम डिस्क पर एक डेटा संरचना है जो एक निर्देशिका ट्री का ट्रैक रखता है; यह आम तौर पर एक विभाजन ( /dev/sd*#) में रखा जाता है । एक फाइलसिस्टम में इनोड होते हैं; इनकोड संख्याएं होती हैं जो फाइलों का प्रतिनिधित्व करती हैं, साथ ही उन फाइलों से जुड़े डेटा (उनके नाम और डायरेक्टरी ट्री में स्थिति के अलावा)।
यह ध्यान देने योग्य है कि फाइलसिस्टम आमतौर पर ब्लॉक में डेटा का ट्रैक रखते हैं। आमतौर पर, डायरेक्टरी ट्री और इनोड लिस्ट को बाइट्स में रखा जाता है, बाइट्स में नहीं, और इनसाइड डिस्क पर ब्लॉक्स को इंगित करता है, बाइट्स को नहीं। (यह उन समस्याओं का कारण बन सकता है जहां फाइलें आम तौर पर अंतरिक्ष के आधे ब्लॉक को बर्बाद करती हैं, क्योंकि फाइल सिस्टम ने एक संपूर्ण ब्लॉक आवंटित किया है लेकिन फाइल के अंतिम भाग के लिए उस पूरे ब्लॉक का उपयोग करने की आवश्यकता नहीं है।)
डिवाइस मैपर
पहेली का अंतिम टुकड़ा लिनक्स कर्नेल में एक बहुत ही महत्वपूर्ण मॉड्यूल है जिसे डिवाइस मैपर कहा जाता है (इसे लोड करें modprobe dm)। डिवाइस मैपर मूल रूप से आपको /dev/mapperनिर्देशिका में एक और डिवाइस फ़ाइल बनाने देता है । उस डिवाइस फ़ाइल को तब डेटा के किसी अन्य स्रोत पर मैप किया जाता है, संभवतः प्रक्रिया में रूपांतरित हो रहा है। सबसे सरल उदाहरण एक फ़ाइल के एक हिस्से को पढ़ रहा है।
कहते हैं कि आपके पास एक पूर्ण-डिस्क छवि है, जो विभाजन तालिका के साथ पूर्ण है। आपको छवि में विभाजन में से एक से डेटा को पढ़ने की आवश्यकता है, लेकिन आप केवल एक विभाजन छवि के बजाय पूर्ण डिस्क छवि के बाद से उस विभाजन को प्राप्त नहीं कर सकते । समाधान यह है कि आपके विभाजन में छवि कहां है, और फिर डिस्क छवि के उस हिस्से में एक नया डिवाइस फ़ाइल मैपिंग बनाएं। यहाँ एक चित्र है:
.-------------------.
| /dev/mapper/foo | <- This is the device file created with the device mapper
.___________________.
\ /
\ /
\ / <- This is a small section of the image being mapped to
\ / the new device file
\ /
\ /
.------------------.
| diskimage.img | <- This is the full-disk image. It's a regular file.
.__________________. Notice how the mapping goes to _part_ of the file.
इसके बारे में सोचने का एक और तरीका परिवर्तन पाइपलाइन की तरह है (यह कर्नेल में आंतरिक रूप से क्या हो रहा है, इसके लिए अधिक सटीक रूपक है)। एक कन्वेयर बेल्ट की कल्पना करें। एक अनुरोध - एक रीड, एक लेखन, आदि - कन्वेयर बेल्ट के एक छोर पर शुरू होता है, डिवाइस मैपर के साथ बनाई गई डिवाइस फ़ाइल पर। अनुरोध तब स्रोत फ़ाइल के लिए डिवाइस मैपर परिवर्तन के माध्यम से यात्रा करता है। उपरोक्त उदाहरण में, इस स्रोत फ़ाइल, एक नियमित रूप से फ़ाइल है diskimage.img। यहाँ चित्र है:
Read operation goes onto
device mapper conveyor belt
read() The device mapper transforms the read The modified read request finally
\ request by moving the requested region reaches the source file, and the data
\ Beginning of conveyor belt to read forward by some number of bytes. is retrieved from the filesystem.
\
\ .-------------------. .--------------------------. .------------------------.
\ | /dev/mapper/foo | | Transformation logic | | /path/to/diskimage.img |
\ .___________________. .___+_____+_____+_____+____. .________________________.
\-->
---------------------------------------------------------------------------------------------------------------
o o o o o o o o o o o
ध्यान दें कि आरेख में, डिवाइस मैपर के साथ हुक किए गए ट्रांसफ़ॉर्मेशन लॉजिक +में रीड रिक्वेस्ट को हेरफेर करने के लिए बहुत सारे उपकरण होते हैं क्योंकि यह कन्वेयर बेल्ट पर चलता है।
अब, मैं विशेष रूप से उस आरेख को कॉपी करने और LVM के लिए इसे संशोधित करने का अनुभव नहीं करता हूं, लेकिन मूल रूप से, परिवर्तन का हिस्सा कुछ भी हो सकता है - न केवल बाइट रेंज को आगे स्थानांतरित करना। यह है कि LVM कैसे काम करता है: LVM भौतिक विस्तार LVM का वह भाग है जो डिस्क पर बैठता है और डेटा का ट्रैक रखता है। इसे LVM के फाइल सिस्टम की तरह समझें। कन्वेयर बेल्ट रूपक में, एक भौतिक विस्तार स्रोत फ़ाइलों में से एक है, और डिस्क पर भौतिक डेटा के लिए लॉजिकल वॉल्यूम (जो कन्वेयर बेल्ट पर सबसे बाईं ओर आइटम है) पर एक अनुरोध को मैप करते हुए LVM अपना काम कर रहा है। बाते कर रहे हैं जिससे कि...
मैं अपने LVM अवधारणाओं पर थोड़ा कठोर हूँ, लेकिन IIRC, वॉल्यूम समूह अनिवार्य रूप से LVM में एक डिस्क की तरह है। फिर, IIRC, RAID स्तर, आदि को वॉल्यूम समूह के अनुसार प्रबंधित किया जाता है। एक लॉजिकल वॉल्यूम, तब एक विभाजन की तरह है, और लॉजिकल वॉल्यूम वे हैं जो वास्तव में डिवाइस फ़ाइलों का प्रतिनिधित्व करते हैं। आप फाइलसिस्टम और सामान को लॉजिकल वॉल्यूम पर रखें।
डिवाइस मैपर के बारे में अच्छी बात यह है कि इसके साथ निर्मित तर्क को डेटा स्टैक में मनमाने ढंग से डाला जा सकता है - आपको बस इतना करना है कि आप जिस डिवाइस का नाम पढ़ रहे हैं उसे बदल दें। यह है कि एन्क्रिप्टेड विभाजन कैसे काम करते हैं ( एन्क्रिप्शन योजनाएं जो फ़ाइल स्तर पर काम नहीं करती हैं - वे FUSE का उपयोग करते हैं), और यह है कि LVM कैसे काम करता है। मैं इस समय किसी भी अन्य उदाहरण के बारे में नहीं सोच सकता, लेकिन मुझ पर विश्वास करो, डिवाइस मैपर बहुत बदमाश है।
लॉजिकल ब्लॉक एड्रेसिंग
मैंने इसके बारे में कभी नहीं सुना, इसलिए मैं इस पर कोई जानकारी नहीं दे सकता। उम्मीद है कि कोई व्यक्ति इस उत्तर को संपादित करके आएगा।