कैमरे जर्नलेड फाइल सिस्टम का समर्थन क्यों नहीं करते हैं?

Question

SD कार्ड के लिए NTFS, HFS + या ext4 की तरह? आखिरकार, जर्नलिंग से डेटा हानि की संभावना कम हो जाती है, जो फोटोग्राफरों के लिए महत्वपूर्ण होगा। मैं एक SD कार्ड खो गया, जिसमें शायद बाली में एक हज़ार तस्वीरें थीं - एक ऐसी जगह जिसे मुझे पहले या बाद में जाने का मौका नहीं मिला।

अगली बार यात्रा से पहले क्या कोई सावधानियां बरतनी चाहिए? कैमरे में कार्ड प्रारूपित करें?

क्या मैं यह समझने में सही हूं कि SDXC (एक्सफ़ैट) और सोनी मेमोरी स्टिक एसडी कार्ड की तुलना में अधिक विश्वसनीयता प्रदान नहीं करते हैं?

Comments

एक एसडी पर उन filesystems में से किसी को चलाने के फ्लैश मेमोरी सुंदर झटके से जल्दी से मार सकता है।

— टिम सेगिन

@PhilipKendall मेरा स्रोत नहीं है, लेकिन इस एसई उत्तर में यह उल्लेख किया गया है: serverfault.com/questions/41674/… ... वैसे भी एसएसडी हार्ड ड्राइव को सामान्य फाइल सिस्टम का उपयोग करते समय फ्लैश को ट्रैश करने से बचने के लिए विशेष तर्क की आवश्यकता होती है। एसडी कार्ड में उस तरह की सस्ती फ्लैश मेमोरी इस तरह के लोड के लिए भी कम अच्छी तरह से अनुकूल है। एफएटी एक बहुत ही सरल फाइलसिस्टम है जो क्रमिक भंडारण भार के लिए अनुकूल है जो कैमरे बनाते हैं और कम फ्लैश मेमोरी पहनने का कारण बनते हैं। प्राथमिक मुद्दा पहले से ही प्रदान किए गए उत्तरों में है: बिना किसी लाभ के लिए जोड़ा गया जटिलता।

— टिम सेगिन

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

— जिम गैरिसन

@KartickVaddadi आपकी संख्याओं के लिए आपका स्रोत क्या है कि एक जर्नल फ़ाइल सिस्टम 10% (5 साल से 4.5%) तक जीवन को कम कर देगा? क्या आपके पास कुछ शोध हैं जो आप इंगित कर सकते हैं?

— फिलिप केंडल

@KartickVaddadi: तार्किक क्षेत्र संख्या और भौतिक डिस्क ब्लॉक के बीच की मैपिंग परत विफलता मोड बनाती है जो चुंबकीय मीडिया से जुड़े किसी भी सामान्य रूप से विपरीत हैं; फाइल सिस्टम जो कि मैपिंग लेयर को नहीं समझता है, जो उनसे छिपा हुआ है, उस लेयर द्वारा लगाए गए किसी भी विफलता मोड से बच नहीं सकता है।

— सुपरकैट

Answer 1

आइए थोड़ा लागत लाभ विश्लेषण करें:

1. एक जर्नलेड फाइल सिस्टम अधिक जटिल है - इसका मतलब है कि विकास का समय, अधिक बग, अधिक बैटरी पावर ड्रेन, उच्च उत्पादन लागत आदि।

2. एक समस्याग्रस्त फ़ाइल सिस्टम द्वारा हल की गई समस्या - FS डेटा दूषित लेकिन फ़ाइल डेटा बरकरार - 3 पार्टी डेटा रिकवरी टूल द्वारा बहुत अच्छी तरह से नियंत्रित किया जाता है।

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

4. कोई बड़ा मेमोरी कार्ड विश्वसनीयता संकट नहीं है, वे कार्ड काफी विश्वसनीय हैं और विफलता अपेक्षाकृत दुर्लभ है।

5. और अंत में, कोई जर्नल फ़ाइल सिस्टम नहीं है जो विंडोज और मैक दोनों पर आउट-ऑफ-द-बॉक्स समर्थित है।

इसलिए - यदि आप प्रभारी उत्पाद प्रबंधक थे, तो क्या आप एक परियोजना को मंजूरी देंगे कि 1. एक पहले से ही हल किए गए (तीसरे पक्ष के उपकरण के साथ) समस्या को एक अपूर्ण तरीके से हल करता है, 2. एक बिक्री बिंदु होने के लिए पर्याप्त महत्वपूर्ण नहीं है और 3. बना देगा बाजार का एक महत्वपूर्ण हिस्सा कैमरे का उपयोग करने में असमर्थ है (कम से कम अतिरिक्त सॉफ़्टवेयर स्थापित किए बिना उन्हें प्रतिस्पर्धी ब्रांडों के साथ की आवश्यकता नहीं होगी)?

Comments

दरअसल, OSX NTFS वॉल्यूम पढ़ सकता है, और कुछ टर्मिनल फू के साथ उन्हें लिख सकता है ।

— जस्टिन डियरिंग

@JustinDearing: नीट! आपको क्रॉस-पोस्ट को एक प्रश्नोत्तर के रूप में पूछना चाहिए ।

— ओव

OS X में डिफ़ॉल्ट फाइलसिस्टम विन्यास (मतलब, वह कॉन्फ़िगरेशन जो सभी मैक के साथ प्रीइंस्टॉल्ड होता है) HFS + के साथ जर्नलिंग सक्षम है। वास्तव में, टाइम मशीन को सक्षम होने के लिए जर्नलिंग की आवश्यकता होती है ।

— ३

@strugee - मैंने यह नहीं कहा कि OS X में जर्नलिंग फ़ाइल सिस्टम नहीं है - मैंने कहा कि कोई एकल प्रणाली नहीं है जो OS X और Windows दोनों बॉक्स से बाहर का उपयोग कर सकता है (Windows HFS + को बिल्कुल भी नहीं समझता है और Mac) डिफ़ॉल्ट रूप से) NTFS नहीं लिख सकते)

— Nir

@ नीर आह, कभी नहीं। मैंने गलत समझा।

— आवारागर्दी

Answer 2

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

वास्तविक समाधान अतिरेक है, यही वजह है कि आपको निकॉन, पेंटाक्स और कैनन से उच्च-स्तरीय प्रसाद मिलेंगे जो दोहरे मेमोरी-कार्ड स्लॉट और एक साथ दोनों कार्डों में चित्र लिखने की क्षमता प्रदान करते हैं। यह आपको तुरंत बैकअप देता है। यदि वे कैमरे आपके लिए सुविधाजनक नहीं हैं, तो आपको लगातार बैकअप बनाने के लिए कोई अन्य तरीका खोजना होगा। कुछ लोग इसे रोजाना लैपटॉप, पोर्टेबल ड्राइव, ऑप्टिकल-डिस्क पर करते हैं।

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

जबकि SDXC डिफ़ॉल्ट रूप से exFAT के रूप में प्रारूप में आता है, आप इसे FAT32 पर भी स्वयं प्रारूपित कर सकते हैं। अधिकांश कैमरे इसे दोनों तरीकों से स्वीकार करेंगे। विश्वसनीयता में अंतर शायद शून्य है।

Comments

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

— वड़ादि कार्तिक

जर्नलेड फाइल-सिस्टम यह सुनिश्चित करते हैं कि पूरी फाइल-प्रणाली सुसंगत है लेकिन वे वास्तव में भ्रष्टाचार के लिए कुछ नहीं करते हैं। आपको इसके लिए कुछ अतिरेक की आवश्यकता होगी।

— इटई

@KartickVaddadi मुझे लगता है कि जब आप किसी भी प्रकार की फ्लैश मेमोरी खरीदते हैं तो यह किसी भी समय पर विफल हो जाएगा। यदि आप इस क्षेत्र में बाहर हैं, तो जोखिम कम करने के लिए निवेश करने के लिए तैयार नहीं हैं, तो सबसे अच्छा आप यह सुनिश्चित कर सकते हैं कि आप प्रतिष्ठित निर्माताओं से विश्वसनीय कार्ड खरीद रहे हैं।

— पेंग टक क्वोक

@KartickVaddadi आप एक ऊंट को निगलने की कोशिश कर रहे हैं ताकि एक ग्न्ट खाने के लिए तनाव से बचा जा सके। यदि आपने अपने गियर पर 'हजारों डॉलर' खर्च किए हैं, तो अतिरिक्त मेमोरी कार्ड के लिए एक और $ 20 क्या है जो आपको दूसरे कार्ड स्लॉट का लाभ उठाने के लिए वैसे भी खरीदना होगा?

— माइकल सी

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

— सिंह

Answer 3

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

DCF के बारे में अधिक जानकारी के लिए /photo//a/46387/15871 देखें ।

Comments

क्या मानक NTFS का उपयोग करने से एक कैमरा विक्रेता को रोक देगा। HFS +, या अन्य फाइल सिस्टम अगर एक कार्ड डाला गया था जो उन प्रणालियों में से एक के साथ स्वरूपित किया गया था, या कैमरे को "कार्ड बेकार" कहने की आवश्यकता होगी?

— सुपरकैट

एक बिंदु पर कल्पना में FAT32 IIRC शामिल नहीं था। वर्तमान में (DCF v2, 2010 प्रकाशित) युक्ति सभी FAT वेरिएंट + exFAT तक सीमित है। तो भविष्य में डीसीएफ के लिए अन्य फाइल सिस्टम को शामिल करने के लिए विस्तारित किया जाना चाहिए, अगर सदस्य चाहते थे।

— जेम्स स्नेल

@ सुपरकैट यह मानक के बाहर होगा जैसा कि अब लिखा गया है। मानक हमेशा संशोधन के अधीन होते हैं। लेकिन सवाल यह लगता है कि कोई भी मौजूदा कैमरा जर्नलेड फाइल सिस्टम का समर्थन क्यों नहीं करता है।

— माइकल सी

@JamesSnell नियमित FAT16 भी प्रति विभाजन 2 GiB में सबसे ऊपर है, इसलिए कुछ और आधुनिक की अनुमति देने के कदम से एक बहुत ही वास्तविक समस्या हल हो गई। गैर-माइक्रोसॉफ्ट सिस्टम में FAT32 के लिए व्यापक समर्थन 2000 के आसपास के वर्षों में लागू किया गया लगता है , और FAT32 एक 512 बाइट्स तार्किक क्षेत्र आकार का उपयोग करते हुए आज भी विभाजन पर काफी अधिक उपयोगी है।

— बजे एक CVn

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

— जेम्स स्नेल

Answer 4

यह हल करने के लिए नीचे आता है "क्या कोई बाजार है?" और "गोद लेने के लिए क्या बाधाएं हैं?"। उनमें से प्रत्येक गोद लेने के लिए एक बड़ा अवरोध प्रस्तुत करता है, भले ही वह सार्थक हो।

NTFS को लाइसेंस देने के लिए लागत का भुगतान करना होगा, भले ही एक उपयुक्त पुस्तकालय यहां तक ​​कि कैमरे के प्रोसेसर (जो गारंटी नहीं है) के लिए मौजूद है और विंडोज के बाहर समर्थन पैच होगा। जबकि HFS + और ext4 के पास विंडोज़ में कोई मूल समर्थन नहीं है, जो कि संभावित ग्राहक आधार को बहुत दूर करता है। तो उन लोगों के लिए कोई बाजार नहीं है।

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

अधिकांश कार्डों की विफलता मोड एक मेमोरी सेल के रूप में नियंत्रक होने की संभावना है यह थोड़ा लाभ के लिए बहुत काम (निर्माण की लागत) है।

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

Comments

एनएफएस एक ऑन-डिस्क फ़ाइल सिस्टम नहीं है, यह एक नेटवर्क प्रोटोकॉल है (समस्या को हल करने के संदर्भ में इसके काफी परिचित चचेरे भाई एफ़टीपी के साथ लगभग बराबर है)। क्या आपका मतलब एचएफएस + (मैक ओएस द्वारा मूल रूप से उपयोग की जाने वाली फाइल सिस्टम) है?

— बजे एक CVn

मेरा वास्तव में मतलब था HFS +, संपादित करेगा :)

— जेम्स स्नेल

Answer 5

एक स्पष्ट कारण: क्योंकि बहुत संभव है कि कैमरे पर एक जर्नलिंग फाइलसिस्टम ने आपकी (या किसी की) मदद नहीं की होगी।

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

यह एक डेस्कटॉप पीसी पर मूल्यवान है, जहां बिजली बाहर जा सकती है, या उपयोगकर्ता रीसेट बटन को हिट कर सकता है, या प्लग को खींच सकता है, आदि भी मूल्यवान है, लेकिन सर्वर (बिजली की विफलता) और लैपटॉप (रीसेट बटन) पर कम है। ।

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

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

एक जर्नलिंग फाइलसिस्टम आपकी सुरक्षा नहीं करता है:

• एसडी, आदि कार्ड पर फ्लैश नियंत्रक में कीड़े।
• कैमरे के एसडी होस्ट हार्डवेयर में कीड़े
• कैमरे पर फाइलसिस्टम कोड में कीड़े
• फर्मवेयर के एसडी ड्राइवरों में कीड़े
• मीडिया पर क्षेत्रों का नुकसान
• हार्डवेयर की खराबी (जैसे, कॉस्मिक किरणों, स्थैतिक निर्वहन, ईएम शोर, पानी, ...) के कारण

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

Answer 6

जर्नल कार्ड सिस्टम एसडी कार्ड (या किसी नंद फ्लैश डिवाइस) के लिए खराब हैं।

नंद फ्लैश डिवाइसों के लिए लिखें ऑपरेशन महंगे हैं और जर्नलेड फाइल सिस्टम समान गतिविधियों के लिए गैर-जर्नलेड फाइल सिस्टमों से अधिक लिखने की प्रवृत्ति रखते हैं।

तो SD कार्ड धीमी गति से काम करेगा और जर्नल फ़ाइल सिस्टम के साथ कम चलेगा।

FLASH- आधारित स्टोरेज, इसके मूल में, NAND FLASH नामक तकनीक का उपयोग करता है। नंद फ्लैश पठनीय और लिखने योग्य है, लेकिन कई झुर्रियों के साथ।

1. मौलिक रीड / राइट यूनिट एक "पृष्ठ" है, न कि एक सेक्टर। 2007-2008 की पीढ़ी के FLASH डिवाइस में 2K पेज का आकार होता है, जो 2009 की पीढ़ी में 4K पेज साइज में माइग्रेट होता है और 2011 पीढ़ियों में 16K पेज साइज देखा गया है।

2. आप कभी भी एक पेज नहीं लिख सकते हैं - आप इसे लिखने से पहले, आपको पहले इसे मिटाना होगा। लेकिन आप एक बार में एक भी पेज नहीं मिटा सकते हैं - आपको (लगातार) 64 पेज (128Kbytes या 256Kbytes) को पीढ़ी के आधार पर पूरे "मिटा ब्लॉक" को मिटाना होगा। और जब आपने ब्लॉक को मिटा दिया है, तो आप पृष्ठों को एक मनमाने क्रम में नहीं लिख सकते हैं, तो आपको उन्हें क्रमिक रूप से लिखना शुरू करना होगा।

3. ब्लॉक समय के साथ खराब हो जाते हैं। एक निश्चित संख्या में मिटाए गए चक्रों के बाद, एक ब्लॉक स्थायी रूप से "खराब हो जाएगा", ताकि यह अब मज़बूती से डेटा नहीं रखेगा। पेज अन्य पेजों पर लिखने की गतिविधि के परिणामस्वरूप डेटा त्रुटियों को भी विकसित कर सकते हैं, और यहां तक ​​कि रीड्स के परिणामस्वरूप भी!

http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device

संपादित करें: यह उल्लेख के लायक है कि जर्नल फ़ाइल सिस्टम गैर-जर्नल फ़ाइल सिस्टम पर महत्वपूर्ण लाभ नहीं लाएगा।

• पॉवर फेल होने के बाद जर्नलिंग फाइलसिस्टम भ्रष्टाचार के खिलाफ गारंटी देते हैं?

Comments

फ्लैश डिवाइस एक ब्लॉक रीमैपिंग लेयर (FTL) का उपयोग करते हैं, इसलिए आप बार-बार उसी भौतिक ब्लॉक को नहीं लिख रहे हैं। Android ext4 जैसे फाइल सिस्टम का उपयोग करता है, इसलिए मुझे आपके तर्क की वैधता दिखाई नहीं देती है कि यह फ़्लैश के लिए अनुपयुक्त है।

— वदादी कार्तिक

एंड्रॉइड डिवाइस में आमतौर पर कुछ रैम के साथ-साथ फ्लैश भी होते हैं, है न?

— माइकल सी

ब्लॉक रीमैपिंग किसी ब्लॉक के खराब होने से पहले प्रति ब्लॉक की कुल संख्या में वृद्धि नहीं करता है, यह सिर्फ पूरे कार्ड के बाहर लिखने के संचालन को फैलाता है ताकि लगभग हर ब्लॉक एक ही दर पर पहना जाए। जर्नलेड सिस्टम गैर-जर्नल सिस्टम की तुलना में एक ही काम करने के लिए अधिक लेखन संचालन का उपयोग करते हैं, इसलिए कार्ड के खराब होने से पहले लिखने की कुल संख्या एक जर्नलेड सिस्टम के साथ अपने जीवन चक्र में जल्द ही घटित होगी।

— माइकल सी

एंड्रॉइड में स्टोरेज (I / O लैग्स) से जुड़ी कुछ समस्याएं हैं और वे स्थिति को सुधारने के लिए TRIM कमांड को लागू कर रहे हैं । एसडी कार्ड सस्ते और छोटे होने चाहिए, मजबूत नहीं होने चाहिए। विकल्प अधिक मजबूत हैं, लेकिन वे अधिक महंगे हैं।

— S182

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

— S182

Answer 7

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

एक पेचीदा मुद्दा इस तथ्य के इर्द-गिर्द है कि मेमोरी-कार्ड मानक निर्दिष्ट करते हैं कि प्रत्येक कार्ड 512-बाइट क्षेत्र के गिने हुए संग्रह के रूप में व्यवहार करता है जिसे मनमाने ढंग से अनुक्रम में स्वतंत्र रूप से पढ़ा और लिखा जा सकता है, लेकिन यह नहीं है कि डेटा चिप्स के भीतर कैसे संग्रहीत किया जाता है। पत्ते। एक विशिष्ट मेमोरी कार्ड में उपयोग किए जाने वाले मेमोरी चिप्स को 528-बाइट पृष्ठों में विभाजित किया गया है; बदले में उन्हें 256 या अधिक के ब्लॉक में बांटा गया है। एक बार एक पृष्ठ लिखे जाने के बाद, इसे मिटाए बिना और इसके ब्लॉक के अन्य सभी पृष्ठों को दोबारा नहीं लिखा जा सकता है। सिद्धांत रूप में, एसडी कार्ड के लिए यह संभव होगा कि आप अपने ब्लॉक के सभी डेटा को रैम से कॉपी करके ब्लॉक को मिटाकर, और पूरे ब्लॉक को वापस लिखकर, लेकिन एक सेक्टर में नए डेटा के साथ 512-बाइट सेक्टर लिखने के अनुरोध का सम्मान करें। । व्यवहार में, प्रदर्शन भयानक होगा। बजाय, किसी सेक्टर को लिखने से SD कार्ड को खाली पृष्ठ चुनने का कारण होगा, उसके सेक्टर नंबर और विभिन्न सहायक जानकारी (कारण पृष्ठ 512 के बजाय 528 बाइट्स) के साथ वहां डेटा लिखें, और किसी तरह उस के लिए उचित स्थान होने का ट्रैक रखें आँकड़े। जब रिक्त पृष्ठ कम आपूर्ति में हो जाते हैं, तो नियंत्रक एक ऐसे ब्लॉक की पहचान करेगा, जिसके पृष्ठ ज्यादातर हाल ही में लिखे गए पृष्ठों से अलग हो गए हैं, फिर भी उस ब्लॉक से रिक्त ब्लॉकों में सभी अभी-वर्तमान पृष्ठों की प्रतिलिपि बनाएँ, और फिर पूरे अब-निरर्थक ब्लॉक को मिटा दें । यह सब तर्क पूरी तरह से कार्ड द्वारा ही नियंत्रित किया जाता है, बिना किसी हस्तक्षेप के कैमरे द्वारा। जब रिक्त पृष्ठ कम आपूर्ति में हो जाते हैं, तो नियंत्रक एक ऐसे ब्लॉक की पहचान करेगा, जिसके पृष्ठ ज्यादातर हाल ही में लिखे गए पृष्ठों से अलग हो गए हैं, फिर भी उस ब्लॉक से रिक्त ब्लॉकों में सभी अभी-वर्तमान पृष्ठों की प्रतिलिपि बनाएँ, और फिर पूरे अब-निरर्थक ब्लॉक को मिटा दें । यह सब तर्क पूरी तरह से कार्ड द्वारा ही नियंत्रित किया जाता है, बिना किसी हस्तक्षेप के कैमरे द्वारा। जब रिक्त पृष्ठ कम आपूर्ति में हो जाते हैं, तो नियंत्रक एक ऐसे ब्लॉक की पहचान करेगा, जिसके पृष्ठ ज्यादातर हाल ही में लिखे गए पृष्ठों से अलग हो गए हैं, फिर भी उस ब्लॉक से रिक्त ब्लॉकों में सभी अभी-वर्तमान पृष्ठों की प्रतिलिपि बनाएँ, और फिर पूरे अब-निरर्थक ब्लॉक को मिटा दें । यह सब तर्क पूरी तरह से कार्ड द्वारा ही नियंत्रित किया जाता है, बिना किसी हस्तक्षेप के कैमरे द्वारा।

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

व्यक्तिगत रूप से, मुझे लगता है कि एसडी कंसोर्टियम के लिए FAT32 से स्वतंत्र एक फाइल सिस्टम को निर्दिष्ट करना बेहतर होगा, या कम से कम यह निर्दिष्ट करें कि भले ही एक कार्ड को FAT32 वॉल्यूम के रूप में पठनीय होना चाहिए, इसे फ़ाइल-आधारित संचार का उपयोग करके लिखा जाना चाहिए। मसविदा बनाना। एक कार्ड जो जानता है कि प्रत्येक फ़ाइल के सेक्टर के कौन से समूह सदस्य हैं, इसके आस-पास के डीफ़्रैग्मेन्टेशन रूटीन को ऑप्टिमाइज़ कर सकते हैं, और डेटा हानि से बचाने का एक बेहतर काम भी कर सकते हैं, जिसमें डिस्क को स्वतंत्र 512-बाइट के एक गुच्छा के रूप में प्रस्तुत करना होगा। क्षेत्रों, लेकिन बेहतर या बदतर के लिए कि कैसे चीजें निर्दिष्ट नहीं हैं।

Comments

मुझे लगता है कि पहले से ही एक मानक समाधान है: शीर्ष पर एक मानक फाइल सिस्टम (NTFS, HFS +, ext4) के साथ एक ब्लॉक-रीमैपिंग परत। और इसका उपयोग मोबाइल के साथ-साथ एंड्रॉइड पर भी किया जाता है। कैमरा OS अधिक आदिम हो सकता है, लेकिन इसे ठीक करने की आवश्यकता है।

— Vaddadi कार्तिक

@KartickVaddadi: ब्लॉक-रीमैपिंग परत मानक है; मेरी बात यह थी कि यदि मेमोरी कार्ड जिसने ब्लॉक-रीमैपिंग परत को लागू किया था, वह कम से कम कुछ हद तक फाइल-सिस्टम लेआउट का संज्ञान था, तो वह इस तरह के ज्ञान के बिना रीमैपिंग लेआउट को अधिक प्रभावी ढंग से अनुकूलित कर सकता था।

— सुपरकैट

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

— वद्दि कार्तिक

@KartickVaddadi: मैंने विभिन्न बाधाओं के साथ एम्बेडेड उपकरणों के लिए कुछ वियर-लेवलिंग फ्लैश फाइल सिस्टम तैयार किए हैं। अगर पहनने के स्तर को बताया जाता है तो "मैं एक फाइल लिखना चाहता हूं; यहाँ

— सुपरकैट

... यहाँ डेटा है; बस। मैं एक और फाइल लिखना चाहता हूं; यहां डेटा है; ऐसा है ", यह कुछ हद तक समझदारी से व्यवहार कर सकता है अगर इसे बस काम करने के लिए अलग-अलग क्षेत्रों का एक गुच्छा दिया जाता है और पता नहीं है कि वे क्या प्रतिनिधित्व करते हैं। अन्य बातों के अलावा, प्रत्येक फ़ाइल से जुड़े सभी डेटा ब्लॉक को टैग के साथ चिह्नित किया जा सकता है। उदाहरण के लिए "फ़ाइल आईडी 193,291,374 का ब्लॉक 347, 273,837,199 अपडेट करें।"

— सुपरकैट

Answer 8

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

http://www.cgsecurity.org/wiki/PhotoRec

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

Comments

मुझे लगता है कि मैंने उस मामले में PhotoRec का उपयोग किया था। वैसे भी लिंक के लिए धन्यवाद।

— वदादी कार्तिक

Answer 9

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

2, जर्नलेड FSs अचानक OS-विफलता या अचानक बिजली-विफलता जैसे अवसरों के लिए बनाए जाते हैं। वे एफएस मेटा-डेटा को सुसंगत रखते हैं, जब वे खराब चीजें होती हैं। यदि आप चाहते हैं कि आपकी हटाई गई फाइलें वापस न आएं तो वे मदद नहीं कर रहे हैं।

3, बैड-ब्लॉक NAND FLASH आधारित स्टोरेज की सबसे महत्वपूर्ण समस्या है। राइटिंग होने पर बैड-ब्लॉक आते हैं। इसलिए, जब एक नंद फ्लैश स्टोरेज के लिए एफएस चुनते हैं, तो लेखन आवृत्ति पहली चीज है जिसे आपको विचार करना चाहिए। जाहिर है, जैसा कि अन्य सभी ने कहा, जर्नलेड एफएस लिखने के लिए और चीजें लाते हैं।

4, जर्नल एफएस निश्चित रूप से अधिक शक्ति लेते हैं। अधिक जटिल, निश्चित। लेकिन ये प्रमुख कारण नहीं हैं कि हम उन्हें NAND FLASH के लिए नहीं अपनाते हैं, मुझे लगता है।

TADA ~~ यही है।

Comments

1. एजे के जवाब पर मेरी टिप्पणी देखें। 2. मैंने फ़ाइलों को मैन्युअल रूप से नहीं हटाया। 3. जैसे मैंने अन्य टिप्पणियों पर लिखा, आप फ्लैश पर एक जर्नल एफएस के एंड्रॉइड के उपयोग की व्याख्या कैसे करते हैं? यह उतना बुरा नहीं है जितना आप इसे करने के लिए बना रहे हैं। कार्ड जीवनकाल में सीमांत कमी की तुलना में फ़ोटो न खोना अधिक महत्वपूर्ण है।

— वदादी कार्तिक

अधिकांश जर्नल एफएस को अपनी "पत्रिकाओं" का प्रबंधन करने के लिए एक या अधिक डेमॉन प्रक्रियाओं / थ्रेड्स की आवश्यकता होती है। (उदाहरण के लिए, EXT3 के लिए लिनक्स में kjournald) अगर ev एक पूर्ण विकसित OS नहीं है, तो उन्हें अपनाना कठिन होगा, जहाँ हमें प्रक्रिया / थ्रेड की कोई अवधारणा नहीं है।

— गार्फ

@KartickVaddadi फिर, कृपया कुछ शोध को यह संकेत दें कि एक जर्नलेड फाइल सिस्टम कार्ड के जीवनकाल में केवल "सीमांत" कमी पैदा करता है। यह दूसरी बार है जब आपने इसे माना है।

— फिलिप केंडल

निष्पक्ष प्रश्न, लेकिन ध्यान रखें कि एंड्रॉइड इसका उपयोग करता है, जैसा कि मैंने पहले ही कई बार कहा था। अगर वे मीडिया के जीवन में भारी कमी का कारण बनते, तो वे इसका इस्तेमाल नहीं करते? इसके अलावा, मैं आपसे केवल शोध का हवाला देते हुए पूछ सकता हूं कि यह जीवन में भारी कमी का कारण बनता है :)

— वड्डदी कार्तिक

शायद हमें सिर्फ @supercat से पूछना चाहिए, क्योंकि वह एक विशेषज्ञ है, और हम में से किसी ने भी डेटा का हवाला नहीं दिया है।

— वदादि कार्तिक

Answer 10

फ़ाइल सिस्टम को स्वयं जटिल होने की आवश्यकता नहीं है क्योंकि छवियां केवल कार्ड पर लिखी जाती हैं, आरंभिक निर्माण के बाद फ़ाइल में शायद ही कोई संपादन किया जाता है और साथ ही साथ फ़ाइल I / O की चिंता नहीं होती है जिसके बारे में चिंतित होने की आवश्यकता होती है कैमरे पर।

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

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

Comments

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

— वदादि कार्तिक

@KartickVaddadi - क्या आपको यकीन है कि यह फाइल सिस्टम था जो भ्रष्ट हो गया था और एसडी कार्ड ही नहीं था? एक एफएटी तालिका के साथ एक फ़ाइल भ्रष्टाचार का मुद्दा कभी भी पूरे कार्ड की विफलता का परिणाम नहीं होना चाहिए, यह तब तक आसानी से पुनर्प्राप्त करना चाहिए जब तक कि कार्ड स्वयं विफल नहीं हो जाता। कैसे आप सुनिश्चित हैं कि क्या वास्तव में विफल रहे।

— ए जे हेंडरसन

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

— वदादि कार्तिक

@KartickVaddadi - हाँ, लेकिन यह एक फ़ाइल सिस्टम या SD कार्ड विफलता हो सकती है। यदि TOC का सफाया हो जाता है, तो आप अभी भी फ़ाइल सिस्टम पर पुनर्प्राप्ति करने जा रहे हैं, भले ही आप FAT या NTFS का उपयोग करें। मुझे अभी भी यकीन नहीं है कि एक जर्नलेड फ़ाइल सिस्टम मदद करेगा। एक जर्नल फाइल सिस्टम की मुख्य ताकत सिर्फ इतनी है कि यह आंशिक रूप से लिखी जा रही फाइल से उबर सकता है क्योंकि यह जानता है कि फाइल या निर्देशिका रिकॉर्ड खराब है। आप जिस चीज के साथ काम कर रहे हैं, वह सबसे अधिक संभावना है कि आवंटन तालिका में भ्रष्टाचार था जो डिस्क या फाइल सिस्टम विफलता हो सकती है।

— ए जे हेंडरसन

@KartickVaddadi: मुझे लगता है कि सिद्धांत की बात के रूप में एक को हमेशा हाथ पर एक अतिरिक्त कार्ड रखने की कोशिश करनी चाहिए, और अगर कार्ड का उपयोग किया जाता है, तो कोई भी परेशानी का संकेत तुरंत स्पेयर पर दिखाता है, ताकि किसी भी डेटा को नष्ट करने से बचें। समस्याग्रस्त कार्ड से पुनर्प्राप्त करने योग्य होता।

— सुपरकैट