लाइनस टॉर्वाल्ड्स और ओएस एक्स फाइलसिस्टम

Question

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

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

Comments

उन्हें कुछ चीजों के बारे में वास्तव में मजबूत राय रखने के लिए जाना जाता है, उदाहरण के लिए जब उन्होंने git @ google के बारे में बात की, तो उन्होंने अन्य प्रणालियों को ट्रैश करने वाली बात का एक अच्छा हिस्सा खर्च किया। तो मैं कहूंगा कि वह शायद यह मानने का एक कारण है कि वह क्या सोचता है, लेकिन वह एक अतिरंजित व्यक्ति भी है, भले ही वह एक प्रतिभाशाली व्यक्ति है। youtube.com/watch?v=4XpnKHJAok8

— एल डेवलपर

यदि आपको इस प्रश्न का उत्तर यहां नहीं मिलता है जिसकी आप उम्मीद कर रहे थे, तो आप यूनिक्स और लिनक्स या सुपर यूजर दोनों में से किसी पर भी खोज कर सकते हैं (और संभवतः पूछ भी सकते हैं) । (अब उपलब्ध कई साइटों के साथ, यह जानना कभी-कभी मुश्किल होता है कि प्रश्न पूछने के लिए कौन सी जगह है। कम से कम IMHO। :)

— तर्कहीन जॉन

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

— इग्वानानुत

Answer 1

"क्यू एंड ए" सत्र की एक प्रतिलेख जिसमें लिनुस ने टिप्पणी की है, उपलब्ध है, लेकिन ऐसा लगता है कि उसे विस्तृत रूप से पूछा नहीं गया था। मुझे यकीन नहीं है कि HFS + पर उनकी राय का अधिक गहराई से विश्लेषण कहीं और लिखा गया है या नहीं।

मामले के किसी और विश्लेषण के लिए, आप जॉन सिराकुसा के मैक ओएस एक्स की समीक्षा पर एक नज़र डाल सकते हैं। विशेष रूप से मैक ओएस एक्स लायन के लिए जो " HFS + के साथ गलत क्या है " शीर्षक वाला एक खंड है, मुझे लगता है कि सबसे अधिक नमकीन बिट है (जोर मेरा):

कंसीडर, मेटाडेटा सही बाइट ऑर्डर में लिखा गया, सब-सेकेंड डेट सटीक, भारी मात्रा में आकार के लिए समर्थन, और विरल फ़ाइल का समर्थन यूनिक्स फाइल सिस्टम की सभी सामान्य विशेषताएं हैं। मैक ओएस एक्स, ज़ाहिर है, एक यूनिक्स नींव पर बनाया गया है। जब HFS + को क्लासिक मैक ओएस से मैक ओएस एक्स में पोर्ट किया गया था, तो इसे यूनिक्स फ़ाइल सिस्टम से अपेक्षित कुछ न्यूनतम सेट का समर्थन करने के लिए विस्तारित करने की आवश्यकता थी ।

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

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

Comments

महान लिंक; जो कई महत्वपूर्ण चीजों को शामिल करता है। विरल फ़ाइल समर्थन का अभाव बहुत पागल है। लिनक्स ext2 ने साधारण ब्लॉक-बिटमैप आधारित आवंटन के साथ HFS + उपयोगों की तरह फाइलें भी विरल कर दीं। मुझे लगता है कि वह मेटाडेटा को बड़े-एंडियन में संग्रहीत करने के बारे में बहुत बड़ी बात करता है, हालांकि। X86 bswapनिर्देश बहुत तेज है। यह कोड को बड़ा और बदसूरत बनाता है, लेकिन डिस्क पर संगतता बनाए रखना एक बड़ी बात है। लिनक्स एक्सएफएस अभी भी सभी मेटाडेटा बिग-एंडियन (जर्नल में मूल-एंडियन को छोड़कर) को स्टोर करता है, इसके मूल कारण एसजीआई में एमआइपीएस सीपीयू है। यह एक आदर्श स्थिति नहीं है, लेकिन XFS द्वारा इसे वापस आयोजित नहीं किया जाता है।

— पीटर कॉर्डेस

Answer 2

हालाँकि, मैं एक ऑपरेटिंग सिस्टम विशेषज्ञ नहीं हूँ, और मैंने विंडोज से आने के बाद OSX का उपयोग करना शुरू कर दिया है, मैं अपने आप को विंडोज़ में एक पॉवरयूज़र मानता हूँ, और लिनक्स में काफी सक्षम हूँ। उस पृष्ठभूमि से आते हुए, मुझे आश्चर्य हुआ कि OSX की तरह एक काफी आधुनिक OS में, फ़ाइलसिस्टम के पास इस तरह की विचित्रताएँ होती हैं, जैसे फ़ाइलों के नाम "गूंगे" होते हैं।

मैं समझता हूं कि लिनसो उसी बिंदु से HFS + स्टेम के साथ जारी करता है: मैंने जिस मुद्दे पर शोध किया है, उसमें से HFS + ने यूनिकोड का उपयोग करके फ़ाइलों के नाम संग्रहीत किए हैं, लेकिन जब कोई फ़ाइल "विस्तारित" या NON-ASCII वर्णों का उपयोग करता है (जैसे aá é, í, ó, ú, स्पेनिश से या जर्मन में ü जैसी चीजें), जिसके लिए यूनिकोड नाम एन्कोडिंग के 2 तरीके प्रदान करता है, OSX चुपचाप भंडारण के समय एन्कोडिंग को "सामान्यीकृत करता है" ... वास्तविक समय नहीं OSX में फ़ाइल बनाई और खपत की गई है, लेकिन जब आप अन्य OS के उपयोगकर्ताओं के साथ जानकारी साझा कर रहे हैं, तो यह तथ्य कि फ़ाइल का नाम बदलता है, सभी प्रकार के अजीब व्यवहारों के लिए बनाता है ...

बिंदु में मामला: मैं पिछले 8 अधिशेष वर्षों से अपने काम "कलाकृतियों" (फाइलें, दस्तावेज आदि) को तोड़फोड़ में ट्रैक कर रहा हूं। मैक पर जाते समय, मुझे मैक के लिए एसवीएन क्लाइंट मिला, और मेरी संबंधित निर्देशिकाओं का एक चेकआउट करने के बाद, मैंने पाया कि सभी फाइलें जिनमें उच्चारण गायब हैं, और एक ही नाम वाली एक नई फ़ाइल गैर-संस्करण के रूप में दिखाई देती है। इसमें खुदाई करते हुए, समस्या यह है कि फ़ाइल-इन-सिस्टम में फ़ाइल ऐप्पल-एन्कोडेड है, जबकि रिपॉजिटरी में डेटा एक और (पूरी तरह से वैध और वैध) यूनिकोड एन्कोडिंग का उपयोग करता है ...

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

फिर से, कुछ उपयोगकर्ताओं को नोटिस नहीं होगा - जब तक वे किसी फ़ाइल की प्रतिलिपि नहीं बनाते हैं, या उसका नाम बदल देते हैं, और इसे वापस डालते हैं जहां मूल एक था और दो फ़ाइलों के साथ समाप्त होता है जो स्पष्ट रूप से समान हैं !!!)

Comments

यह सिर्फ एक बिंदु है, और वास्तविक मुद्दा यह है कि विभिन्न ओएस बस अलग-अलग तरीकों से तारों को सामान्य करते हैं, और क्रॉस-प्लेटफ़ॉर्म ऐप उसके साथ सौदा नहीं करते हैं। नामों को सामान्य नहीं करना संभवत: बदतर होगा (आप दो अलग-अलग फाइलों के नाम हो सकते हैं जो एक ही स्ट्रिंग को सामान्य करते हैं, ओएस एक्स पर)।

— Blaisorblade

Answer 3

जॉन सिराकुसा और डैन बेंजामिन हाइपरक्रिटिकल # 56 में एचएफएस + के कुछ नुकसानों पर चर्चा करते हैं ।

वे एचएफएस + में डेटा भ्रष्टाचार को संबोधित करते हैं और जेडएफएस की कुछ विशेषताओं पर विचार करते हैं।

Comments

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

— इयान सी

फाइलसिस्टम टॉक 23 मिनट से शुरू होता है।

— neoneye

पॉडकास्ट में उपलब्ध अधिकांश जानकारी जॉन सिराकुसा (पॉडकास्ट में दो पुरुषों में से एक) द्वारा एक Ars Technica लेख में भी पाई जा सकती है ।

— TML