क्या अल्पकालिक फाइलें डिस्क में प्रवाहित होती हैं?

Question

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

चूंकि फाइलें छोटी हैं, तो मान लें कि उनके आकार का योग इससे छोटा dirty_bytesऔर है dirty_background_bytes।

Ext4 में डिफ़ॉल्ट पत्रिका चालू है, अर्थात मेटाडेटा पत्रिका। मैं यह भी जानना चाहता हूं कि क्या मेटाडेटा या डेटा डिस्क पर लिखा है।

Comments

> मेरा कार्यक्रम कई छोटी-छोटी फाइलों को बनाता है जो 'बहुत कुछ' है? क्या आप इन फ़ाइलों को हटा रहे हैं या फ़ाइलों को फिर से लिख रहे हैं? > मैं यह भी जानना चाहता हूं कि क्या मेटाडेटा या डेटा डिस्क पर लिखा है। मेरा मानना ​​है कि डिफ़ॉल्ट मेटाडेटा मोड का आदेश दिया गया है जिसका अर्थ है कि डेटा को डिस्क पर लिखे जाने से पहले मेटाडेटा प्रतिबद्ध है। बेशक वहाँ माउंट विकल्प आप इसे बदलने के लिए जोड़ सकते हैं। > मेरा सवाल यह है कि क्या मेरे प्रोग्राम में बहुत सारी डिस्क लिखी जाती हैं? यह आपके द्वारा प्रदान की गई जानकारी पर विचार करने के लिए प्रतिक्रिया करने के लिए मुश्किल है। क्या आपने डिस्क IO की निगरानी के लिए iotop और sysstat जैसे टूल का उपयोग करने पर विचार किया है ?

— एंग्रीबोम्बैट

ReiserFS छोटी फाइलों के लिए बेहतर है यदि आप वास्तव में चाहते हैं कि वे डिस्क को कभी हिट करें tmpfs ठीक है अगर आप परवाह नहीं करते हैं

— xenoterracide

कुछ स्पष्टीकरण: (1)। ext4 फाइल सिस्टम syncविकल्प के साथ आरोहित नहीं है । आप एक डिफ़ॉल्ट स्थापित फ़ेडोरा, डेबियन या ubuntu पर विचार कर सकते हैं। तुम एक चुनो। (2)। प्रत्येक फ़ाइल लगभग 60KB है। (3)। लगभग 1000 फाइलें प्रति सेकंड बनाई और नष्ट की जाती हैं, लेकिन किसी भी समय 10 से अधिक फाइलें मौजूद नहीं होती हैं। दूसरे शब्दों में, I / O थ्रूपुट बड़ा है, लेकिन कब्जा कर लिया गया स्थान छोटा है।

— वू योंगझेंग

Answer 1

Ext4 का उपयोग करके एक सरल प्रयोग:

एक 100MB छवि बनाएं ...

# dd if=/dev/zero of=image bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.0533049 s, 2.0 GB/s

इसे लूप डिवाइस बनाएं ...

# losetup -f --show image
/dev/loop0

फ़ाइल सिस्टम और माउंट करें ...

# mkfs.ext4 /dev/loop0
# mount /dev/loop0 /mnt/tmp

थोड़े समय की फाइलों के साथ किसी तरह का रन बनाएं। (इसे अपनी पसंद की किसी भी विधि में बदलें।)

for ((x=0; x<1000; x++))
do
    (echo short-lived-content-$x > /mnt/tmp/short-lived-file-$x
     sleep 1
     rm /mnt/tmp/short-lived-file-$x ) &
done

उम्मंट, सिंक, अनलूप।

# umount /mnt/tmp
# sync
# losetup -d /dev/loop0

छवि सामग्री की जाँच करें।

# strings image | grep short-lived-file | tail -n 3
short-lived-file-266
short-lived-file-895
short-lived-file-909
# strings image | grep short-lived-content | tail -n 3

मेरे मामले में यह सभी फ़ाइल नामों को सूचीबद्ध करता है, लेकिन फ़ाइल सामग्री में से कोई भी नहीं। इसलिए केवल सामग्री नहीं लिखी गई थी।

Comments

अच्छा प्रयास। अब मैं आश्वस्त हूं। मैंने ext2 की भी कोशिश की, और आपके जैसा ही परिणाम मिला। मैंने आपके समांतर I / O कार्यभार को एक क्रमिक रूप से बदल दिया और एक छोटी-जीवित-फाइल -9999 और एक 8 अल्पकालिक सामग्री- * प्राप्त की। क्या किसी के पास कोई स्पष्टीकरण है?

— वू योंगझेंग

@msw: यह स्पष्ट नहीं होने पर संपादित किया गया। अन्यथा कृपया विस्तार से बताएं।

— ठंढकुट्ज़

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

— ठंढकुट्ज़

Answer 2

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

यदि आप वास्तव में डिस्क लिखने से बचना चाहते हैं, तो tmpfs में देखें ,

Comments

tmpfs वास्तव में इस मामले में एक अच्छा फिट है, लेकिन मैं अभी भी जानना चाहता हूँ, सामान्य ऑपरेटिंग सिस्टम प्रश्न के रूप में, डिस्क (अनावश्यक रूप से) को लिखा गया डेटा है?

— वू योंगझेंग

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

— msw

ठीक है, अगर pdflush फाइल डिलीट होने के बाद आता है। इसे लिखना अनावश्यक होगा।

— वू योंगझेंग

Answer 3

एक सामान्य नियम के रूप में, नहीं, वे नहीं लिखे जाएंगे। ऐसा इसलिए है क्योंकि दो शर्तों में से एक के पूरा होने पर कैश गंदा पेजों को फ्लश करता है:

1. डेटा के बाद वृद्ध हो जाता है /proc/sys/vm/dirty_writeback_centisecs, जो 5 सेकंड में चूक जाता है।

2. कैश को डेटा रखने के लिए बहुत कम मेमोरी है, कैश में dirty_ratioगंदे पृष्ठों से अधिक (20% तक चूक)।

तो बहुत सारी मुफ्त मेमोरी वाले सिस्टम पर और 5 सेकंड से कम समय में डिलीट होने वाली आपकी छोटी फाइलों से अलग ट्रैफिक लिखने पर डेटा फ्लश नहीं होगा।

Answer 4

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

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

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

कुछ सिद्धांत

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

if (IS_DIRSYNC(dir))
    (void)fat_sync_inode(dir);
else
    mark_inode_dirty(dir);

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

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

Comments

आपके उत्तर के लिए धन्यवाद। ऐसा लगता है कि ext4 ने भी आवंटन में देरी की है। इसका मतलब यह है कि मेरा जवाब नहीं है? (कहीं और मज़ेदार कॉन्फ़िगरेशन विकल्प नहीं दिए गए)। क्या इसका मतलब यह भी है कि मेरे उत्तर हां है अगर ext2 का उपयोग किया जाता है?

— वू योंगझेंग

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

— ओकाद

मेरा ext4 स्पष्ट रूप से syncविकल्प के साथ मुहिम नहीं किया गया है। मैं ऐसा कदापि नहीं करता।

— वू योंगझेंग

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

— वू योंगझेंग

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

— ओकाद