2010-07-21 27 views
6

मैं एक फ़ाइल स्टोरेज तंत्र को कार्यान्वित करने की कोशिश कर रहा हूं जिसमें एक फ़ाइल में कई अलग-अलग आकार के रिकॉर्ड्स हैं, गारंटी के साथ कि रिकॉर्ड का सेट हमेशा एक स्थिर स्थिति में पुनर्प्राप्त करने योग्य होगा, भले ही सिस्टम हार्डवेयर में विफल हो स्तर।क्या स्मृति-मैप की गई फ़ाइल में डेटा क्रमशः फ्लश करने की गारंटी है?

अभी तक, प्रत्येक योजना मैं अनुक्रमिक रूप से डेटा लिखने पर पिवट के साथ आया हूं। डेटा का कुछ टुकड़ा प्रत्येक रिकॉर्ड के अंत में जोड़ा जाएगा जो पुष्टि करता है कि लेखन सफल हुआ। हालांकि, अगर फ्लैश होने पर डेटा को क्रमशः डिस्क पर लिखा नहीं जाता है तो सामग्री डेटा से पहले पुष्टिकरण डेटा लिखा जाना संभव होगा।

इस के आसपास दो स्पष्ट तरीके हैं, लेकिन दोनों अवांछनीय हैं:

  1. सामग्री फ्लश और फिर पुष्टि लिख सकते हैं और यह फ्लश। अतिरिक्त फ्लश जोड़ने से प्रदर्शन खराब हो सकता है।
  2. पुष्टिकरण में चेकसम शामिल करें (यह पुष्टि करने के लिए सामग्री को पढ़ने की आवश्यकता होगी कि यह मान्य है)।

मैं उपयोग कर रहा हूँ Windows पर सी # (32 और 64-बिट) और नेट 4.0 की स्मृति मैप की गई फ़ाइल कार्यान्वयन

+0

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

उत्तर

1

यह बहुत कम स्तर और सी # के लिए ओएस विशिष्ट है। सी से विंडोज एपीआई का उपयोग करने का प्रयास करें, और एपीआई विनिर्देशों को बहुत सावधानी से पढ़ें।

0

क्या आपने अंतर्निहित फाइलस्ट्रीम पर FileOptions.WriteThrough का उपयोग करने का प्रयास किया है? इससे मदद मिल सकती है क्योंकि यह बफरिंग को अक्षम करता है। अन्य विचारों को अंतिम लिखित ऑफ़सेट के रूप में पुष्टिकरण वाली एक अलग फ़ाइल रखना होगा, यदि यह आपके फाइलसाइज़ से मेल नहीं खाता है (उदाहरण के लिए पावर आउटेज के कारण) तो आप इसे आसानी से कर सकते हैं कि आकार

+1

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

+0

@ केनेट बेलेन्की: फ्लशिंग के बारे में बात अजीब है, [जावा] (http://docs.oracle.com/javase/1.4.2/docs/api/java/nio के साथ तुलना करें) /MappedByteBuffer.html)। हो सकता है कि आप लॉग के लिए एक सामान्य FileOutputStream का उपयोग कर सकें (लॉग छोटा है इसलिए बहुत तेज अंतर नहीं होगा)? IIUYC एक पुष्टिकरण रिकॉर्ड खोने वाला बुरा नहीं है, इसलिए आप लॉग को और अधिक ही कम कर सकते हैं। – maaartinus

+0

@मार्टिनस जावा का एपीआई निश्चित रूप से कारणों के लिए आसान है, लेकिन यह भी सही नहीं है। यह अच्छा है कि यह गारंटी प्रदान करता है कि वापसी पर फ्लश पूरा हो गया है। हालांकि, यह भी अच्छा होगा अगर यह आपको एसिंक अधिसूचना प्रदान करता है ताकि आप अपने व्यवसाय के बारे में जा सकें। 10ms एक कताई-डिस्क फ्लश का समय तलाशने के लिए निष्क्रिय रहने के लिए एक लंबा समय है। –