बढ़ते की अवधारणा को समझने में परेशानी

13

दोनों को पढ़ने के बाद लिनक्स में डिवाइस माउंट करने का क्या मतलब है? और ओएस में एक अवधारणा के रूप में "माउंट" को समझना , मुझे एक समस्या है जहां यह कहा गया है कि

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

लेकिन कहने के लिए पहले से ही एक सुलभ स्थान / देव / सीडीआरएम के तहत एक सीडीआरएम ड्राइव है जो स्पष्ट रूप से निर्देशिका पदानुक्रम में आता है। तो / मीडिया / सीडीआरएम के तहत एक अलग "माउंट पॉइंट" बनाने की आवश्यकता क्यों है? / Dev / cdrom से सीधे एक्सेस करना असंभव क्यों है? मैंने सुना है कि डिवाइस नोड फाइलें साधारण फाइलों की तरह हैं। और उन्हें पढ़ना और लिखना साधारण फाइलों की तरह है। तो क्या इसका मतलब यह है कि यदि हम इसे / dev / cdrom से एक्सेस करते हैं तो cdrom में फाइल सिस्टम उपलब्ध नहीं है। और फाइलसिस्टम पदानुक्रम (सीडीरोम के अंदर) "जीवित" आता है जब हम इसे "माउंट" करते हैं?

linux mount devices

— sounak
स्रोत

11

आप पढ़ सकते हैं या लिख सकते हैं / देव / cdrom (उदाहरण के लिए, का उपयोग कर ddया cat) लेकिन जब आप ऐसा करते हैं कि आप डिवाइस के कच्चे बाइट्स को पढ़ रहे हैं या लिख रहे हैं। यह विभिन्न परिस्थितियों में उपयोगी हो सकता है (जैसे विभाजन को क्लोन करना), लेकिन आम तौर पर हम डिवाइस पर संग्रहीत निर्देशिकाओं और फाइलों को देखना चाहते हैं।

जब आप एक डिवाइस माउंट करते हैं तो आप मूल रूप से उन कच्चे बाइट्स को वास्तविक फाइल सिस्टम में अनुवाद करने के लिए सॉफ्टवेयर (फाइलसिस्टम ड्राइवर) की एक परत का उपयोग करने के लिए कर्नेल को बता रहे हैं। इस प्रकार एक डिवाइस बढ़ते फाइल डिवाइस को डायरेक्टरी पदानुक्रम में फाइल सिस्टम से जोड़ता है।

— दोपहर 2 बजे
स्रोत

8

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

फाइलसिस्टम में निर्देशिका और फाइलें हैं, और प्रत्येक फाइल बाइट्स के कुछ स्ट्रिंग के लिए एक लेबल है।
/dev/cdrom एक फाइल है, यह सीडी पर संग्रहीत बाइट्स के स्ट्रिंग का प्रतिनिधित्व करता है।
आप इसे बहुत लंबे स्ट्रिंग को सीधे पढ़ सकते हैं, लेकिन विशेष प्रयोजनों (जैसे एक पूर्ण डिस्क छवि बनाना) को छोड़कर यह बहुत व्यावहारिक नहीं है।
इस लंबी स्ट्रिंग में अतिरिक्त आंतरिक संरचना होती है: इसमें एक फाइल सिस्टम होता है, जिसमें इस बात की जानकारी होती है कि कौन सी निर्देशिकाओं और फाइलों को संग्रहीत किया जाता है और इस बहुत लंबे स्ट्रिंग में कहां।
उपयोग करके mount -t iso9660 /dev/cdrom /media/cdrom, आप सिस्टम को बताते हैं: "बाइट्स की यह बहुत लंबी स्ट्रिंग लें, जो आपके पास है /dev/cdrom, इसे iso9660 प्रारूप में एक निर्देशिका ट्री के रूप में व्याख्या करें, और मुझे इसे स्थान के तहत एक्सेस करने की अनुमति दें /media/cdrom"।
वास्तव में, यह नियमित फ़ाइलों के लिए भी काम करता है। आप एक नियमित फ़ाइल बना सकते हैं जिसमें एक डिस्क छवि होती है, और फिर mountइसे एक्सेस करने के लिए उपयोग करें। इसे इस्तेमाल करे:

dd if = / dev / zero of = fs-image bs = 1M count = 50
mke2fs fs-image
सुडो माउंट एफएस-छवि / कुछ / माउंट / बिंदु

(छवि फ़ाइल तैयार करते समय पहले दो कमांड केवल पहली बार आवश्यक हैं।)

— Krzysztof Kosiński
स्रोत

आपको जरूरत क्यों पड़ी mke2fs?

— ADTC

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

— Krzysztof Kosiński

ओह ठीक है, यह एक संभावित विनाशकारी कार्रवाई है। आप का उल्लेख है कि यह आदेश केवल पहली बार प्रारंभ करने के लिए है। :)

— ADTC

5

/dev/cdromएक डिवाइस फ़ाइल को संदर्भित करता है । यह आपके ऑप्टिकल ड्राइव में डालने की इच्छा रखने वाली किसी भी डिस्क की सामग्री नहीं है , बल्कि यह हार्डवेयर (और शायद सॉफ़्टवेयर ड्राइवरों) के बिट का संदर्भ है जिसे आप दिखाने के लिए कॉल कर सकते हैं। जब आप mount /dev/cdromअपने पेड़ में कुछ पथ पर जाते हैं तो आप इसकी सामग्री को आपके फाइल सिस्टम से जोड़ देते हैं ।

बात यह है - मैं वास्तव में इसे करने का दूसरा तरीका नहीं सोच सकता। विंडोज में भी - हालांकि यह उतना स्पष्ट नहीं है - इसके लिए अभी भी फाइलसिस्टम एब्स्ट्रक्शन है \\?\volumename\। मुझे यह याद रखने में एक मिनट का समय लगा कि मैं कैसा दिख रहा था, और मुझे यह गुगली लगा ।

... वॉल्यूम नाम सिर्फ एक प्रतीकात्मक लिंक है जो एक वास्तविक वॉल्यूम डिवाइस पर वापस इंगित करता है, आमतौर पर के रूप में \Device\HarddiskVolume23। MS-DOS डिवाइस का एक और उदाहरण है जो ड्राइव अक्षर है। यदि आपके वॉल्यूम में C: ड्राइव अक्षर है, तो आपके पास एक प्रतीकात्मक लिंक होगा \\?\C: जिसे \Device\HarddiskVolumeXXप्रारूप में एक वास्तविक वॉल्यूम इंगित करता है।

और इसलिए शायद यह सब अलग नहीं है - हालांकि मैं कम जटिल बहस करूंगा - यह सिर्फ अधिक स्पष्ट है , मुझे लगता है। वे एक और एक ही प्रणाली नहीं हैं, लेकिन वे मौलिक रूप से अलग नहीं हैं, या तो।

शायद सबसे महत्वपूर्ण के बीच अंतर /dev/deviceऔर /path/to/its/mountहै कि बाद के पथ एक फ़ाइल-प्रणाली पर है - सॉफ्टवेयर के कुछ बिट एक संगठित तरीके में डेटा को संभाल करने का इरादा - पूर्व की सामग्री की व्याख्या कर रहा है। आप बस एक डिस्क को नहीं पढ़ सकते हैं - किसी को यह आपको पढ़ने के लिए मिला है। फाइलसिस्टम उपकरण की सामग्री की व्याख्या करता है।

— mikeserv
स्रोत

यह कुछ भ्रामक है। यदि आप /dev/cdromएक हेक्स संपादक में खोलते हैं , तो यह वास्तव में CD-ROM की कच्ची सामग्री को समाहित करता है। mountआप का उपयोग करके बस ओएस को उन सामग्रियों को एक निर्देशिका पेड़ के रूप में व्याख्या करने के लिए कहें।

— क्रिज़ीस्तोफ़ कोसीकोस्की

0

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

दी गई, केवल-पढ़ने के लिए डिवाइस के लिए यह कम समझ में आता है, लेकिन यह अभी भी लागू होता है।

— जो सेवेल
स्रोत