क्यों इतने सारे प्रतिस्पर्धी फाइल सिस्टम डिजाइन हैं? [बन्द है]


27

बस एक त्वरित सवाल है, लेकिन आज भी कई फ़ाइल सिस्टम प्रतिस्पर्धा और उपयोग में क्यों हैं? (ntfs, fat32, ext3 (ffs), आदि)

ऐसा लगता है कि फाइल सिस्टम डिजाइनर प्रत्येक प्रकार के सिस्टम के सर्वोत्तम पहलुओं पर सहमत हो सकते हैं और "सर्वश्रेष्ठ" फाइल सिस्टम को लागू कर सकते हैं, नहीं? बस एक विचार, चूंकि ये फाइलसिस्टम कुछ समय के लिए आसपास रहे हैं, और यह कम से कम कुछ हद तक स्पष्ट होना चाहिए कि दूसरों के ऊपर कौन से अच्छे गुण हैं, और हम बस प्रत्येक में अच्छे को जोड़ सकते हैं और एक परम प्रणाली बना सकते हैं जो बहुत बेहतर है


39
क्या हमें फेरारी को भी बेकहो के साथ मिलाने की कोशिश करनी चाहिए? डिजाइन व्यापार-श्रृंखला की एक श्रृंखला पर आधारित है; परिपूर्ण मौजूद नहीं है।
पबबी

7
@ Pubby8 मैं एक ड्राइव करूँगा।
मफिन मैन

8
इसका सही उत्तर सिर्फ तकनीकी चर्चा नहीं है, बल्कि एक कानूनी भी है।
6

38
यह प्रश्न मुझे xkcd.com/927
dan04

7
हम ऐसा उसी समय करेंगे जब हम एक ऐसा कैमरा बनाते हैं जिसमें एक बड़ा, लंबा उच्च-गुणवत्ता वाला लेंस होता है, और यह वास्तव में हल्का होता है, और जेब या पर्स में फिट होता है, और बहुत सस्ता होता है। यह विचार कि आप सभी अच्छे हिस्सों को ले सकते हैं और उन्हें एक सबसे अच्छी चीज में मिला सकते हैं, वास्तव में व्यवहार में नहीं आते हैं। अच्छी चीजों की एक सूची या तो अधूरी है या उन वस्तुओं से भरी है जो एक दूसरे के विपरीत हैं
एरिक लिपर्ट

जवाबों:


32

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

  • ntfs - Microsoft को मालिकाना। जो कोई भी Microsoft नहीं है वह इसका उपयोग नहीं कर सकता है, इसलिए कुछ अलग का उपयोग / निर्माण करना होगा। अब, यदि आप Microsoft हैं, तो आप इसे अगले बुलेट बिंदु के मुद्दों के कारण FAT पर उपयोग करना चाहते हैं।

  • fat32 - पर्याप्त रूप से आधुनिक नहीं। अधिकतम फ़ाइल आकार 4GB है। निर्देशिका प्रविष्टि लुकअप O (n) है। आबंटन तालिका एक लिंक की गई सूची है, बजाय आवंटन बिटमैप जैसे कुछ अधिक कुशल (जहां यह वास्तव में सन्निहित मुक्त स्थान खोजने के लिए त्वरित है)। अनुमति का समर्थन नहीं करता है। हार्ड लिंक या प्रतीकात्मक लिंक का समर्थन नहीं करता है। जर्नलिंग का समर्थन नहीं करता है।

  • ext3 - यह ext2 का एक विस्तार था मुख्य रूप से जर्नलिंग का समर्थन करने के लिए।

तो, ऐसा लगता है कि कुछ कारण हैं:

  1. पहले के फाइल सिस्टम में कुछ कमी होती है। एफएटी के मामले में इसकी कमी है: दोनों (1) सुविधाओं और (2) प्रदर्शन के मामले में। Ext2 के मामले में इसमें अपडेट अपडेट नहीं था, इसलिए किसी दुर्घटना से उबरने में अधिक समय लगा।

  2. एक मौजूदा फाइल सिस्टम शायद करेगा, लेकिन यह आपका नहीं है। (उदा। यदि आप Microsoft नहीं हैं तो NTFS)। इस मामले में आपके पास वास्तव में आपके पास आने के लिए ज्यादा विकल्प नहीं हैं।


2
Nitpick: वास्तव में, FAT32 के लिए अधिकतम फ़ाइल आकार (Microsoft द्वारा प्रकाशित आधिकारिक विनिर्देशों के अनुसार) 2 GiByte है, लेकिन कोई भी नहीं, Microsoft भी इसे लागू नहीं करता है कि यह मूर्खतापूर्ण रूप से :-)
Jörg W Mittag

16
Nitpick 2: NTFS फाइल फॉर्मेट का आविष्कार Microsoft द्वारा किया गया था, लेकिन यह एक प्रकाशित प्रारूप है और इसमें कोई पेटेंट पेटेंट नहीं है। विभिन्न गैर-Microsoft ऑपरेटिंग सिस्टम लिनक्स सहित NTFS को लागू करते हैं।
स्टीफन सी

6
Xfs - बड़े फ़ाइलों की त्वरित स्ट्रीमिंग पुनर्प्राप्ति के लिए डिज़ाइन करने के लिए डिज़ाइन किया गया (वीडियो वर्कस्टेशन के लिए डिज़ाइन किया गया)। ZFS - 21 वीं सदी के लिए एक फाइल सिस्टम। ReiserFS - एक "हत्यारा" फाइलसिस्टम बनाने का प्रयास। प्रत्येक फाइलसिस्टम में ताकत और कमजोरियां होती हैं, प्रत्येक को एक निश्चित आवश्यकता को पूरा करने के लिए बनाया गया था।
टिमोथी बाल्ड्रिज

3
@ स्टीफन सी: NTFS माइक्रोसॉफ्ट द्वारा बिल्कुल "आविष्कार" नहीं किया गया था। en.wikipedia.org/wiki/NTFS#History
सुरक्षित करें

1
@StephenC क्या आप इसके बारे में निश्चित हैं? जहाँ तक मुझे पता है कि NTFS प्रलेखित नहीं है। अधिकांश खुले स्रोत कार्यान्वयन आपको चेतावनी देते हैं कि यदि आप उस ड्राइवर का उपयोग करके लिखने की कोशिश करते हैं, तो विंडोज को कुछ राज्यों में डिस्क को छोड़ देने पर गंभीर नुकसान होगा ।
asveikau

24

संक्षिप्त उत्तर: एक आकार सभी फिट नहीं है।

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


आखिरी बार आपने कब फैसला किया था कि कौन सी एफएस आपकी विशिष्ट जरूरतों को पूरा करती है? मैं संचालन की तुलना में कोडिंग पक्ष पर अधिक हूं, लेकिन मैंने ऐसा निर्णय कभी नहीं देखा। विशेष रूप से, चूंकि अक्सर कोई वास्तविक विकल्प नहीं होता है: MS-> Ntfs। लिनक्स: एक्सट (नवीनतम), शायद रेसर।
केप्पला

@keppla: निर्णय अक्सर OS डिजाइनरों द्वारा किए जाते हैं। फ़ाइल सिस्टम अंतिम उपयोगकर्ताओं द्वारा गंजे नहीं किए जाते हैं।
ज़नो

2
@keppla: किसी भी समय मैं एक फ्लैश ड्राइव को प्रारूपित करने का निर्णय लेता हूं, मैं जर्नलिंग बंद कर देता हूं और यह तय करता हूं कि क्या यह केवल मेरे स्वयं के उपयोग के लिए है (फिर ext2, क्योंकि इसमें POSIX फाइल अनुमतियां हैं) या दूसरों के साथ साझा करने के लिए (तब fat32)। फिर भी हार्ड ड्राइव के लिए मैं NTFS (विंडोज पर) या ext4 (जब लिनक्स पर) का उपयोग करने के लिए जाता हूं ...
liori

1
@keppla लगभग सभी लिनक्स सिस्टम कई अलग-अलग फाइल सिस्टम का उपयोग करने की क्षमता के साथ आते हैं, न कि केवल [2..4]। जब मैं लिनक्स बॉक्स सेट करता हूं, तो मैं बॉक्स के उद्देश्य को देखता हूं। उदाहरण के लिए: मेरी लिनक्स डीवीआर मशीन वीडियो स्टोरेज ड्राइव पर जेएफएस को चलाती है क्योंकि यह एक्स 3 की तुलना में बड़ी फ़ाइलों को बहुत अधिक खूबसूरती से संभालती है और एक्सएफएस की तुलना में कम सीपीयू ओवरहेड का उपयोग करती है। लेकिन एक ही मशीन पर उपयोगकर्ता खातों और सिस्टम फ़ाइलों के लिए मैं EXT3 चलाता हूं क्योंकि मैं छोटे फ़ाइल आकारों के साथ काम कर रहा हूं।
jernernerny

@keppla: इसके अलावा, मैक OS X पर भी आप उनके FS की क्षमताओं के विभिन्न संयोजनों के बीच चयन कर सकते हैं। इसके अलावा, मूल रूप से मैंने टोन को किसी ऐसे व्यक्ति का होने का इरादा किया था जो एफएस डिजाइन करता है। क्योंकि, ओपी ने पूछा कि एक डिज़ाइनर FS को क्यों नहीं डिज़ाइन करता है जिसमें सब कुछ सबसे अच्छा होता है। और जो मैं इंगित करने की कोशिश करता हूं वह सबसे अच्छा है जहां इसका उपयोग होने जा रहा है, उसके सापेक्ष है। कुछ स्थान एक सुविधा उपयोगी है कुछ अन्य स्थान समान सुविधा एक अनावश्यक ओवरहेड है।
जंगल हंटर

14

कभी भी किसी चीज़ का एक "सर्वश्रेष्ठ" नहीं हो सकता क्योंकि "सर्वश्रेष्ठ" के बारे में बहुत सारे विचार हैं। निर्णय उपयोगकर्ता की आवश्यकताओं और सीमाओं के लिए विशिष्ट है। डिजाइन हमेशा बाधाओं के भीतर फिट होने की उनकी क्षमता पर आधारित होते हैं।

एक बुनियादी मोबाइल फोन में कुछ सौ संपर्क, पाठ संदेश इतिहास और कुछ छोटे ऐप स्टोर करने की आवश्यकता होती है। क्या इसके फाइल सिस्टम को RAID विन्यास में मल्टी-टेराबाइट ड्राइव पर एक पदानुक्रमित निर्देशिका संरचना का समर्थन करने की आवश्यकता है? क्या इस तरह के फाइल सिस्टम को चलाने के लिए डिवाइस पर पर्याप्त रैम है? क्या फाइल सिस्टम को जटिल ACL की आवश्यकता है? शायद नहीं - इन सभी सवालों के लिए - इतना आसान, संसाधन-सीपिंग फाइलसिस्टम पर्याप्त होगा।

प्रतिस्पर्धी लाभ बनाए रखने के लिए कंपनियां विभिन्न उत्पादों का विकास भी करेंगी। उदाहरण के लिए, Apple अपने HFS + फाइलसिस्टम की क्षमता को ट्रैक करता है कि कौन सी फाइलें हाल ही में बदली हैं ताकि बैकअप जल्दी हो। दूसरी तरफ, एक फ्लॉपी डिस्क फाइलसिस्टम (FAT) के लिए ड्राइवर बस कुछ KB मेमोरी में फिट हो सकते हैं।


1
समस्या यह नहीं है कि कोई भी "सर्वश्रेष्ठ" का अर्थ पर सहमत नहीं हो सकता है। समस्या यह है कि "सर्वश्रेष्ठ" नहीं हो सकती ...
स्टीफन सी

1
@ स्टीफन: बेशक एक "सबसे अच्छा" हो सकता है। हमें केवल माप मीट्रिक तय करने की आवश्यकता है।
डोनाल्ड फेलो

अगर आप हर किसी को सहमत करने के लिए मिल सकते हैं
स्टीफन सी

11

बहुत कुछ इस बात पर निर्भर करता है कि आप क्या अनुकूलित करना चाहते हैं।

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

Ext2 या ext3 जैसी कोई चीज़ बहुत सी सुविधाएँ और क्षमताएं जोड़ती है जो केवल FAT से अनुपस्थित हैं। फाइलों की खोज भी काफी तेज है। इसी समय, कच्चे लेखन की गति शायद थोड़ी धीमी है, और फ़ाइल सिस्टम को लागू करने के लिए कोड निस्संदेह काफी बड़ा है।


9

बस एक त्वरित सवाल है, लेकिन आज भी कई फ़ाइल सिस्टम प्रतिस्पर्धा और उपयोग में क्यों हैं? (ntfs, fat32, ext3 (ffs), आदि)

ऐसा लगता है कि फाइल सिस्टम डिजाइनर प्रत्येक प्रकार के सिस्टम के सर्वोत्तम पहलुओं पर सहमत हो सकते हैं और "सर्वश्रेष्ठ" फाइल सिस्टम को लागू कर सकते हैं, नहीं?

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

मुझे नहीं लगता कि किसी ने 10 साल के लिए एक नए हार्ड ड्राइव पर FAT32 का इस्तेमाल किया है, लेकिन यह अभी भी यूएसबी ड्राइव, एसडी कार्ड, आदि के प्रारूप के लिए वास्तविक मानक के रूप में कायम है, कैमरा और मोबाइल फोन निर्माताओं ने इसका उपयोग करने के लिए फर्मवेयर की कोशिश की और परीक्षण किया है। Arduino hobbyists के पास इसका उपयोग करने के लिए स्थिर पुस्तकालय हैं। वे सभी को बदलने के लिए बड़े प्रोत्साहन की आवश्यकता है।

और फिर आपके पास पुराने ओएस (विशेषकर विंडोज, जिनके उपयोगकर्ता नए फाइलसिस्टम ड्राइवर स्थापित नहीं करना चाहेंगे) के साथ पीछे की ओर संगतता है।


5
क्रॉस प्लेटफॉर्म क्षमता के लिए FAT32 को किसी प्रकार का बाहरी उपकरण दिया जाना अच्छा है। यही कारण है कि आप FAT32 को स्वरूपित बहुत सारे बाहरी उपकरण देखेंगे।
मैट

@ मट, क्या मैंने जो कहा, उसका एक उपसमूह नहीं है?
पीटर टेलर

3
और छोटे micros के लिए, बुनियादी FAT समर्थन को लागू करने के लिए कोड केवल कुछ ही kbytes में फिट बैठता है। यह तब मायने रखता है जब आपके पास खेलने के लिए केवल कुछ ही
किबेट होते हैं

2
@ पेटर मैं इसे इस तथ्य के लिए अधिक बता रहा था कि आप इसे विभिन्न ओएस पर बिना किसी समस्या के उपयोग कर सकते हैं।
मैट

4

जैसा कि अक्सर होता है उत्तर की गणना करने में मामला ऐतिहासिक परिस्थितियों के कारण (ए) है और पीछे की संगतता और (बी) बनाए रखने की आवश्यकता है क्योंकि कुछ तरीके दूसरों की तुलना में कुछ कार्यों के लिए बेहतर हैं।

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

इसी तरह, लिनक्स उपयोगकर्ताओं के लिए, कहते हैं, एक स्थिर NTFS ड्राइवर आने में एक लंबा समय था, इसलिए FAT के रूप में स्वरूपित उपकरणों को रखने का मतलब है कि उन्हें कई प्रणालियों में पढ़ा और लिखा जा सकता है।

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

इसलिए अलग-अलग फाइल सिस्टम अलग-अलग उद्देश्यों के लिए डिज़ाइन किए गए हैं।


3

फिर भी हर किसी के लिए एक आदर्श फ़ाइल सिस्टम क्यों नहीं हो सकता है इसका एक और उदाहरण: HDDs और SSDs में बहुत अलग-अलग रीड / राइट एक्सेस एक्सेस हैं। एक SSD- अनुकूलित फाइल सिस्टम शायद पागलों की तरह फाइलों को खंडित करके सबसे अच्छा काम करेगा, लेकिन हर टुकड़े के साथ SSD का पृष्ठ आकार; यह एक HDD पर बहुत अच्छा प्रदर्शन करेगा। एक एचडीडी-अनुकूलित फाइलसिस्टम फाइलों को यथासंभव अनफ्रेग्मेंटेड रखने की कोशिश करता है और यहां तक ​​कि प्लॉट के तेज-कताई बाहरी हिस्से पर "गर्म" क्षेत्र में अक्सर उपयोग की जाने वाली फाइलें डालता है; ये विशेषताएँ SSD की गति को बिल्कुल भी पढ़ने में मदद नहीं करेंगी, और उन्हें लिखा गया है कि वे कैसे लिखे जाते हैं, इस पर बहुत बड़ा प्रभाव डालते हैं।


2

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

यह प्रतिस्पर्धा, विखंडन, दहन और मैं अंत में बेहतर समाधान और अधिक विकल्पों में आपके लिए एक मिलान समाधान चुनने की आशा करता हूं।


1

यहां एक और ठोस उदाहरण है कि आपको एक अलग फ़ाइल सिस्टम की आवश्यकता क्यों है या मौजूदा FS की कार्यक्षमता का विस्तार करना चाहिए।

  1. कहते हैं कि आप एक डेटाबेस विक्रेता हैं और आईओ को बेहतर बनाने के लिए डेटा की स्ट्रिपिंग / मिररिंग की जटिलता को कम करना चाहते हैं। आपको मूल फ़ाइल सिस्टम की कार्यक्षमता का विस्तार करने की आवश्यकता महसूस होगी, क्योंकि ओरेकल ने एएसएम (ऑटोमेटेड स्टोरेज मैनेजर) के साथ किया था जो एक लॉजिअल वॉल्यूम प्रबंधक की तरह है।

1

अपनी सूची में आप एक पुराने फाइल सिस्टम का उपयोग करते हैं क्योंकि एक बेहतर उपलब्ध नहीं है, हालांकि यह तेज है।

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

अनिवार्य रूप से उनके पास अंतर लक्ष्य हैं और वे औचित्य बनाम खुले स्रोत हो सकते हैं।


0

मुझे लगता है कि ZFS (सूर्य प्रणाली [अब Oracle] में सोलारिस द्वारा उपयोग) फ़ाइल सिस्टम का समाधान है।

खोज के लिए Unfortunatly Oracle Oracle OpenSolaris बंद करें और इसका परीक्षण करें।

ZFS खुला स्रोत है, कुछ लिनक्स इसे एकीकृत करने की कोशिश कर रहे हैं, विकिपीडिया में अधिक informations के लिए देखें।

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