जैसा कि मैंने Reiser4 के लिए LZ4 संपीड़न प्लगइन लिखा था

मैं यह नहीं बताऊंगा कि Reiser4 क्या है और इसके साथ क्या खाया जाता है, क्योंकि इस [ 1 , 2 ] पर पर्याप्त जानकारी है और मुझे इसे दोहराने का कोई कारण नहीं दिखता है। इसलिए, मैं इस तथ्य से शुरू होता हूं कि मैंने 2010 में Reiser4 को आजमाने का फैसला किया था, लेकिन टेल पैकेजिंग के साथ पारदर्शी संपीड़न का उपयोग करने में समस्याओं के कारण (जैसा कि यह निकला कि वर्तमान में हल की गई फ्लश प्रक्रिया में समस्याएं थीं [ 3 ]), मैं वापस ReiserFS में वापस आ गया। 2013 में, मुझे पता चला कि यह समस्या हल हो गई थी [ 4 ] और मैं Reiser4 (LZO1 एक स्थिर प्रणाली पर, बिना किसी संपीड़न के लैपटॉप पर) में लौट आया। कुछ समय बाद, मुझे "एक्सट्रीमली फास्ट कंप्रेशन एलगोरिदम" एलजेड 4 के बारे में समाचार याद आया, साथ ही इस तथ्य के बारे में भी कि ज़ीएफएस में इलुमोस समुदाय ने इसके लिए समर्थन जोड़ा। तब मुझे इस विचार से दौरा पड़ा: "यह बहुत अच्छा होगा अगर Reiser4 को LZ4 का समर्थन मिले!" इसलिए मैंने इसे Reiser4 को "संलग्न" करना शुरू कर दिया।

सबसे पहले, मैंने ccreg40 प्लगइन कोड को देखा (जैसा कि आप जानते हैं कि Reiser4 में एक प्लगइन संरचना है)। यह सब फ़ाइल fs / reiser4 / plugin / compress / compress.h के साथ शुरू होता है जिसमें reiser4_compression_id गणना है:

typedef enum { LZO1_COMPRESSION_ID, GZIP1_COMPRESSION_ID, LAST_COMPRESSION_ID, } reiser4_compression_id; 

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

हम फ़ाइल fs / reiser4 / plugin / compress / compress.c में जारी रखते हैं , जिसमें हम पहले से ही सीधे फ़ंक्शन का वर्णन करते हैं। केवल 7 मुख्य कार्य:

• init () - आवश्यकता है अगर एल्गोरिथ्म को किसी चीज के प्रारंभिक प्रारंभिककरण की आवश्यकता होती है। न तो GZIP1, न ही LZO1, और LZ4 को इसकी आवश्यकता नहीं है, इसलिए वे सिर्फ 0 लौटाते हैं।
• उग आया () - "पूंछ" का अधिकतम आकार लौटाता है जो संपीड़न के दौरान बन सकता है। उदाहरण के लिए, यदि आप "पूंछ" को ध्यान में नहीं रखते हैं, तो असंगत इनपुट डेटा के साथ, आउटपुट बफर सीमा से परे चला जाएगा। उदाहरण के लिए, GZIP1 के लिए यह मान 0 है, LZO1 "src_len / 64 + 19" के लिए, और LZ4 के लिए "src_len / 255 + 16"।
• आवंटित () - एल्गोरिथ्म जरूरतों के लिए स्मृति आवंटित करता है।
• मुक्त () - एल्गोरिथ्म की जरूरतों के लिए आवंटित स्मृति को रिहा करता है।
• min_size_deflate () - न्यूनतम ब्लॉक आकार लौटाता है जो अभी भी संपीड़ित करने के लिए समझ में आता है।
• संपीड़ित () - डेटा संपीड़ित करता है।
• डीकंप्रेस () - डेटा अनपैक।

मैं आवंटन () / नि: शुल्क () कार्यों पर ध्यान केंद्रित करूंगा। उनके द्वारा स्वीकार किए जाने वाले तर्कों में से एक प्रकार tfm_action का तर्क है। tfm_action हेडर फ़ाइल fs / reiser4 / plugin / compress /h में वर्णित गणना है (इसमें reiser4_compression_id के समान संरचना है), जिसमें दो तत्व TFMA_READ और TFMA_WRITE हैं।

 typedef enum { TFMA_READ, /* decrypt, decompress */ TFMA_WRITE, /* encrypt, compress */ TFMA_LAST } tfm_action; 

इस प्रकार, पढ़ने या लिखने के समय, फ़ंक्शन कॉल को निर्धारित करना संभव है। कुछ एल्गोरिदम को अपघटन के लिए अतिरिक्त मेमोरी की आवश्यकता होती है, और इस प्रकार हम सही मात्रा में मेमोरी आवंटित करते हैं। उदाहरण के लिए, GZIP1 एल्गोरिथ्म को अतिरिक्त मेमोरी की आवश्यकता होती है और हम इसे इसके लिए आवंटित करते हैं, लेकिन LZO1 / LZ4 एल्गोरिदम को इसकी आवश्यकता नहीं होती है और हम इसे आवंटित नहीं करते हैं।

सब कुछ एक ही compress.c फ़ाइल में समाप्त होता है, जिसमें संपीड़न_प्लाजिन सरणी का वर्णन है, जिसमें हम प्लग-इन के प्रकार, इसकी पहचान संख्या, हेडर, फ़ंक्शन आदि का संकेत देते हैं।

  [LZ4_COMPRESSION_ID] = { .h = { .type_id = REISER4_COMPRESSION_PLUGIN_TYPE, .id = LZ4_COMPRESSION_ID, .pops = &compression_plugin_ops, .label = "lz4", .desc = "lz4 compression transform", .linkage = {NULL, NULL} }, .init = lz4_init, .overrun = lz4_overrun, .alloc = lz4_alloc, .free = lz4_free, .min_size_deflate = lz4_min_size_deflate, .checksum = reiser4_adler32, .compress = lz4_compress, .decompress = lz4_decompress } 

अब मैं LZ4 कोड में क्या बदल गया हूं। आरंभ करने के लिए, मैंने Microsoft विज़ुअल स्टूडियो से जुड़े सभी कोड को हटा दिया (शायद किसी दिन वे एमएस वीएस कंपाइलर का उपयोग करके लिनक्स कर्नेल का निर्माण करेंगे, लेकिन जाहिर है कि यह निकट भविष्य में नहीं होगा) और सी ++ (एक बाहरी "सी")। फिर उन्होंने बिगइंडियन सिस्टम के लिए अनुकूलन से संबंधित कोड को हटा दिया, जिससे आउटपुट की जानकारी लिटिलएंडियन सिस्टम के साथ असंगत हो गई और कोड जो सामान्य के बजाय स्टैक मेमोरी का उपयोग करने की अनुमति देता है (यह तेजी से बाहर हो जाएगा, लेकिन हम कर्नेल में हैं, ऐसी स्वतंत्रता व्यर्थ नहीं होगी)। अंत में, मैंने कोड से मॉलोक () / नि: शुल्क () फ़ंक्शन को हटा दिया, फ़ंक्शन तर्क की सूची में एलजेड 4 की जरूरतों के लिए आवंटित मेमोरी में एक सूचक जोड़कर (याद रखें आवंटित) ()।

खैर, अब सबसे महत्वपूर्ण बात यह है कि यह सब कैसे काम किया ... स्पष्ट रूप से, बुरी तरह से। LZ4 प्लगइन LZO1 प्लगइन की तुलना में अधिक धीरे और संकुचित काम करता है। एकल-उपयोगकर्ता मोड में, लाइव सिस्टम पर माप किए गए थे। माप में विभाजन को अनमाउंट करने का संचालन शामिल था (ताकि सिंक / फ्लश प्रक्रियाएं काम की गईं और फाइलें पूरी तरह से डिस्क पर लिखी गईं)। तीन परीक्षण किए गए: शून्य फाइल (जो / dev / शून्य से) के साथ ज़िप की गई डिस्क की रेखीय लेखन / रीडिंग, एक असंगत फ़ाइल का रेखीय पढ़ना / लिखना (पहले / dev / urandom से लिया गया था और मेमोरी में tmpfs को लिखा गया था) और Linux कर्नेल स्रोत कोड का अनपैकिंग / संपीड़न संस्करण 3.9.5। सभी परीक्षणों में, LZ4 के साथ प्लगइन ने केवल एक फायदा दिखाया जब एक फ़ाइल को शून्य के साथ लिखना / पढ़ना। अन्य सभी परीक्षणों में, LZO1 ने संपीड़न / विघटन की गति और अंतिम फ़ाइल आकार में LZ4 को बेहतर बनाया।

आगे के अध्ययन के दौरान (LZ4 और lz4c बनाम lzop से फुलबेंच), यह पाया गया कि LZ4 अपने सभी गुणों को छोटे ब्लॉकों के साथ खो देता है, और घोषित गुणों को प्रदर्शित करता है [ 5 ] केवल बड़े ब्लॉकों पर, उदाहरण के लिए डिफ़ॉल्ट फुलबेंच 4MiB, में। lz4c 8MiB। जैसा कि एडुआर्ड शिश्किन ने कहा: "4MiB थोड़ा बहुत है। LZO1 टुकड़ों को संकुचित करता है और बहुत छोटा होता है .. ”[ 6 ]

इस प्रकार, मुझे पता चला कि Reiser4 LZO1 के लिए LZ4 की तुलना में अधिक बेहतर विकल्प है। वैसे, कुछ मुझे बताता है कि LZ4 का समर्थन, जो समुदाय द्वारा जोड़ा गया था, ZFS में हमेशा ही प्रकट नहीं होगा (हालाँकि हमेशा LZJB के साथ तुलना में), और लिनक्स 7 - 7 में LZ4 को धकेलने के असफल प्रयास (उपयोग के अवसर के रूप में) इसके लिए कर्नेल कम्प्रेशन या इनट्राम) पुष्टि करता है। के रूप में btrfs में LZ4 के लिए ... एडवर्ड शिश्किन ने स्पष्ट रूप से बताया कि btrfs [ 8 ] क्या है और इसे कैसे विकसित किया जा रहा है।

---

लिनक्स 3.9 के लिए पैच Reiser4
पैच LZ4 Reiser4 के लिए
PS फ़ंक्शन LZ4_decompress_safe () को थोड़ा रिड्यूस करने की आवश्यकता है, लेकिन इसका कोई मतलब नहीं है, इसलिए मैंने ऐसा नहीं किया।
Reiser4progs के लिए पैच
[१] habrahabr.ru/post/45873
[२] http://theoks.net/~onekopaka/Reiser4Site/v4.html
[३] marc.info/?l=reiserfs-devel&m=135146138331012ww/2
[४] sourceforge.net/p/reiser4/discussion/general/thread/2bca4fye
[५] कोड
[६] sourceforge.net/p/reiser4/discussion/general/thread/780facb4
[[] Lwn.net/Articles/534168
[[] Habrahabr.ru/post/108629