किसी मौजूदा निर्देशिका पर माउंट क्यों होता है?


52

माउंट पॉइंट के रूप में एक मौजूदा निर्देशिका की आवश्यकता है ।

$ ls
$ sudo mount /dev/sdb2 ./datadisk
mount: mount point ./datadisk does not exist
$ mkdir datadisk
$ sudo mount /dev/sdb2 ./datadisk
$

मुझे यह भ्रामक लगता है क्योंकि यह निर्देशिका की मौजूदा सामग्री को ओवरले करता है। माउंट पॉइंट डायरेक्टरी की दो संभावित सामग्रियां हैं जो अप्रत्याशित रूप से स्विच हो सकती हैं (एक उपयोगकर्ता के लिए जो माउंट का प्रदर्शन नहीं कर रहा है)।

mountनव निर्मित निर्देशिका में क्यों नहीं होता है? यह तरीका है कि ग्राफ़िकल ऑपरेटिंग सिस्टम हटाने योग्य मीडिया कैसे प्रदर्शित करते हैं। यह स्पष्ट होगा कि यदि निर्देशिका आरोहित है (मौजूद है) या माउंट नहीं है (मौजूद नहीं है)। मुझे पूरा यकीन है कि एक अच्छा कारण है लेकिन मैं अभी तक इसे खोज नहीं पाया हूं।


1
यदि आप चाहते हैं कि व्यवहार, उपयोग करें udisksctl। क्यों उपयोग करें mount?
मूरू

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

8
एक ऐतिहासिक नोट के रूप में, विंडोज और LInux से पहले अन्य सभी ओएस को कुचल दिया गया था, अपोलो नामक एक कंपनी थी। उन्होंने यूनिक्स-अलाइक (यूनिक्स से बेहतर डिजाइन!) ऑपरेटिंग सिस्टम लिखा। इसने उन निर्देशिकाओं का निर्माण किया जिन पर NFS का निर्यात अपने आप बढ़ गया। वास्तव में, आप पहले से मौजूद निर्देशिका पर माउंट नहीं कर सकते। एचपी ने अपोलो को खरीदा, ऑपरेटिंग सिस्टम को फेंक दिया, और अपोलो के 64-बिट सीपीयू को एचपी-पीए के रूप में इस्तेमाल किया। दूरस्थ प्रक्रिया कॉल की अपोलो प्रणाली OSF की DCE बन गई, जो जाहिर तौर पर विंडोज के अंदर रहती है। जानना केवल आधी लड़ाई है!
ब्रूस एडगर

किसी तरह यह मेरे ubuntu 14.04,3 ​​सिस्टम पर होता है। मैंने अभी तक जांच नहीं की है। जब मेरा एसडी कार्ड माउंट हो जाता है, तो यह एक ऐसे रास्ते पर समाप्त हो जाता है, जिसमें कुछ भी नहीं होता है। अगर मैं इसे umount करता हूं और मैन्युअल रूप से इसे वापस माउंट करने का प्रयास करता हूं, तो मुझे जो त्रुटि मिलती है वह माउंट बिंदु पर कोई निर्देशिका नहीं है।
स्कैपरन

2
@ ब्रूसडाइगर better design than Unix![उद्धरण वांछित]
रुस्लान

जवाबों:


51

यह एक कार्यान्वयन विवरण का मामला है जो लीक हो गया है।

UNIX प्रणाली में, प्रत्येक निर्देशिका में इनोड संख्याओं के लिए मैप किए गए नामों की सूची होती है । एक इनकोड मेटाडेटा रखता है जो सिस्टम को बताता है कि क्या यह एक फाइल, डायरेक्टरी, स्पेशल डिवाइस, पाइप, आदि का नाम है। यदि यह एक फाइल या डायरेक्टरी है, तो यह सिस्टम को यह भी बताता है कि डिस्क पर फाइल या डायरेक्टरी कंटेंट कहां खोजे। अधिकांश इनकोड्स फाइलें या निर्देशिकाएं होती हैं। इनकोड संख्याओं को सूचीबद्ध -iकरने का विकल्प ls

एक फाइलसिस्टम को माउंट करने से एक डायरेक्टरी इनोड लेता है और कर्नेल की इन-मेमोरी कॉपी पर एक झंडा लगाता है, ताकि यह कहा जा सके कि "वास्तव में, जब इस डायरेक्टरी की सामग्री की तलाश है तो इसके बजाय अन्य फाइल सिस्टम को देखें" ( इस प्रस्तुति की स्लाइड 10 देखें )। यह अपेक्षाकृत आसान है क्योंकि यह एकल डेटा आइटम को बदल रहा है।

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

यदि आप गतिशील रूप से निर्मित माउंट पॉइंट चाहते हैं, तो automountसिस्टम ऐसा कर सकता है। विशेष गैर डिस्क फ़ाइल सिस्टम भी होगा पर निर्देशिका बना सकते हैं, जैसे proc, sys, devfsऔर इतने पर।

संपादित करें: यह भी देखें कि जब आप किसी मौजूदा फ़ोल्डर को सामग्री के साथ माउंट करते हैं तो क्या होता है?


सिवाय यह इनोड पर एक ध्वज सेट नहीं करता है। sudo mount --bind / /mnt ; ls /mnt/proc-> खाली। मुझे आश्चर्य है कि यह कैसे काम करता है।
sourcejedi

सटीक ऑपरेशन में है fs/namespace.c, मुझे लगता है; मैं स्रोत से परिचित नहीं हूं और विस्तार से ड्रिलिंग पर बहुत लंबा समय नहीं बिताना चाहता। "इनोड पर ध्वज" मुझे जुड़ी हुई प्रस्तुति से मिला।
pjc50

2
@sourcejedi: bind mounts केवल उस फाइल सिस्टम को बाँधता है जिसे आप वास्तव में संदर्भित करते हैं। वे पुन: इसके तहत माउंट किए गए अन्य फाइल सिस्टम को पुन: बांधते नहीं हैं। यह माउन्ट्स द्वारा छिपाए गए कबाड़ को खोजने का एक आसान तरीका है। (उदाहरण के लिए अगर कुछ सामान रूट एफएस पर समाप्त हो गया है /var/cacheजब /varमाउंट करने में विफल रहा है।) यह भी देखें path_resolution(7)। (पुराने linux-manpages में वह आदमी पेज था जैसे कि अनुभाग 2 में, die.net की तरह) IDK वास्तव में कैसे लिनक्स आंतरिक रूप से काम करता है, प्रत्येक निर्देशिका घटक को संभावित माउंट के रूप में जाँचने के लिए। शायद कि VFS प्रविष्टि कैश में पिन करें?
पीटर कॉर्ड्स

2
fs/namei.cहालाँकि , यह मेरी बात है ... इसलिए (पथ -> इनोड लुकअप) नामस्थान में कॉल करता है lookup_mnt()। डेंट्री (निर्देशिका कैश प्रविष्टि) पर एक ध्वज है। लेकिन यह सिर्फ एक अनुकूलन उर्फ ​​कार्यान्वयन विवरण है। यह आपको नहीं बताता है कि कौन सी फाइलसिस्टम आरोहित है; आपको माउंट टेबल में देखना होगा। (अधिक कार्यान्वयन विवरण के लिए देखें m_hash (), लिनक्स, कम से कम, अतिरिक्त स्ट्रिंग तुलनाओं से बचा जाता है, और AFAICS एक ही समय में डेंट्री के पार करने के लिए प्रबंधन करता है जैसे कि बाइंड माउंट, क्योंकि यह जादूगरों द्वारा लिखा गया है)।
sourcejedi

1
@PeterCordes: : man 8 mount mount --bind foo fooबाइंड mountकॉल केवल एक फाइल सिस्टम का (केवल एक हिस्सा) देता है, संभव सबमाउंट नहीं। उप attached mounts सहित पूरी फ़ाइल पदानुक्रम का उपयोग करके एक दूसरे स्थान से जुड़ी हुई है :mount --rbind olddir newdir
mikeserv

19

यदि माउंट बिंदु होने के लिए नई निर्देशिका के निर्माण की mount(2) आवश्यकता है, तो आप केवल पढ़ने के लिए फाइलसिस्टम के तहत कुछ भी माउंट नहीं कर सकते हैं। वह गूंगा होगा, इसलिए हम उस पर शासन कर सकते हैं।

यदि माउंट ने माउंटपॉइंट होने के लिए वैकल्पिक रूप से एक नई निर्देशिका बनाई, तो यह अजीब होगा। यह हर समय माउंट / अनमाउंट नहीं होता है, इसलिए कर्नेल में इन दो चरणों को एक सिस्टम कॉल के साथ करने के लिए अतिरिक्त तर्क रखना एक महत्वपूर्ण स्पीडअप नहीं होगा। mkdir(2)अगर यह चाहता है तो सिस्टम कॉल करने के लिए इसे केवल यूजर-स्पेस तक छोड़ दें । दिमित्री का जवाब बताता है कि mount(2)दोनों चीजें करने से यह गैर-परमाणु बन जाएगा। और आप mount(2)मोड के झंडे के साथ एक अतिरिक्त तर्क चाहते हैं open(2), जैसे कि , आदि के लिए O_CREAT, O_EXCLयह उपयोगकर्ता-स्थान को ऐसा करने की तुलना में मूर्खतापूर्ण होगा।

या हो सकता है आप mount(8)(पारंपरिक कार्यक्रम जो mount(2)सिस्टम कॉल करता है) ऐसा करने के बारे में पूछ रहे थे ? यह संभव होगा, लेकिन mkdir(1)नौकरी के लिए पहले से ही पूरी तरह से अच्छा है , और यूनिक्स का डिज़ाइन सभी अच्छे छोटे उपकरणों के बारे में है जो संयुक्त हो सकते हैं। यदि आप ऐसा टूल चाहते हैं जो दोनों करता है, तो उस टूल को दो सरल टूल से बनाने के लिए शेल स्क्रिप्ट लिखना आसान है। (या, जैसा कि मौरू ने टिप्पणी की है, udisksctlपहले से ही ऐसा करता है, इसलिए आपको इसे लिखने की ज़रूरत नहीं है।) इसके अलावा, लिनक्स का सामान्य उपयोग mount(8)- लिनेक्स से समर्थन करता है, mount -o x-mount.mkdir[=mode]यह उपयोगकर्ताओं के x-लिए विकल्पों के सिंटैक्स का उपयोग करता है , बजाय फाइलों के सिस्टम में पारित होने के लिए।


अब और अधिक दिलचस्प सवाल: माता-पिता फाइल सिस्टम पर एक निर्देशिका क्यों होना चाहिए?

जैसे pjc50 का उत्तर बताता है (कोई संबंध नहीं है, भले ही उसके पास मेरे प्रारंभिक हैं!), माउंट पॉइंट्स को डायरेक्टरी लिस्टिंग में दिखाते हैं, फिर हर पर एक अतिरिक्त जांच की आवश्यकता होगी readdir()

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


1
If mount(2) required the creation of a new directory to be the mount point, you couldn't mount anything under a read-only filesystem. That would be dumb- मैं इसे बेहतर तरीके से बहस करूंगा: उपयोगकर्ता के दृष्टिकोण से, केवल-पढ़ने के लिए कोई फ़ाइल सिस्टम नहीं बदलना चाहिए, लेकिन माउंट की अनुमति देने का मतलब यह हो सकता है
इज़काटा

2
@ इज़काटा: एक फाइलसिस्टम को केवल पढ़ने के लिए बनाने का मतलब यह नहीं है कि वीएफएस की पूरी सबट्री जमी हुई है। पठन-लेखन निर्देशिकाओं की ओर इशारा करते हुए यह सहानुभूति हो सकती है, या पहले से ही इसके तहत पठन-लेखन माउंट बिंदु हैं जब माता-पिता की एफएसओाउन्टाउन की गई थी ro। रीड-ओनली फाइलसिस्टम के लिए कई उपयोग के मामले हैं जहां आपके तर्क का कोई मतलब नहीं है।
पीटर कॉर्ड्स

2
man 8 mount: x-mount.mkdir[=mode] लक्ष्य निर्देशिका (माउंटपॉइंट) बनाने की अनुमति दें। वैकल्पिक तर्क मोड mkdir(2)ऑक्टल नोटेशन के लिए उपयोग की जाने वाली फाइल सिस्टम एक्सेस मोड को निर्दिष्ट करता है। डिफ़ॉल्ट मोड 0755 है। यह कार्यक्षमता केवल रूट उपयोगकर्ताओं के लिए समर्थित है।
15

मैं माउंटेड रीड-राइट फाइलसिस्टम के साथ रीड-ओनली फाइलसिस्टम के किसी भी महत्वपूर्ण उपयोग के मामलों को नहीं देखता, खासकर शुरुआती यूनिक्स में नहीं। @PeterCordes
kubanczyk

@kubanczyk: केवल पढ़ने के लिए एक पढ़ने-लिखने की साथ रूट फाइल सिस्टम, /tmpऔर /home। या उस पर केवल /usrएक स्थानीय /usr/localघुड़सवार के साथ एनएफएस-माउंटेड पढ़ा जाता है। या अधिक आम तौर पर, एक संशोधित हिस्से के साथ किसी भी साझा रीड-ओनली छवि को माउंट किया जाता है। (रीड-ओनली इमेज के लिए स्थानीय मॉड्स भी प्रति-फ़ाइल के आधार पर कस्टम फाइल सिस्टम जैसे कि ओवरलेफ्स या लिनक्स के लिए अन्य यूनियन फाइल सिस्टम के साथ किया जा सकता है, लाइवसीडी बूटेबल इमेज पर उपयोग किया जाता है।) मैं शुरू में रूट एफएस के बारे में सोच रहा था। बूट, लेकिन इसे आरडब्ल्यू बनाने से अन्य आरोहियों से पहले हो सकता है।
पीटर कॉर्ड्स

12

मौजूदा निर्देशिका में बढ़ते हुए mountव्यावहारिक रूप से परमाणु को एक कॉल करता है : यह या तो सफल होता है या विफल रहता है, कम से कम उपयोगकर्ता के दृष्टिकोण से। यदि mountमाउंटपॉइंट स्वयं बनाना होता है, तो इसमें विफलता के दो बिंदु होंगे, जिससे स्वच्छ रोल बैक की गारंटी देना असंभव होगा। इस परिदृश्य की कल्पना करें:

  1. mount सफलतापूर्वक माउंटपॉइंट बनाता है
  2. mount उस निर्देशिका में एक नई फ़ाइल सिस्टम को माउंट करने की कोशिश करता है, लेकिन विफल रहता है
  3. mount माउंटपॉइंट को हटाने की कोशिश करता है, लेकिन विफल रहता है

सिस्टम एक असफल के साइड इफेक्ट के साथ समाप्त होता है mount

यहाँ एक और है:

  1. umount फ़ाइल सिस्टम को सफलतापूर्वक अनमाउंट करता है
  2. umount माउंटपॉइंट को हटाने की कोशिश करता है, लेकिन विफल रहता है

अब, umountसफलता या असफलता लौटानी चाहिए ?


5
mountत्रुटियों के लिए 8 अलग-अलग रिटर्न कोड हैं जिन्हें संयुक्त भी किया जा सकता है। निर्देशिका हटाने में विफल होने पर यह बस एक और जोड़ सकता है। man7.org/linux/man-pages/man8/mount.8.html#RETURN_CODES
अव्यवस्था

8
मुझे लगता है कि ओपी पूछ रहा है कि क्यों माउंटपॉइंट को एक मौजूदा निर्देशिका होने की आवश्यकता है, न कि mountसिस्टम कॉल इसे क्यों नहीं बनाता है। हालाँकि हो सकता है कि यह सिर्फ मेरी व्याख्या / अपेक्षा थी कि मैंने सोचा था कि ओपी का मतलब क्या है, या अगर मैं पूछ रहा था तो मैंने क्या पूछा होगा।
पीटर कॉर्ड्स

3

एक और मामला जो हो सकता है:

जब आप बूट करते हैं, तो एक मूल रीड ओनली इमेज रूट डायरेक्टरी पर लोड होती है। तो जब आप असली जड़ को खत्म करना चाहेंगे तो आप इसे ओवरराइड करना चाहेंगे। तो आप कल्पना कर सकते है कि माउंट syscall बस स्वैप roकरने के लिए माउंटप्वाइंट rw

यहां, आपको कल्पना करता है कि रूट माउंटपॉइंट पर आपके पास एक फ़ाइल सिस्टम समस्या है, आप इसे सुधारने का प्रयास करने में सक्षम होना चाहते हैं। माउंट ओवरलैप के साथ, आप फाइल सिस्टम को अनमाउंट कर सकते हैं और fsckइसे हल करने के लिए मूल छवि में प्रदान किया जा सकता है।

यह सुविधा उन प्रणालियों में भी उपयोगी हो सकती है जिन्हें roविभाजन और एक के बीच परिवर्तन का ट्रैक बनाने के लिए मजबूत सुरक्षा की आवश्यकता होती है rw


1
मुझे यकीन नहीं है कि यह सवाल का जवाब कैसे देता है। क्या आप यह इंगित कर रहे हैं कि यदि mount आवश्यक है कि माउंट-प्वाइंट के स्थान पर एक नई निर्देशिका बनाई जाए, तो आप केवल पढ़ने के लिए फाइल सिस्टम के शीर्ष पर कुछ भी माउंट नहीं कर सकते हैं? उद्घाटन पैराग्राफ भ्रामक है: कि लिनक्स initrd कैसे काम करता है। यह pivot_rootरूट एफएस को बदलने के लिए सिस्टम कॉल का उपयोग करता है , न कि केवल इसके ऊपर अधिक सामान माउंट करने के लिए। इससे अगले पैराग्राफ में आपके तर्क का पालन करना कठिन हो गया, क्योंकि मुझे लगा कि आप इसके बारे में बात कर रहे हैं pivot_root(2)
पीटर कॉर्ड्स

2
@PeterCordes - linux ने कई वर्षों से initrd का उपयोग नहीं किया है : जब कोई अन्य रूट डिवाइस स्विच करता है, initrd होता है pivot_rootऔर फिर umountरैमडिस्क होता है। लेकिन initramfs रूटफ़िश है: आप न तो pivot_rootरूटफ़्स कर सकते हैं , न ही इसे अनमाउंट कर सकते हैं । इसके बजाय स्थान खाली करने के लिए find -xdev / -exec rm {} \;रूटफ़ेट्स से सब कुछ हटा दें ( ), नई रूट ( cd /newmount; mount --move . /; chroot .) के साथ रूटफ़ॉम्स को ओवरमाउंट करें, नए / देव / कंसोल के लिएexecinit
स्टड

@ माइकर्स: नीट! मुझे महसूस नहीं हुआ कि जड़ों को बदलने के लिए बुनियादी तंत्र बदल गया जब हमने initrd के बजाय initramfs का उपयोग करना शुरू कर दिया। "यह सुनिश्चित करें कि सही कर्नेल मॉड्यूल इसे समाप्त करते हैं" से व्यवस्थापक दृष्टिकोण, वे समान हैं> <। मुझे अभी भी लगता है कि यह वास्तव में बहुत अच्छी तरह से सवाल का जवाब नहीं देता है । ऐसा लगता है कि "माउंट एक रफ़्स के तहत माउंट असंभव है" व्याख्या, और एक बहुत विशिष्ट समस्या का मामला देता है (जो कि संभावना नहीं है क्योंकि इनट्रामेफ़्स को केवल बूट पर रीड-माउंटेड नहीं किया गया है। और यहां तक ​​कि अगर यह है, तो यह आसानी से पढ़ा जा सकता है। cpio.gz छवि को प्रभावित किए बिना राइट करें।)
पीटर कॉर्ड्स

@PeterCordes - मैं वास्तव में इस जवाब को नहीं समझता। मैंने अभी आपकी टिप्पणी देखी - initramfs एक फाइल सिस्टम है - यह वास्तव में कभी-कभी केवल पढ़ा नहीं जा सकता है - इसका fs कैश अवतार।
mikeserv

2

मुझे हमेशा आश्चर्य होता है कि वह भी।

एक साधारण आवरण जैसे:

#!/bin/sh
eval "mkdir -p \"\$$#\"" 
/bin/mount "$@"  

एक निष्पादन योग्य स्क्रिप्ट के रूप में सहेजा गया जिसे आपके PATH में mountओवरराइड करने वाली निर्देशिका में नाम दिया गया है /bin, इस बात का ध्यान रखना चाहिए यदि यह आपको बहुत परेशान करती है

(वास्तविक mountबाइनरी को चलाने से पहले , यह अंतिम तर्क के नाम पर एक निर्देशिका बनाता है mount, अगर ऐसी निर्देशिका पहले से मौजूद नहीं है।)


वैकल्पिक रूप से, यदि आप mountडायरेक्टरी बनाने के लिए रैपर के असफल चालान नहीं चाहते हैं, तो आप ऐसा कर सकते हैं:

#!/bin/sh
set -e
eval "lastArg=\"\$$#\""
test -d "$lastArg" || { mkdir "$lastArg"; madeDir=1; }
/bin/mount "$@"  ||  {  test -z "$madeDir" || rmdir "$lastArg"; }

mountतब इस प्रकार बनाई गई निर्देशिका का उपयोग नहीं करना चाहिए ?
मुरु

1
@ ममरू यही आखिरी लाइन है।
PSkocik

ओह, तो आपका मतलब है कि इसका उपयोग इस प्रकार किया जाना चाहिए mount /dev/foo /some/path:? मुझे लगता था कि यह काम करेगा udisksctl, तो आप दौड़ेंगे mount /dev/foo
मुरु

4
आप अंतिम cmdline arg evalको विस्तार $#, उपयोग किए बिना प्राप्त कर सकते हैं "${@:-1}"। मैंने DASH के साथ इसका परीक्षण किया, क्योंकि मुझे लगता है कि यह POSIX sh के समर्थन के लिए जो आवश्यक है, उससे आगे कुछ भी समर्थन नहीं करता है। /bin/dash -c 'echo ${@:-1}' foo barप्रिंट करता है bar
पीटर कॉर्ड्स

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