यूनिक्स फाइल सिस्टम में निर्देशिकाओं को कैसे लागू किया जाता है?


19

मेरा सवाल यह है कि निर्देशिकाओं को कैसे लागू किया जाता है? मैं एक डेटा संरचना की तरह विश्वास कर सकता हूं जैसे कि एक चर उदाहरण तालिका, सरणी या समान। चूंकि UNIX ओपन सोर्स है इसलिए मैं उस स्रोत को देख सकता हूं जो एक नई निर्देशिका बनाते समय प्रोग्राम क्या करता है। क्या आप मुझे बता सकते हैं कि विषय पर कहाँ देखना या विस्तृत करना है? यह एक निर्देशिका "" एक फाइल है जिसे मैं समझ सकता था और क्या एक निर्देशिका वास्तव में एक फाइल है? मुझे यकीन नहीं है कि यह सच है कि फ़ाइलें "इन" फाइलों में संग्रहीत की जाती हैं, जबकि अभी भी जिस तरह से आप लगभग किसी भी चीज के बारे में शब्द फ़ाइल कह सकते हैं और मुझे यकीन नहीं है कि क्या बिल्कुल फ़ाइल नहीं है क्योंकि आप एक चर भी कह सकते हैं फ़ाइल। उदाहरण के लिए एक लिंक निश्चित रूप से एक फ़ाइल नहीं है और एक लिंक एक निर्देशिका की तरह है लेकिन फिर यह उल्लंघन करता है कि निर्देशिका एक फ़ाइल है?


1
क्या आप किसी विशेष फाइल सिस्टम में रुचि रखते हैं?
इग्नासियो वाज़क्वेज़-अब्राम्स

3
UNIX में, सब कुछ एक फ़ाइल (ऐतिहासिक ज्ञान) है। लेकिन हर UNIX ओपन सोर्स नहीं है। गन्नू यूनिक्स नहीं है, आप जानते हैं? ओपन सोलारिस एक ओपन सोर्स यूनिक्स है, जबकि लिनक्स केवल एक यूनिक्स रहित ओएस है। :) और हाँ - फाइलसिस्टम - Reiserfs? Ext2-3-4? XFS? एनएफएस?
उपयोगकर्ता अज्ञात

2
एक लिंक है वास्तव में एक फ़ाइल है, भी।
mattdm

5
एक प्रतीकात्मक लिंक एक फ़ाइल है। फाइलसिस्टम ग्राफ में एक कड़ी कड़ी है।
dmckee

3
विज्ञापन: आप ऑपरेटिंग सिस्टम डेवलपमेंट साइट के प्रस्ताव में दिलचस्पी ले सकते हैं ।
गिल्स एसओ- बुराई को रोकना '

जवाबों:


22

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

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

1167010 .
1158721 ..
1167626 subdir
 132651 barfile
 132650 bazfile

इस सूची को कुछ (कमोबेश) 4KB ब्लॉक की श्रृंखला के अंदर कम या ज्यादा कुशल तरीके से कोडित किया गया है। ध्यान दें कि नियमित फ़ाइलों की सामग्री इसी तरह संग्रहीत होती है। निर्देशिकाओं के मामले में, यह जानने का कोई मतलब नहीं है कि इन ब्लॉकों के अंदर वास्तव में किस आकार का उपयोग किया जाता है। यही कारण है कि निर्देशिका द्वारा रिपोर्ट किए गए आकार du4KB के गुणक हैं।

सामान्य ज्ञान में 'फाइल' नाम से एकल इकाई बनाते हुए ब्लॉक को एक साथ बाँधने के लिए होते हैं। उन्हें एक संख्या से पहचाना जाता है जो किसी प्रकार का पता होता है और प्रत्येक को आमतौर पर एकल, विशेष ब्लॉक के रूप में संग्रहीत किया जाता है।

इस सब का प्रबंधन कर्नेल मोड में होता है। सॉफ्टवेयर सिर्फ एक निर्देशिका के निर्माण के लिए कहता है जिसमें int mkdir(const char *pathname, mode_t mode);एक सिस्टम कॉल के लिए अग्रणी फ़ंक्शन का नाम होता है , और शेष सभी पर्दे के पीछे किया जाता है।

लिंक संरचना के बारे में:

एक हार्ड लिंक एक फ़ाइल नहीं है, यह सिर्फ एक नई निर्देशिका प्रविष्टि है (यानी एक नाम - इनोड नंबर एसोसिएशन) एक preexisting इनोड एंटिटी² का जिक्र है। इसका मतलब यह है कि एक ही इनकोड को अलग-अलग पाथनेम्स से एक्सेस किया जा सकता है। विशेष रूप से, चूंकि मेटाडेटा (अनुमतियाँ, स्वामित्व, टाइमस्टैम्प ...) इनोड के भीतर संग्रहीत हैं, ये फ़ाइल को एक्सेस करने के लिए चुने गए पथनाम के अद्वितीय और स्वतंत्र हैं।

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

-
1. यह प्रयोग करके प्राप्त किया गया था ls -ai1 testdir
2. जिसका प्रकार आजकल 'निर्देशिका' से भिन्न होना चाहिए।


विस्तार के लिए धन्यवाद ताकि मैं प्रोग्राम स्तर पर निर्देशिकाओं और फ़ाइलों के बीच के अंतर को समझ सकूं।
निकलेस

12

स्टीफन जिमेनेज़ से पोस्ट पर विस्तार करने के लिए, एक नई निर्देशिका बनाने की प्रक्रिया S_IFDIR (अनुमतियों के मोड के साथ) के st_mode मान के साथ एक नया इनोड बनाने की प्रक्रिया है, लिंक के साथ नए इनोड के पहले डेटा ब्लॉक में दो प्रविष्टियां बनाना 2) सिस्टम कॉल: '।' जो इस नए इनोड की ओर इशारा करता है और '..' जो पेरेंट डाइरेक्टरी को इंगित करता है, फिर इनोड के साथ पैरेंट डायरेक्टरी में एक एंट्री बनाता है और नई डायरेक्टरी का नाम - पहला और आखिरी भाग सिस्टम कॉल माकनॉड द्वारा किया जाता है ( 2)। इसके अलावा, केवल रूट ही इन कार्यों के लिए इन दिनों mknod (2) का उपयोग कर सकते हैं जैसे कि हम बात कर रहे हैं।

उदाहरण के लिए, mkdir("/home/larry.user/xyzzy", 0666)अनिवार्य रूप से निम्नलिखित है (यह SysV दिनों से C कोड था [1]):

int mode = 0666;
char newdir[] = "/home/larry.user/xyzzy";
char path1[NAMESZ+4, path2[NAMESZ+4], *p;
mknod(newdir, S_IFDIR|mode);
strcpy(path1, newdir);
strcat(path1, "/."); /* "." link */
link(newdir, path1);
strcat(path1, ".");  /* ".." link */
strcpy(path2, newdir);
if ((p = strrchr(path2, '/') == (char *)0) /* root directory */
    link(".", path1);
else {
    *p = '\0';
    link(path2, path1);
}
  1. हैविलैंड और सलामा, "यूनिक्स सिस्टम प्रोग्रामिंग", 1987, पीपी 69-71।

यह बहुत अधिक त्रुटि वाला था (और fsck के मुख्य कारणों में से एक) इसलिए mkdir (2) सिस्टम कॉल आपके लिए ऐसा करने में सक्षम होने के लिए बनाया गया था।

ध्यान दें कि एमी फाइलसिस्टम ऑब्जेक्ट mknod (2) के साथ बनाया जा सकता है: नियमित फ़ाइल, निर्देशिका, डिवाइस फ़ाइल, सिमलिंक, आदि। इसलिए ओपी के सवालों में से एक का जवाब देने के लिए, हां, एक निर्देशिका एक फाइल है, जिसका अर्थ है, "यह कहने के लिए" एक ऑब्जेक्ट है, जो एक इनसाइड द्वारा दर्शाया जाता है, एक फाइलसिस्टम में रहता है जो एक आई / ओ इंटरफेस के साथ व्यवहार करता है।


बहुत दिलचस्प जवाब के लिए धन्यवाद। मैं समझता हूं और सोचता हूं कि मैं उस कार्यक्रम के स्रोत में भी देख सकता हूं touchजो एक खाली फ़ाइल बनाता है और देखता है कि यह क्या करता है।
निकल्स

2

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

"कॉमन फाइल मॉडल" यूनिक्स प्रणालियों में, प्रत्येक निर्देशिका को एक फाइल माना जाता है, जिसमें फाइलों और निर्देशिकाओं की एक सूची होती है।

वीएफएस (वर्चुअल फाइल सिस्टम) में, निर्देशिकाओं को एक संरचना में दर्शाया जाता है जिसे कहा जाता है dentrydentry एक स्ट्रिंग नाम (के साथ एक सी संरचना है d_name ), एक inode (करने के लिए एक सूचक d_inode ) और माता पिता के dentry (करने के लिए एक सूचक d_parent )। फाइल सिस्टम में एक फाइल के बारे में जानकारी को संभालने के लिए एक इनोड एक संरचना है। उदाहरण के लिए, यदि आपके पास निर्देशिका है /tmp/test/foo, तो VFS पथनाम में प्रत्येक घटक के लिए एक डेंट्री ऑब्जेक्ट बनाएगा। एसओ, यह रूट डायरेक्टरी /के testप्रवेश के लिए एक डेंट्री ऑब्जेक्ट , दूसरा डेंट्री ऑब्जेक्ट और fooटेस्ट डायरेक्टरी के प्रवेश के लिए तीसरा डेंट्री ऑब्जेक्ट बनाएगा ।


धन्यवाद दिमित्री मैं यह समझना चाहता हूं कि क्यों कुछ प्रोजेक्ट ने एक विशेष डेटा संरचना को चुना जैसे कि बी-ट्री, एक बाइनरी ट्री, एक ट्राइ या एसोसिएटिव ऐरे। मुझे लगता है कि एक उपयुक्त डेटा स्ट्रक्ट्योर / डेटा मॉडल को चुनना महत्वपूर्ण है। विभिन्न कार्यान्वयनों के बारे में सीखने से मुझे उन विवरणों की जानकारी मिलती है जिनकी मुझे तलाश है।
निकलैस

1

आप http://www.freebsd.org/doc/en/books/design-44bsd/book.html#OVERVIEW-FILESYSTEM पढ़कर शुरू कर सकते हैं । अधिक जानकारी के लिए उत्कृष्ट क्लासिक पुस्तक "द डिजाइन एंड इंप्लीमेंटेशन ऑफ 4.4 बीएसडी ऑपरेटिंग सिस्टम" प्राप्त करें।


लिंक के लिए धन्यवाद। मैं समझता हूं कि दोनों फाइलें निर्देशिकाएं हैं जो मूल रूप से सरणियां हैं जो या तो फाइलों या निर्देशिकाओं के रूप में व्याख्या की जाती हैं। कृपया मुझे सही करें अगर मैं गलत हूँ ..
निकोलस

1
निर्देशिकाएँ पारंपरिक रूप से केवल विशेष रूप से स्वरूपित फ़ाइलें हैं, लेकिन यह अब सच नहीं है: en.wikipedia.org/wiki/ReiserFS#Design ReiserFS और कुछ अन्य में, निर्देशिकाएं डेटाबेस में प्रविष्टियां हैं। निर्देशिकाएँ सरणियों के रूप में कार्य कर सकती हैं, लेकिन यह सिर्फ प्रोग्रामिंग अमूर्तता है।
ब्रूस एडिगर

विवरण को इंगित करने के लिए आपका बहुत-बहुत धन्यवाद। अब मुझे लगता है कि मैं और अधिक समझता हूं कि फाइलसिस्टम अभी भी कैसे काम कर रहा है और सोच रहा है कि यह कार्यक्रम कैसे और क्यों locateकाम करता है और यह संबंधित प्रोग्राम को चलाने से अद्यतन करने से संबंधित है updatedb(विशेष रूप से मैं पीसी-बीएसडी, ड्रैगनफ़्लब्ड्स और उबंटू नेट्टी बूटिंग का लाइव सीडी से उपयोग करता हूं और अलग-अलग बेंचमार्किंग कर रहा हूं और इंटरफेस)
निकेलस
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.