हमें लिनक्स पर माउंट करने की आवश्यकता क्यों है?

67

मैं समझता हूं कि लिनक्स में क्या बढ़ रहा है, और मैं डिवाइस फ़ाइलों को समझता हूं। हालाँकि मुझे समझ नहीं आता कि हमें माउंट करने की आवश्यकता क्यों है।

उदाहरण के लिए, इस आदेश का उपयोग करते हुए, इस प्रश्न के स्वीकृत उत्तर में बताया गया है :

mount /dev/cdrom /media/cdrom

हम सीडीरॉम डिवाइस को आगे बढ़ा /media/cdromरहे हैं और अंततः निम्नलिखित कमांड के साथ सीडीरॉम की फाइलों तक पहुंचने में सक्षम हैं

ls /media/cdrom

जो CDROM की सामग्री को सूचीबद्ध करेगा।

बढ़ते को पूरी तरह से क्यों न छोड़ें, और निम्न कार्य करें?

ls /dev/cdrom

और CDROM सूचीबद्ध सामग्री है। मुझे लगता है कि उत्तर में से एक होने की उम्मीद है: " यह है कि लिनक्स कैसे डिज़ाइन किया गया है "। लेकिन अगर ऐसा है, तो इसे इस तरह से क्यों बनाया गया था? /dev/cdromसीधे निर्देशिका तक क्यों नहीं पहुंचें ? बढ़ते का वास्तविक उद्देश्य क्या है?

mount devices

— Greeso
स्रोत

2

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

— PM 2Ring

23

बहुत सारे ऑपरेटिंग सिस्टम "माउंट" पर ध्यान दें। यह ज्यादातर मामलों में पारदर्शी है। जब आप विंडोज में एक पेनड्राइव के लिए "सुरक्षित रूप से हटाते हैं" चुनते हैं, तो आप वास्तव में umount कर रहे हैं, क्योंकि यह सिस्टम द्वारा स्वचालित रूप से माउंट किया गया था। लिनक्स सिर्फ इस प्रक्रिया से अब तक उपयोगकर्ता को अलग नहीं करता है, इसलिए परिणाम के रूप में आप इसे और अधिक 'अनुकूलित' करने में सक्षम हैं - कहते हैं, ओम्फ़्सडोस विभाजन vfat से किसी भी दृश्य तरीके में भिन्न नहीं होता है, लेकिन यदि आप mount -t umsdosइसे माउंट करने के लिए उपयोग करते हैं, तो यदि आपके पास mount -t vfatयह सादा विंडोज पार्टीशन की तरह व्यवहार करता है , तो आपके पास सभी लिनक्स परमिशन, ओनरशिप, स्पेशल फाइल्स, फीफोस आदि हैं ।

— एसएफ।

2

help.ubuntu.com/community/Autofs

— jamesdlin

7

"मैं समझता हूं कि लिनक्स में क्या बढ़ते हैं, और मैं डिवाइस फ़ाइलों को समझता हूं।" स्पष्ट रूप से नहीं;)

— कक्षा में हल्की दौड़

5

Why not access the /dev/cdrom directory directly?क्योंकि यह एक निर्देशिका नहीं है।

— ब्रैंडन

67

एक कारण यह है कि ब्लॉक लेवल एक्सेस थोड़ा निचले स्तर की तुलना में lsकाम करने में सक्षम होगा। /dev/cdrom, या dev/sda1क्रमशः आपकी हार्ड ड्राइव के सीडी रोम ड्राइव और पार्टीशन 1 हो सकते हैं, लेकिन वे आईएसओ 9660 / ext4 को लागू नहीं कर रहे हैं - वे केवल डिवाइस डिवाइस के रूप में जाना जाता है उन उपकरणों के लिए रॉ संकेत हैं ।

माउंट की जाने वाली चीजों में से एक यह है कि उस कच्ची पहुंच का उपयोग कैसे किया जाए - फाइल सिस्टम लॉजिक / ड्राइवर / कर्नेल मॉड्यूल्स रीड / राइट को प्रबंधित करने जा रहे हैं या ls /mnt/cdromकिस ब्लॉक में पढ़ने की आवश्यकता है, और उन की सामग्री की व्याख्या कैसे करें जैसी चीजों में ब्लॉक file.txt।

अन्य बार, यह निम्न स्तर की पहुंच काफी अच्छी हो सकती है; मैंने सिर्फ़ सीरियल पोर्ट्स, usb डिवाइसेस, tty टर्मिनल्स और अन्य अपेक्षाकृत सरल डिवाइसों से पढ़ा और लिखा है। मैं कभी भी / dev / sda1 से मैन्युअल रूप से पढ़ने / लिखने की कोशिश नहीं करूंगा, कहने के लिए, एक टेक्स्ट फ़ाइल को संपादित कर सकता हूं, क्योंकि मुझे मूल रूप से ext4 तर्क को फिर से लागू करना होगा, जिसमें अन्य चीजें शामिल हो सकती हैं: फ़ाइल इनोड को देखें, खोजें स्टोरेज ब्लॉक, पूरा ब्लॉक पढ़ें, मेरा बदलाव करें, पूर्ण ब्लॉक लिखें, फिर इनोड (शायद) को अपडेट करें, या इसके बजाय यह सब जर्नल में लिखें - बहुत मुश्किल।

अपने लिए इसे देखने का एक तरीका सिर्फ इसे आज़माना है:

[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory

/devएक निर्देशिका है, और आप कर सकते हैं cdऔर lsआप सभी को पसंद है। /dev/sda1निर्देशिका नहीं है; यह एक विशेष प्रकार की फ़ाइल है जो कि कर्नेल उस उपकरण को 'हैंडल' के रूप में प्रस्तुत करता है।

अधिक गहराई से उपचार के लिए डिवाइस फ़ाइलों पर विकिपीडिया प्रविष्टि देखें ।

— Ehryk
स्रोत

4

मैं कुछ विवरणों के बारे में बता रहा हूं, क्योंकि मुझे लगता है कि बुरी चीजें तब होंगी जब आप सिर्फ डेटा को / dev / sda1 पर संग्रहीत करने के लिए लिखना शुरू करते हैं, और इस प्रकार मुझे लगता है कि कुछ निवारक उपाय या शायद अमूर्तता है जो आपको ओवरराइटिंग चीजों से रोक देगा। लेकिन इसे योग करने के लिए, यदि आप जानते हैं कि डिस्क को कैसे और कहां लिखना है, तो आप इसे मैन्युअल रूप से कर सकते हैं /dev/sda1। ध्यान दें कि कुछ उपकरणों जैसे कच्चे डिस्क, के साथ सीधे बातचीत करते swapon/swapoffऔर dd।

— एह्रीक '

4

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

— ओरियन

6

@Ehryk (3 टिप्पणियाँ ऊपर) एक विशिष्ट लिनक्स सिस्टम में एकमात्र निवारक उपाय फाइल सिस्टम अनुमतियाँ हैं - दूसरे शब्दों में, आपको डिवाइस फ़ाइल में लिखने के लिए रूट खाते का उपयोग करना होगा। यदि आप करते हैं, तो आप cat >/dev/sda1अपने दिल की सामग्री के लिए कर सकते हैं और लिनक्स आपको रोक नहीं पाएगा। (कहने की जरूरत नहीं है, ऐसा करने से फाइलसिस्टम पूरी तरह से भ्रष्ट हो जाएगा।)

— डेविड जेड

5

@psusi आप विंडोज 95 पर ऐसा नहीं कर सकते, सच है। लेकिन यह एमएस डॉस और विंडोज एनटी पर मौजूद (और अच्छी तरह से छिपा हुआ) था। आपका आधुनिक एनटी-आधारित विंडोज निश्चित रूप से आपको (यहां तक कि अन्य विभाजनों पर भी फ़ोल्डर्स में, और यहां तक कि एक ही समय में कई फ़ोल्डरों में) विभाजन को माउंट करने की अनुमति देता है - यह आमतौर पर डिफ़ॉल्ट रूप से पत्र चलाने के लिए सभी अज्ञात विभाजन को मापता है। आप इसे पूर्ण पथ (यूनिक्स रास्ते के समान) का उपयोग करके माउंट किए बिना डिवाइस तक पहुंच सकते हैं, लेकिन केवल अगर यह लॉक नहीं है - जो कि वर्तमान में माउंट होने पर निश्चित रूप से है।

— लुआं

3

@ लुआं और सूसी Psusi का अधिकार है। लेकिन लगभग सभी उद्देश्यों और उद्देश्यों के लिए Win32 API के कॉलर के लिए प्रभाव मूल रूप से समान है। (Posix अनुपालन के लिए माउंट सेमेंटिक्स का एक अनुकरण भी है।) वास्तव में Win9x में माउंट की अवधारणा है क्योंकि यह अभी भी डॉस के शीर्ष पर चलता है। FAT का समर्थन DOS में एक देशी हैंडलर के रूप में बनाया गया था, जिस तरह से NT कर्नेल इसे संभालता है। लेकिन सीडीरॉम और नेटवर्क फाइल सिस्टम को माउंट किया जाना था। (सीडी के लिए MSCDEX याद रखें। इसने ISO / RockRidge फाइलसिस्टम हैंडलर प्रदान किया और इसे ड्राइव-लेटर पर माउंट किया)।

— Tonny

20

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

mount न केवल "आपको फ़ाइलों तक पहुंच प्रदान कर रहा है", यह ओएस को बता रहा है कि ड्राइव के पास फाइलसिस्टम है, यदि यह केवल पढ़ा है या रीड / एक्सेस एक्सेस आदि है।

/dev/cdromएक निम्न-स्तरीय डिवाइस है, ऑपरेटिंग सिस्टम फ़ंक्शन यह नहीं जान पाएंगे कि उन्हें कैसे एक्सेस किया जाए ... कल्पना कीजिए कि आपने इसमें एक अजीब रूप से स्वरूपित सीडीआरएम (यहां तक कि एक ऑडियो सीडी) भी लगाया है, कैसे lsबताएगा कि कौन सी फाइलें (यदि कोई हैं) सीडी "बिना" बढ़ते "पहले?

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

— JCL
स्रोत

8

स्थिरता के लिए

कल्पना करें कि आपके सिस्टम में पहली हार्ड ड्राइव पर कुछ विभाजन हैं। उदाहरण के लिए, /dev/sda2। आप बाद में निर्णय लेते हैं कि ड्राइव इतनी बड़ी नहीं है कि आप एक दूसरे को खरीदकर सिस्टम में जोड़ दें। अचानक, वह बन जाता है /dev/sdaऔर आपकी वर्तमान ड्राइव बन जाती है /dev/sdb। अब आपका विभाजन है /dev/sdb2।

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

हालाँकि, माउंटिंग आपको इस नामांकित ड्राइव के लिए एक ही माउंट पॉइंट का उपयोग करने की अनुमति देता है। आपको /etc/fstabअपने सिस्टम को यह बताने के लिए संपादित करना होगा कि (उदाहरण के लिए) /media/backupअब /dev/sdb2इसके बजाय है, लेकिन यह केवल एक ही संपादन है।

ध्यान दें कि आधुनिक दिन प्रणाली और भी आसान है। डिवाइस के रूप में संदर्भित करने के बजाय /dev/sda2या /dev/sdb2, उनके पास UUIDS, जो समान दिखते हैं c5845b43-fe98-499a-bf31-4eccae14261bया जैसे मित्रवत लेबल दिए जा सकते हैं जैसे कि backupबढ़ते समय डिवाइस को संदर्भित करने के लिए उपयोग किया जा सकता है। इस तरह, एक नया उपकरण जोड़ने पर डिवाइस का नाम नहीं बदलता है जो प्रशासन को और भी सरल बनाता है:

# mount LABEL="backup" /media/backup

सुरक्षा के लिए

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

— garethTheRed
स्रोत

सार्वभौमिक Ids वास्तव में UUIDs हैं, Microsoft के GUID नहीं हैं।

— रुस्लान

@Ruslan - तो वे हैं! उस समय मेरा एमएस सिर था। बहुत धन्यवाद - मैंने इसे बदल दिया है।

— garethTheRed

6

मैं इसे ऐतिहासिक कारण कहूंगा। ऐसा नहीं है कि अन्य उत्तर गलत हैं, लेकिन कहानी के लिए थोड़ा और अधिक है।

विंडोज की तुलना करें: विंडोज की शुरुआत सिंगल-कंप्यूटर, सिंगल-यूजर ओएस के रूप में हुई थी। उस एकल कंप्यूटर में संभवतः एक फ्लॉपी ड्राइव और एक हार्ड ड्राइव, कोई नेटवर्क कनेक्शन, कोई USB नहीं, कुछ भी नहीं था। (Windows 3.11 में नेटवर्किग नेटवर्किंग क्षमताएं थीं। विंडोज 3.1 नहीं था ।)

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

इसके विपरीत, यूनिक्स बहुत शुरुआत से कई उपयोगकर्ताओं के साथ सर्वर नेटवर्क पर चलने के लिए बनाया गया था।

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

वे उन फ़ाइलों को संग्रहीत करने वाले भौतिक उपकरणों से तार्किक फ़ाइल सिस्टम, फ़ाइलों के लिए पथ को सार कर रहे थे। सर्वर ए सामान्य रूप से होस्ट / होम कह रहा है, लेकिन सर्वर ए को रखरखाव की आवश्यकता है: बस सर्वर ए को अनमाउंट करें और इसके बजाय बैकअप सर्वर बी को माउंट करें, और प्रशासकों के अलावा कोई भी नोटिस नहीं करेगा।
(विभिन्न भौतिक उपकरणों - C :, D :, आदि को अलग-अलग नाम देने के विंडोज कन्वेंशन के विपरीत - जो कि यूनिक्स के लिए प्रयास कर रहे पारदर्शिता के खिलाफ काम करता है।)

उस तरह की सेटिंग में, आप दृष्टि विली में सब कुछ माउंट नहीं कर सकते,

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

इसलिए एक ऐतिहासिक परिप्रेक्ष्य से: विंडोज और यूनिक्स अलग-अलग पृष्ठभूमि से आए थे। आप इसे एक सांस्कृतिक अंतर कह सकते हैं, यदि आप चाहें तो:

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

हाल ही में, OSes एक दूसरे के करीब जा रहे हैं:

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

लेकिन यह बताना अभी भी आसान है कि दोनों अलग-अलग परंपराओं का परिणाम हैं।

— जेजी-Faustus
स्रोत

1

यह सिर्फ इतना ही नहीं है। फ़ाइल सिस्टम ड्राइवर (और संभवतः अन्य सिस्टम सॉफ़्टवेयर) का उपयोग करने के लिए डिवाइस निम्न-स्तरीय सार हैं। यूनिक्स को ऑपरेटिंग सिस्टम प्रोग्रामर के लिए एक ऑपरेटिंग सिस्टम के रूप में डिजाइन किया गया था। उदाहरण के लिए, उन फाइलसिस्टम ड्राइवरों के प्रोग्रामर। यही कारण है कि ये निम्न-स्तरीय अमूर्त उपयोगकर्ता के संपर्क में हैं।

— रीइनियरियरपोस्ट

5

मौजूदा व्यवस्था के कई फायदे हैं। उन्हें ब्लॉक विशेष फ़ाइलों और माउंटपॉइंट्स के फायदे में वर्गीकृत किया जा सकता है।

विशेष फाइलें वे फाइलें हैं जो उपकरणों का प्रतिनिधित्व करती हैं। विचारों में से एक है कि यूनिक्स बनाया गया था सब कुछ एक फ़ाइल है। यह कई चीजों को सरल बनाता है, उदाहरण के लिए उपयोगकर्ता इंटरैक्शन सिर्फ फ़ाइल पढ़ता है और एक टटी डिवाइस पर लिखता है, जो एक चरित्र विशेष फ़ाइल है। इसी तरह खराब ब्लॉक्स के लिए जाँच, विभाजन या डिस्क को प्रारूपित करना सिर्फ फ़ाइल ऑपरेशन है। डिस्क mfm, ide, scsi, फाइबरचैन, या कुछ और है तो यह मैटर नहीं करता है, यह सिर्फ एक फाइल है।

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

अब मैंने देखा कि आपने अपनी सीडी / मीडिया / सीडीआरएम पर बढ़ते हुए उल्लेख किया है, जो केवल एक सीडीआर ड्राइव के साथ कंप्यूटर के लिए आसान है, लेकिन क्या होगा यदि आपके पास एक से अधिक हैं? आपको दूसरा माउंट कहां करना चाहिए या तीसरा? या पंद्रहवीं? आप निश्चित रूप से / मीडिया / cdrom2, आदि का उपयोग कर सकते हैं या आप इसे / src / samba / Resources / windows-install, या / var / www पर माउंट कर सकते हैं, या जहाँ भी ऐसा करने का कोई मतलब हो।

— hildred
स्रोत

मुझे लगता है कि ओपी का मतलब था कि पूरी mountतरह से क्यों न छोड़ें , और /dev/cd0, /dev/cd2, /dev/sda1, /dev/sda2सीधे सीधे बातचीत करें - प्रत्येक के पास पहले से ही निर्दिष्ट प्रकार की 'निर्देशिका' है।

— एह्रीक '

1

आप सही हैं, लेकिन क्या आप वास्तव में / dev / sdb9 / share / doc / package / README को एक अच्छा मार्ग पाएंगे? यहां तक कि d: / share / doc / package / README बेहतर है, लेकिन / usr / share / doc / package / README में शब्दार्थ है! वह माउंटपॉइंट का मान है।

— हल्दी

3

मुझे संदेह है कि सिमेंटिक उपयोग बाद में 'डाइरेक्टरी सिस्टम और उस रॉ फाइल पॉइंटर टू द डिवाइस' के बीच में कुछ कोड के एक विशेष बायप्रोडक्ट के उपयोगी उपप्रकार के रूप में आया, क्योंकि cd / ls / नैनो / सब कुछ का उपयोग करना कच्चे की तुलना में बहुत आसान है। लिखते हैं: dd if=/file of=/dev/sda2 bs=4096 skip=382765832 count=84756अकेले जुड़े इनोड / FAT / पत्रिका को अद्यतन करने दें।

— एह्रीक '

(कुछ linux masochists शायद प्यार करेंगे / dev / sdb9 वर्किंग डाइरेक्टरीज़ के रूप में, मुझे यकीन है)

— Ehryk

2

मेरा पहला कंप्यूटर 2 8 "फ्लॉपी पर cp / m चला। यह सब-डाइरेक्टरी को बिल्कुल भी सपोर्ट नहीं करता था। डिस्क के प्रति एक डाइरेक्टरी। एक रास्ता b: name.ext की तरह दिखता था। सिमेंटिक नेमिंग का विचार पहले से ही स्थापित था। यहां तक कि टेप सिस्टम भी। उपयोग किए गए फ़ाइल नाम। UNIX ने पहले ही माउंटपॉइंट्स के लिए ड्राइव अक्षरों के विचार को अस्वीकार कर दिया था। वैसे, @Ehryk, क्या आप जानते हैं कि आप न केवल खिड़कियों में बल्कि डॉस पर एक निर्देशिका पर ड्राइव माउंट कर सकते हैं? मैंने इसे MS-DOS 5 पर किया था। इसके अलावा, जब मैं एक आदमी पृष्ठ की तलाश में हूं तो मुझे यह याद नहीं रखना है कि यह कौन सा कंप्यूटर है जो बहुत कम ड्राइव पर है।

— hildred

5

प्रश्न शीर्षक पूछता है: हमें लिनक्स पर माउंट करने की आवश्यकता क्यों है?

इस प्रश्न की व्याख्या करने का एक तरीका: हमें mountलिनक्स पर फ़ाइल सिस्टम उपलब्ध कराने के लिए स्पष्ट आदेश जारी करने की आवश्यकता क्यों है ?

जवाब: हम नहीं।

आपको फ़ाइल सिस्टम को स्पष्ट रूप से माउंट करने की आवश्यकता नहीं है, आप इसे स्वचालित रूप से करने की व्यवस्था कर सकते हैं, और लिनक्स वितरण पहले से ही अधिकांश उपकरणों के लिए ऐसा करते हैं, जैसे विंडोज और मैक करते हैं।

तो शायद यह नहीं है कि आप क्या पूछना चाहते थे।

दूसरी व्याख्या: लिनक्स पर फाइल सिस्टम उपलब्ध कराने के लिए हमें कभी-कभी स्पष्ट mountआदेश जारी करने की आवश्यकता क्यों होती है ? क्यों नहीं ऑपरेटिंग सिस्टम हमेशा हमारे लिए करते हैं, और इसे उपयोगकर्ता से छिपाते हैं?

यह प्रश्न मैं प्रश्न पाठ में पढ़ रहा हूं, जब आप पूछते हैं:

बढ़ते को पूरी तरह से क्यों न छोड़ें, और निम्न कार्य करें

ls /dev/cdrom

और CD-ROM की सामग्री सूचीबद्ध है?

मुमकिन है, आप का मतलब है: क्यों नहीं बस उस आदेश क्या करना है

ls /media/cdrom

अब क्या करता है?

ठीक है, उस मामले में, /dev/cdromएक निर्देशिका ट्री होगा, न कि डिवाइस फ़ाइल। तो आपका असली सवाल यह प्रतीत होता है: पहली बार डिवाइस फाइल क्यों है?

मैं पहले से दिए गए लोगों के लिए एक उत्तर जोड़ना चाहूंगा।

उपयोगकर्ताओं को डिवाइस फ़ाइलों को देखने के लिए क्यों मिलता है?

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

फ़ाइल सिस्टम ड्राइवर अपना काम कैसे करता है? उत्तर: यह डिवाइस फ़ाइल से पढ़ने और लिखने से होता है। क्यों? जवाब, जैसा कि आपने पहले ही कहा था: यूनिक्स को इस तरह से डिजाइन किया गया था। यूनिक्स में, डिवाइस फ़ाइलें उपकरणों के लिए सामान्य निम्न-स्तरीय अमूर्तता हैं। किसी विशेष उपकरण के लिए वास्तव में डिवाइस-विशिष्ट सॉफ़्टवेयर (डिवाइस ड्राइवर) डिवाइस फ़ाइल पर संचालन के रूप में डिवाइस पर उद्घाटन, समापन, पढ़ना और लिखना लागू करना है। इस तरह, उच्च-स्तरीय सॉफ़्टवेयर (जैसे कि फ़ाइल सिस्टम ड्राइवर) को व्यक्तिगत उपकरणों के आंतरिक कामकाज के बारे में अधिक जानने की आवश्यकता नहीं है। निम्न-स्तरीय डिवाइस ड्राइवर और फ़ाइल सिस्टम ड्राइवर को अलग-अलग लोगों द्वारा अलग-अलग लिखा जा सकता है, जब तक कि वे एक-दूसरे के साथ इंटरफ़ेस करने के लिए एक सामान्य तरीके से सहमत होते हैं, और यही वह डिवाइस फ़ाइलों के लिए है।

इसलिए फाइल सिस्टम ड्राइवर्स को डिवाइस फाइल्स की जरूरत होती है।

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

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

डिवाइस फ़ाइलें इसे आसान बनाती हैं।

— reinierpost
स्रोत

1

बहुत अच्छी तरह से समझाया

— शैलेन्द्र

4

कई डेटाबेस इंजन सीधे कच्चे डिस्क या विभाजन के साथ काम कर सकते हैं। उदाहरण के लिए, MySQL:

http://dev.mysql.com/doc/refman/5.7/en/innodb-raw-devices.html

यह फाइलसिस्टम ड्राइवरों के ऊपर जाने से बचता है, जब सभी डीबी इंजन को वास्तव में जरूरत होती है एक बड़ी फाइल जो डिस्क को भरती है।

— टॉम रॉबिन्सन
स्रोत

3

क्योंकि /dev/cdromएक डिवाइस है, जबकि /media/cdromएक फाइलसिस्टम है । CD-ROM पर फ़ाइलों को एक्सेस करने के लिए आपको पहले वाले को बाद में माउंट करना होगा।

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

सभी ऑपरेटिंग सिस्टम ऐसा करते हैं - हालांकि, कुछ (जैसे कि विंडोज, जब यह सीडी-रोम को मापता है D:) तो इसे पारदर्शी तरीके से करते हैं। लिनक्स इसे आपके पास छोड़ देता है ताकि प्रक्रिया पर आपका अधिक नियंत्रण हो।

— ऑर्बिट में लाइटनेस दौड़
स्रोत

2

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

— ग्रिट्सो

@Greeso: मैं अपने जवाब से खड़ा हूं।

— ऑर्बिट

0

ऐसा इसलिए होता है क्योंकि डेस्कटॉप और लैपटॉप यूआई के लिए कई मीडिया के साथ, मीडिया डाला जाने पर क्या करना है, इसके बारे में अस्पष्टता है, क्योंकि उपयोगकर्ता अंतर्ज्ञान भौतिक बॉक्स में डिस्क को सम्मिलित करना है जिसके साथ उपयोगकर्ता बातचीत नहीं करता है, कहने के लिए अलग है , इसे एक डिवाइस में कंप्यूटर के बगल में सम्मिलित करना जिसमें नेटवर्क कनेक्शन है।

इस प्रकार, मूलभूत अर्थों में, मीडिया के लिए यूआई को दो प्रकार की संभावित माउंट घटनाओं का समान रूप से इलाज करने की आवश्यकता है, और कंप्यूटर के लिए नेटवर्क माउंट को सहज तरीके से संभालने का कोई अच्छा तरीका नहीं है, जैसे कि अन्य यूआई के साथ कंप्यूटर के लिए नेटवर्क माउंट के लिए, जैसे कि स्मार्टफोन, टैबलेट और पहनने योग्य कंप्यूटर, जिसमें उपकरणों में भौतिक मीडिया को सम्मिलित करने की संभावना कम होती है। (ध्यान दें कि सिम कार्ड स्विच करने के लिए iPhone इंटरफ़ेस कितना भयानक है, एक प्रकार के भौतिक मीडिया iOS उपकरणों ने उनमें डाला है।

ध्यान दें कि इस प्रकार के भौतिक बॉक्स के लिए UI के लिए अन्य लोकप्रिय दृष्टिकोण (उदाहरण के लिए, विंडोज 98, विंडोज 8, मैक ओएस एक्स v10.2 (जगुआर), और मैक ओएस एक्स v10.9 (मावेरिक्स)) एक ही मुद्दों में चलते हैं। , और संभावित भ्रम को सुलझाने के लिए अतिरिक्त जीयूआई संवादों का उपयोग करें (उदाहरण के लिए, विंडोज 8 को आमतौर पर प्रत्येक नई सीडी के लिए संकेत देने के लिए कॉन्फ़िगर किया जाता है कि क्या इसे फाइलसिस्टम, म्यूजिक मीडिया, या उपयुक्त होने पर, MP4 वीडियो के संग्रह के रूप में माउंट किया जाना चाहिए )। ऐसा कोई कारण नहीं है कि इनमें से कोई भी उपयोगकर्ता संवाद लिनक्स या अन्य यूनिक्स के साथ उपयोग नहीं किया जा सकता है।

— चार्ल्स स्टीवर्ट
स्रोत