कॉपी करते समय लिनक्स के लिए कॉपी-ऑन-राइट में क्या गलत है

चेतावनी: यह लेख लिनक्स पर सभी सीओडब्ल्यू फ़ाइल सिस्टम पर लागू होता है जो कॉपी करते समय रिफ्लक्स का समर्थन करते हैं। फिलहाल, ये हैं: BTRFS, XFS और OCFS2।

कृपया उन होलीवरों से बचना चाहिए जिनके बारे में FS बेहतर है: Btrfs, XFS, Reiser4, NILFS2, ZFS या कुछ असंबद्ध।

प्रागितिहास

• 21 जुलाई, 2001 - नेम्सिस ने Reiser4 की घोषणा प्रकाशित की। DARPA विकास को प्रायोजित करता है।
• 20 नवंबर, 2003 - नेम्स ने कुछ Reiser4 बेंचमार्क प्रकाशित किए।
• 24 अगस्त, 2004 - नेम्सिस Reiser4 की एक सार्वजनिक रिलीज़ करता है ।
• 14 सितंबर, 2004 - जेडएफएस घोषणा।
• 16 नवंबर, 2005 - ZFS OpenSolaris build 27 में शामिल है।
• सितंबर 2006 - हंस रीज़र को पत्नी नीना रेज़र की हत्या के लिए गिरफ्तार किया गया। नेमेस के अंत की शुरुआत
• 12 जून, 2007 - क्रिस मेसन (पूर्व नाम कर्मचारी) द्वारा Btrfs घोषणा ।
• 22 सितंबर, 2011 - ZFSonLinux में रिफ्लिन कार्यान्वयन के अनुरोध के साथ एक टिकट दिखाई दिया।
• 2012 - Btrfs को स्थिर ओरेकल लिनक्स और एसयूएसई लिनक्स एंटरप्राइज के रूप में मान्यता मिली
• 21 जनवरी, 2013 - लिनक्स कर्नेल के स्रोत कोड में Btrfs के साथ प्रयोग लेबल हटा दिया गया था ।
• मई 2019 - आरएचईएल 8 से हटाए गए Btrfs (ओरेकल द्वारा पदोन्नत Btrfs के रूप में संदिग्ध राजनीतिक कारण)

CoW फाइल सिस्टम में कॉपी एक्सपेक्टेशंस

जब 2001 में Reiser4 की घोषणा की गई, तो मैं Copy-on-Write सुविधाओं के बारे में प्रेरित और भावुक था। जरा सोचिए, हम आसानी से और आसानी से जितनी चाहें उतनी परियोजनाओं की कई प्रतियाँ अपने पास रख सकते हैं, और शारीरिक रूप से डिस्क केवल उनके बीच के अंतरों को संग्रहीत करेगी!

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

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

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

ZFS को लिनक्स के साथ असंगत लाइसेंस के तहत प्रकाशित किया गया था, और इसलिए इसे कर्नेल में शामिल नहीं किया गया था। इसलिए, लिनक्स में जेडएफएस की शुरूआत लंबे समय तक धीमी हो गई थी।

उसके बाद मैं Btrfs की प्रतीक्षा करने लगा। और घोषणा के केवल 6 साल बाद, यह लिनक्स कर्नेल के डेवलपर्स द्वारा स्थिर के रूप में पहचाना गया था।

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

एचडीडी के लिए, विखंडन प्रदर्शन को मारता है, क्योंकि रीड हेड के ब्लॉक को बदलने की प्रक्रिया बहुत लंबा ऑपरेशन है।

इसलिए, मैंने व्यक्तिगत रूप से अपनी मशीनों पर btrfs के कार्यान्वयन को तब तक के लिए स्थगित कर दिया, जब तक कि वे SSD पर स्विच नहीं हो गए।

मैं ध्यान देता हूं कि एसएसडी भी विखंडन को पसंद नहीं करते हैं, हर कोई जानता है कि एसएसडी के लिए, रैखिक लेखन / रीड यादृच्छिक उपयोग की तुलना में दस गुना तेज हो सकता है।

लेकिन एक खंडित SSD का प्रदर्शन HDD की तरह नाटकीय नहीं है।

तो, सीओडब्ल्यू के साथ प्रतिलिपि गति के बारे में क्या?

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

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

कुछ समय बाद, मैंने परीक्षण करने का फैसला किया। और मेरी बड़ी निराशा के लिए, मुझे नकल करते समय सीओडब्ल्यू से कोई गति नहीं बढ़ी। यहाँ एक SATA SSD पर परिणाम है:

time cp -a /usr /usr1 real 0m15,572s user 0m0,240s sys 0m4,739s 

यह पता चला कि सीओडब्ल्यू का उपयोग करने के लिए आपको एक विशेष कुंजी निर्दिष्ट करने की आवश्यकता है।

 time cp -a --reflink=auto /usr /usr2 real 0m3,166s user 0m0,178s sys 0m2,891s 

केवल इस मामले में हम 5 गुना लाभ देखते हैं। वैसे, फ़ाइल की लंबाई बढ़ने के साथ लाभ का आकार अनिश्चित काल तक बढ़ता है। /usr फ़ोल्डर जो मैंने कॉपी किया है वह ज्यादातर छोटी फाइलें हैं।

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

इस मामले में, मैंने Btrfs अनुभाग पर प्रतिलिपि का परीक्षण किया। लेकिन आपको किसी अन्य CoW फ़ाइल सिस्टम के साथ समान परिणाम मिलेगा जो कि रिफ्लिंक का समर्थन करता है।

क्या समस्या है, बिली?

समस्या सी.पी. डिफ़ॉल्ट रूप से, यह कॉपी करते समय CoW का उपयोग नहीं करता है। हालांकि यह कर सकते हैं।

आप कह सकते हैं - मैं cp का उपयोग नहीं करता। हालांकि, लिनक्स के हुड के तहत, इसका उपयोग लगभग हर जगह किया जाता है। कई कार्यक्रम, जब उन्हें कुछ कॉपी करने की आवश्यकता होती है, तो cp उपयोग करें, न कि उनकी "बाइक" का।

Coreutils डेवलपर्स ने ऐसा अस्पष्ट निर्णय क्यों लिया, जो CoW फाइल सिस्टम के फायदों का आधा हिस्सा पार कर गया?

यह पता चला है कि GNU Coreutils के विकास के लिए जिम्मेदार Pádraig ब्रैडी ने फैसला किया है।

यहाँ उसका तर्क है :

1. डिफ़ॉल्ट रूप से, cp CoW का उपयोग नहीं करता है, क्योंकि फ़ाइल सिस्टम के नष्ट होने के बाद फ़ाइल को डिस्क में सहेजने की संभावना बढ़ाने के लिए कोई भी नकल का उपयोग कर सकता है।
2. प्रदर्शन के संदर्भ में, यदि किसी प्रकार की विलंब-संवेदनशील प्रक्रिया है, तो आप चाहते हो सकता है कि मुख्य रिकॉर्ड प्रतिलिपि बनाने के दौरान बनाया जाए, इसलिए यदि बाद में ऐसा होता है, तो हार्ड ड्राइव के प्रमुखों का विरोध करते समय एक अंतराल हो सकता है। कृपया ध्यान दें कि संस्करण 8.24 कोरुटिल्स से शुरू होकर, एमवी डिफ़ॉल्ट रूप से रिफ्लिन विकल्प का उपयोग करता है।

Pádraig ब्रैडी अंग्रेजी में उत्तर पाठ

यह मजबूती के कारणों के लिए डिफ़ॉल्ट नहीं है क्योंकि कोई व्यक्ति डेटा भ्रष्टाचार से बचाने के लिए कॉपी ले सकता है। प्रदर्शन के कारणों से भी आप लिख सकते हैं कि सीओडब्ल्यू फ़ाइल पर काम करने वाली कुछ विलंबता संवेदनशील प्रक्रिया के बजाए कॉपी समय पर हो सकती है और राइट्स द्वारा यांत्रिक डिस्क के एक अलग हिस्से में संभवतः देरी हो रही है। ध्यान दें कि coreutils से v8.24 mv डिफ़ॉल्ट रूप से रीफ़्लिंक होगा, क्योंकि इसमें उपरोक्त बाधाएँ नहीं हैं।

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

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

पडरैग तर्क पार्सिंग

पहला तर्क कुछ समझ में आता है। अनुभवहीन उपयोगकर्ता वास्तव में एक ही फाइल सिस्टम पर मूल्यवान फाइलों का बैकअप ले सकते हैं।

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

हालाँकि, CoW सिस्टम पर, डेटाबेस फ़ाइल में लिखते समय देरी या "आउट ऑफ़ स्पेस" त्रुटि प्राप्त करना वास्तव में संभव है। इससे बचने के लिए, आपको शुरू में डेटाबेस के लिए CoW अक्षम के साथ एक खाली निर्देशिका बनाने की आवश्यकता है।

इस तरह निर्देशिका / फ़ाइल पर CoW अक्षम करें:

 chattr +C /dir/file chattr +C /dir/dir 

नोडोडैको माउंट करने का विकल्प भी है। यह सभी नई बनाई गई फाइलों पर लागू होगा।

लेकिन क्या होगा यदि हम डिफ़ॉल्ट रूप से कॉपी करते समय सीओडब्ल्यू का उपयोग करना चाहते हैं?

1. मूल तरीका कोरुटिल्स को पैच करना है। शायद अपने निजी भंडार में अपना पैकेज बनाएँ।
   
   पैच cp.c फ़ाइल:
   
   

    -x->reflink_mode = REFLINK_NEVER; +x->reflink_mode = REFLINK_AUTO; 

2. एक कम कट्टरपंथी समाधान अपने खोल के लिए एक सी.पी. उपनाम लिखना है। उदाहरण के लिए बैश के लिए:
   
   /etc/profile.d फ़ोल्डर में, सामग्री के साथ cp_reflink.sh cp_reflink.sh बनाएँ:
   
   

    #!/bin/bash alias cp='cp --reflink=auto' 

   
   यह समाधान लगभग सभी मामलों में काम करेगा जब cp को शेल द्वारा नाम से एक्सेस किया जाएगा। लेकिन अगर लिपियों में / बिन / सीपी का उपयोग किया जाएगा, तो उपनाम काम नहीं करेगा और नकल हमेशा की तरह होगी।

फ़ाइल प्रबंधक और Reflink

31 अक्टूबर, 2019 तक की स्थिति:

• मध्यरात्रि कमांडर - समर्थन करता है।
• क्रूसेडर - समर्थन नहीं करता है।
• डॉल्फिन - समर्थन नहीं करता है।
• नॉटिलस - समर्थन नहीं करता है।
• निमो - का समर्थन करता है।

प्रोग्रामिंग भाषा, सिस्टम कॉल और रीफ्लिंक

अधिकांश प्रोग्रामिंग भाषाओं में रिफ्लिंक सपोर्ट नहीं है।
सी में, कई प्रोग्रामर अभी भी लूप और बफ़र्स का उपयोग करके कॉपी करते हैं ।

Sendfile सिस्टम कॉल reflink का उपयोग नहीं करता है।
cp FICLONE ध्वज के साथ ioctl सिस्टम कॉल का उपयोग करता है।

मुझे लगता है कि अगर आपको कोड में कुछ कॉपी करने की आवश्यकता है, तो इसे करना उचित है क्योंकि cp करता है या सिर्फ cp --reflink=auto ।

निष्कर्ष

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

वर्तमान में, केवल 3 फ़ाइल सिस्टम इस प्रकार की प्रतिलिपि का समर्थन करते हैं: BTRFS, XFS और OCFS2।

मुझे पूरी उम्मीद है कि ZFS और NILFS2 में रिफ्लिंक सपोर्ट पूरा हो जाएगा, क्योंकि वे पहले से ही आंतरिक तंत्र द्वारा CoW का समर्थन करते हैं।

हालाँकि, सभी लिनक्स वितरणों में, फ़ाइलों की प्रतिलिपि बनाते समय CoW को निष्क्रिय कर दिया जाता है, और हमें या तो स्पष्ट रूप से संबंधित कुंजियों को निर्दिष्ट करने की आवश्यकता होती है, या विभिन्न चालें जैसे उपनाम या पैच का उपयोग करना होता है।

Reiser4 की घोषणा को 18 साल बीत चुके हैं, हालांकि, अभी तक लाइटवेट CoW नकल हर जगह हमारे जीवन में प्रवेश नहीं किया है।

पीएस डोकर और सीओडब्ल्यू

क्या आप जानते हैं कि Docker अपने स्टोरेज के लिए btrfs का समर्थन करता है। यह विकल्प सक्षम होना चाहिए। यह डिफ़ॉल्ट रूप से चयनित नहीं है।

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

मेरी राय में, यह OverlayFS और Aufs की तुलना में बहुत अधिक जैविक है, जो COW का अनुकरण करने के लिए तकनीकी बैसाखी हैं।

Docker में Btrfs का उपयोग करने के लिए आपको चाहिए:

1. डॉकर की एक ताजा (बिना छवियों और आभासी मशीनों) की स्थापना में, एक अलग Btrfs मात्रा को /var/lib/docker माउंट करें
2. डॉकर लॉन्च कॉन्फ़िगरेशन फ़ाइल में विकल्प जोड़ें

Gentoo और गणना लिनक्स के लिए, यह /etc/conf.d/docker

 DOCKER_OPTS="--storage-driver btrfs --data-root /var/lib/docker" 

और यहां सभी वितरण के लिए पूर्ण निर्देश है ।

टिप्पणियों से जोड़

XFS और CoW

constb ( स्रोत ): XFS पर, CoW भी हमेशा समर्थित नहीं है। आपको mkfs.xfs -m reflink=1 साथ एक फ़ाइल सिस्टम बनाने की आवश्यकता है।
पहले से ही निर्मित FS पर, आप CoW समर्थन को "सक्षम" नहीं कर सकते। साथ ही, कर्नेल पर 4.11 तक इस विकल्प को शामिल करने से dmesg में लाल चेतावनी का कारण बनता है कि यह सुविधा प्रयोगात्मक है।

MacOS और CoW

MMik ( स्रोत ): OS X में, cp कमांड का एक समान विकल्प -c ।

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

ओएस एक्स 10.12 (सिएरा) और केवल एपीएफएस फाइल सिस्टम पर समर्थित है।

---

धन्यवाद:

• उनके समर्थन के लिए RUVDS कंपनियां और हैबे पर अपने ब्लॉग पर प्रकाशित करने का अवसर।
  
• प्रति छवि ट्रिपलकॉन्सेप्ट ।

PPS एक व्यक्तिगत में देखी गई त्रुटियों को निर्देशित करें। मैं इसके लिए कर्म बढ़ाता हूं।

---

नीचे के कूपन के साथ RUVDS से वर्चुअल मशीन मंगवाकर आप CoW फाइल सिस्टम के साथ प्रयोग कर सकते हैं।