ZFS scrub: VPS pool के लिए सही schedule क्या है?

ZFS scrub वास्तव में क्या करता है

ZFS scrub पूल में मौजूद हर allocated block को पढ़ता है, उसके checksum की पुनर्गणना करता है, और परिणाम की तुलना parent block pointer में संग्रहीत checksum से करता है। जहाँ दोनों मेल नहीं खाते, ZFS पूल में मौजूद redundancy का उपयोग करके उस block को ठीक कर देता है। ZFS में कोई अन्य प्रक्रिया यह कार्य नहीं करती है। सामान्य reads केवल उन्हीं blocks को सत्यापित करते हैं जिन्हें आप एक्सेस करते हैं, इसलिए जिस फ़ाइल को आपने दो वर्षों से नहीं खोला है, वह तब तक सत्यापित नहीं होती जब तक कि scrub उसे न पढ़ ले।

Scrub कोई fsck नहीं है, जो कि अन्य filesystems के लिए आवश्यक offline repair pass है। इसमें कोई structural repair चरण नहीं होता, क्योंकि ZFS कभी भी on-disk format को टूटी हुई स्थिति में नहीं छोड़ता है: हर write एक नए स्थान पर जाती है और uberblock, जो पूल का root pointer है, सबसे अंत में अपडेट होता है। Scrub पूरी device को भी नहीं पढ़ता है। यह केवल allocated blocks को पढ़ता है, यही कारण है कि लगभग खाली पूल कुछ ही मिनटों में scrub हो जाता है और 80% भरे हुए उसी पूल में काफी अधिक समय लगता है।

Scrub, ZFS की सबसे कम I/O priority पर चलता है। Linux पर, zfs_vdev_scrub_max_active डिफ़ॉल्ट रूप से 2 होता है, इसलिए प्रति vdev (virtual device, disks का समूह जिसे ZFS एक इकाई के रूप में मानता है) अधिकतम दो scrub reads ही सक्रिय रहते हैं। zfs_scrub_min_time_ms डिफ़ॉल्ट रूप से 750 होता है, जो वह न्यूनतम समय है जिसे sync thread transaction group flushes के बीच scrub कार्य पर व्यतीत करता है, जो कि वे periodic commits हैं जिनमें ZFS writes को batch करता है। एक idle machine पर scrub पूरी disk का उपयोग करता है। लोड होने पर यह हट जाता है। एक या दो devices वाले पूल में हटने के लिए कोई जगह नहीं होती है, यही कारण है कि साठ drives वाले बड़े chassis की तुलना में यहाँ scheduling अधिक मायने रखती है।

ऐसे pool को scrub क्यों करें जो खुद को ठीक नहीं कर सकता?

छोटे pool पर यही वह वाक्य है जो बाकी सब कुछ तय करता है। Redundancy न होने पर, scrub corruption का पता तो लगा लेता है लेकिन उसे ठीक नहीं कर सकता। VPS में एक अकेला virtual disk बिना mirror और बिना parity वाला pool होता है। ZFS खराब block को पढ़ेगा, checksum fail होने पर उसे CKSUM कॉलम में गिनेगा, फाइल का नाम बताएगा और वहीं रुक जाएगा, क्योंकि rebuild करने के लिए कोई दूसरी copy मौजूद नहीं होती।

दो आंशिक अपवाद जानने योग्य हैं। ZFS डिफ़ॉल्ट रूप से metadata की एक अतिरिक्त copy (redundant_metadata=all) स्टोर करता है, जिसे device के किसी अलग हिस्से में लिखा जाता है, इसलिए एक-device वाले pool पर भी scrub किसी क्षतिग्रस्त directory entry या block pointer को ठीक कर सकता है। और copies=2 वाला dataset अपने data blocks की दो copies रखता है, जिसके लिए दोगुनी जगह खर्च होती है। इनमें से कोई भी device के पूरी तरह खराब होने पर नहीं बचता। copies property का documentation ठीक इसी बारे में चेतावनी देता है: striped pool न बनाएँ, copies=2 सेट न करें, और यह न सोचें कि आपके पास redundancy है।

इसलिए single-device pool पर scrub आपको एक ही चीज़ देता है: समय पर और सटीक सूचना। यह silent corruption को zpool status -v में एक फाइल नाम में बदल देता है, जबकि आपका backup अभी भी उस फाइल का सही version सुरक्षित रखता है। यह backups के पक्ष में एक तर्क है, न कि scrubbing के खिलाफ। यदि आपने point-in-time image और वास्तविक off-box copy के बीच का अंतर स्पष्ट नहीं किया है, तो VPS snapshot backup क्यों नहीं है से शुरुआत करें, क्योंकि scrub का परिणाम तभी काम आता है जब कहीं और एक intact copy मौजूद हो।

जो scrub कुछ भी नहीं ढूँढता, वह भी एक परिणाम है। यह आपको बताता है कि जिस data पर आप भरोसा करने वाले हैं वह सुरक्षित है, और restore या migration से पहले आपको यही जानना होता है।

छोटे VPS पूल को कितनी बार scrub करना चाहिए?

मासिक (monthly) अंतराल एक उचित डिफ़ॉल्ट है, और पैकेज पहले से ही इसी आधार पर काम करते हैं। Debian और Ubuntu में एक cron job होती है जो हर महीने के दूसरे रविवार को स्वस्थ पूल को scrub करती है। FreeBSD की periodic प्रणाली दिनों की एक सीमा (threshold) पर काम करती है, और daily_scrub_zfs_default_threshold का डिफ़ॉल्ट मान 35 है, जिसे मैनुअल में पांच सप्ताह बताया गया है।

एक व्यस्त छोटे पूल पर साप्ताहिक (weekly) scrubbing का खर्च उसके लाभ से अधिक होता है। एक या दो डिवाइस होने पर, scrub आपके एप्लिकेशन के साथ ही कतार (queue) के लिए प्रतिस्पर्धा करता है, और इसे संभालने के लिए कोई अतिरिक्त डिवाइस नहीं होता। VPS पर I/O की अनुमति सीमित होती है, इसलिए scrub द्वारा उपयोग किए गए reads आपके डेटाबेस को नहीं मिल पाते। इस लागत की तुलना में, साप्ताहिक scrubbing आपको किसी ऐसी खराबी के बारे में अधिकतम तीन सप्ताह पहले चेतावनी देती है जिसे आप वैसे भी ठीक नहीं कर सकते। यह समझौता तभी उचित है जब scrubbing सस्ती हो।

समय मापें, फिर निर्णय लें। एक बार हाथ से scrub चलाएं और देखें कि इसमें कितना समय लगता है।

1. sudo zpool scrub tank को एक शांत शाम को चलाएं और zpool status से कुल समय नोट करें।
2. यदि यह एक घंटे से काफी कम समय में पूरा हो जाता है और सर्वर रात में खाली रहता है, तो साप्ताहिक scrubbing किफायती है।
3. यदि पूल के ट्रैफिक संभालने के दौरान इसे चलने में कई घंटे लगते हैं, तो मासिक अंतराल ही रखें और इसे पैकेज्ड जॉब के भरोसे रहने दें।
4. जब भी पूल का आकार काफी बढ़ जाए, तो समय को फिर से मापें, क्योंकि scrub की अवधि आवंटित डेटा पर निर्भर करती है, डिस्क की क्षमता पर नहीं।

आप जो भी चुनें, उसे अपने अन्य आवर्ती सर्वर कार्यों के साथ लिख लें। Scrub को पैकेज अपग्रेड और लॉग रोटेशन जैसी सूची में ही शामिल किया जाना चाहिए: देखें मासिक Linux सर्वर रखरखाव चेकलिस्ट।

Scrub को शुरू, पॉज और स्टॉप करना

sudo zpool scrub tank
sudo zpool status tank

पॉज करना और स्टॉप करना अलग-अलग प्रक्रियाएं हैं, और गलत विकल्प चुनने से आपका घंटों का काम दोबारा करना पड़ सकता है।

sudo zpool scrub -p tank
sudo zpool scrub tank
sudo zpool scrub -s tank

-p पॉज करता है। पॉज की स्थिति और प्रगति समय-समय पर डिस्क पर सिंक होती है, इसलिए पॉज किया गया scrub एक्सपोर्ट या रीबूट के बाद भी बना रहता है: पूल वापस आने पर scrub पॉज स्थिति में ही रहता है, आपके अगले निर्देश की प्रतीक्षा में। zpool scrub को दोबारा चलाने से यह डिस्क पर लिखे गए अंतिम चेकपॉइंट से फिर से शुरू हो जाता है। -s scrub को पूरी तरह रोक देता है, और अगली बार जब आप scrub शुरू करेंगे तो वह शुरुआत से शुरू होगा। जब आपको एक घंटे के लिए डिस्क की आवश्यकता हो, तो -p का उपयोग करें। जब आप scrub को पूरी तरह हटाना चाहते हों, तो -s का उपयोग करें।

दो और फ्लैग्स के बारे में जानना उपयोगी है। -w कमांड वापस आने से पहले scrub के समाप्त होने की प्रतीक्षा करता है, जो कि स्क्रिप्ट के अंदर आवश्यक है ताकि अगला चरण समय से पहले शुरू न हो जाए। -e केवल उन फाइलों को scrub करता है जिनमें zpool status -v द्वारा रिपोर्ट की गई ज्ञात डेटा त्रुटियां हैं, जो यह पुष्टि करने का त्वरित तरीका है कि बैकअप से रिस्टोर की गई फाइल अब ठीक है।

ZFS प्रति पूल एक समय में केवल एक scrub या resilver (डिवाइस बदलने के बाद होने वाला रीबिल्ड) चलाता है, क्योंकि दोनों ही I/O के मामले में बहुत गहन प्रक्रियाएं हैं। यदि कोई डिवाइस resilver हो रहा है, तो आपका scrub अपनी बारी की प्रतीक्षा करेगा।

Scrub चलते समय zpool status कैसे पढ़ें

sudo zpool status tank चलाएं और किसी और के आंकड़ों से मिलान करने के बजाय अपने स्वयं के आंकड़ों को पढ़ें। Scrub के दौरान scan: लाइन में scanned आंकड़ा, issued आंकड़ा, कुल योग, repaired आंकड़ा, पूर्ण होने का प्रतिशत और शेष समय का अनुमान दिखाई देता है।

Scanned मेटाडेटा चरण है: ZFS ब्लॉक ट्री को स्कैन करता है और उन पतों को एकत्रित करता है जिन्हें उसे पढ़ना है। Issued डेटा चरण है: डिस्क पर भेजे गए वास्तविक रीड ऑपरेशंस, जिन्हें डिस्क ऑर्डर के अनुसार व्यवस्थित किया गया है। सॉर्ट किया गया स्क्रब ही वह कारण है जिसके चलते दो काउंटर होते हैं, और issued वह काउंटर है जो वास्तविक प्रगति को ट्रैक करता है। शुरुआत में, scanned का आंकड़ा issued से काफी आगे रहता है और समय का अनुमान बहुत कम सटीक होता है। इसे पहले दस प्रतिशत के बाद ही आंकें।

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

इसके बाद प्रति-डिवाइस कॉलम पढ़ें। READ और WRITE उन I/O त्रुटियों को गिनते हैं जिनकी सूचना डिवाइस ने स्वयं दी है। CKSUM उन ब्लॉकों को गिनता है जो चेकसम सत्यापन में विफल रहे, और CKSUM ही वह कॉलम है जिसे भरने के लिए स्क्रब किया जाता है। एक स्वस्थ दिखने वाले डिवाइस पर गैर-शून्य CKSUM वास्तविक है: डेटा वापस तो आया, लेकिन वह गलत था।

अंतिम लाइन परिणाम है। errors: No known data errors का अर्थ है कि सब ठीक है। इसके अलावा कुछ भी दिखने का मतलब है कि आपको sudo zpool status -v tank चलाना होगा, जो पिछले पूर्ण स्क्रब के बाद से डेटा त्रुटियों की पूरी सूची प्रिंट करता है, जिसमें प्रभावित फाइलनाम भी शामिल होते हैं। उन फाइलों को बैकअप से रिस्टोर करें, काउंटरों को रीसेट करने के लिए sudo zpool clear tank चलाएं, और फिर से स्क्रब करें। प्रत्येक पूर्ण स्क्रब उस सूची को फिर से बनाता है, इसलिए जो फाइलनाम एक पूर्ण और सफल स्क्रब के बाद सूची में नहीं है, वह वास्तव में हट चुका है।

आपके सिस्टम पर कौन सा periodic scrub job चल रहा है?

यह न मानें कि कोई job मौजूद है, और न ही यह मानें कि केवल एक ही है। इसका mechanism platform और package के अनुसार अलग-अलग होता है। Pool का format हर जगह एक समान है, जिससे यह भूलना आसान है कि इसके लिए इस्तेमाल होने वाले tools अलग हैं, और FreeBSD की तुलना में Linux पर ZFS जिस तरह से उपलब्ध है वह अंतर यहाँ मायने रखता है।

FreeBSD पर यह job periodic system में रहता है। इन्हें /etc/periodic.conf में सेट करें:

daily_scrub_zfs_enable="YES"
daily_scrub_zfs_pools="tank"
daily_scrub_zfs_default_threshold="35"

daily_scrub_zfs_pools pool के नामों की एक space-separated सूची है, और इसे खाली छोड़ने पर हर pool scrub हो जाता है। daily_scrub_zfs_default_threshold उन दिनों की संख्या है जो scrub के बीच बीतने चाहिए जब कोई pool-specific threshold सेट न हो, और manual में default मान 35 दिया गया है। यह daily job हर दिन चलता है; यह scrub तभी शुरू करता है जब threshold पूरा हो चुका हो।

Linux पर यह आपके distribution के ZFS package पर निर्भर करता है, और कुछ systems में दोनों mechanisms एक साथ मौजूद होते हैं। इसमें per-pool systemd timers, zfs-scrub-monthly@tank.timer और zfs-scrub-weekly@tank.timer होते हैं, जो एक बार में एक pool के लिए enable किए जाते हैं। Debian और Ubuntu में /etc/cron.d/zfsutils-linux भी होता है, जो एक script चलाता है और महीने के दूसरे रविवार को हर ONLINE pool को scrub करता है। कुछ भी नया जोड़ने से पहले जाँच लें कि आपके पास क्या है:

systemctl list-timers 'zfs-*'
ls /etc/cron.d/ | grep -i zfs
sudo zpool history tank | grep scrub

zpool history ही सही जवाब है, क्योंकि यह उन scrubs को record करता है जो pool ने वास्तव में शुरू किए हैं, तारीखों के साथ। महीने में दो बार scrub होने का मतलब है कि दोनों mechanisms सक्रिय हैं और उनमें से एक को हटा देना चाहिए। Timer को enable करने के लिए:

sudo systemctl enable --now zfs-scrub-monthly@tank.timer

फ्री स्पेस किसी भी ट्यूनेबल से अधिक महत्वपूर्ण है

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

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

इसलिए, पहला उपाय कोई ट्यूनेबल नहीं है। यह चीजों को डिलीट करना है। ZFS बॉक्स पर पुराने स्नैपशॉट्स इसका सामान्य कारण हैं, उसके बाद Docker images and layers जिन्हें किसी ने प्रून नहीं किया है और अपग्रेड के बाद बचे हुए kernel packages आते हैं। किसी भी अन्य चीज को छूने से पहले zfs list -o space चलाएं, क्योंकि यह स्नैपशॉट्स द्वारा घेरे गए स्पेस को लाइव डेटा द्वारा घेरे गए स्पेस से अलग करता है।

अब, संक्षेप में नॉब्स (knobs) के बारे में। Linux पर आप वर्तमान मान पढ़ सकते हैं:

cat /sys/module/zfs/parameters/zfs_scrub_min_time_ms
cat /sys/module/zfs/parameters/zfs_vdev_scrub_max_active

FreeBSD इन्हीं पैरामीटर्स को sysctl के माध्यम से दिखाता है, इसलिए sysctl -a | grep scrub के साथ अपना मान खोजें। इन्हें बढ़ाने से स्क्रब जल्दी पूरा होता है और आपकी एप्लीकेशन धीमी हो जाती है। इन्हें कम करने से इसका उल्टा होता है। एक या दो डिवाइस वाले पूल पर कोई भी सेटिंग आपको दोनों लाभ नहीं दे सकती, क्योंकि विभाजित करने के लिए केवल एक ही क्यू (queue) होती है। एक नॉब शायद ही कभी डिजाइन की समस्या को ठीक करता है। यदि मासिक स्क्रब से समस्या होती है, तो इसका स्पष्ट अर्थ यह है कि पूल बहुत भरा हुआ है या डिवाइस बहुत धीमा है, और एक ट्यूनेबल केवल समस्या को स्थानांतरित करता है।

Scrub time, resilver का एक पूर्वावलोकन है

Resilver, scrub के समान ही कार्य करता है: यह allocated blocks को पढ़ता है, उनकी पुष्टि करता है, और गायब blocks को replacement device पर लिखता है। इसलिए, scrub में लगने वाला समय इस बात का सबसे सटीक अनुमान है कि rebuild में कितना समय लगेगा, और उस दौरान pool कितने समय तक कम redundancy के साथ चलेगा।

ZFS, scrub की तुलना में resilver के कार्य को अधिक प्राथमिकता देता है, इसलिए एक rebuild आमतौर पर उसी pool के scrub की तुलना में जल्दी पूरा हो जाता है। अपने scrub के समय को एक सुरक्षित ऊपरी सीमा (conservative upper bound) मानें। यदि scrub में नौ घंटे लगते हैं, तो rebuild के लिए भी उसी अवधि की योजना बनाएं, और यह समझें कि उस अवधि के दौरान यदि दूसरा device विफल होता है, तो pool का डेटा नष्ट हो जाएगा। यही एक विस्तृत raidz group के बजाय mirrored pairs का उपयोग करने का व्यावहारिक तर्क है, क्योंकि raidz, जो कि RAID 5 के स्थान पर ZFS द्वारा उपयोग किया जाने वाला parity layout है, rebuild के लिए हर जीवित device को पढ़ता है।

Single-device pool में कोई resilver नहीं होता है। यदि device विफल होता है, तो pool भी नष्ट हो जाता है। ऐसी स्थिति में आपका recovery time, restore time ही होता है, इसलिए restore की प्रक्रिया को मापें। जिस restore को आपने कभी चलाया नहीं है, वह कोई recovery plan नहीं है।

जब आप डिस्क किराए पर लेते हैं तो क्या बदलता है

VPS पर block device वर्चुअल होता है। हाइपरवाइजर एक वॉल्यूम प्रस्तुत करता है, और इसके नीचे स्थानीय NVMe, या अपनी पैरिटी वाला एक रेप्लिकेटेड नेटवर्क वॉल्यूम हो सकता है। scrubs के लिए इसके दो परिणाम होते हैं।

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

दूसरा, आप आमतौर पर वर्चुअल डिस्क के नीचे मौजूद डिवाइस के लिए SMART (self-monitoring, analysis and reporting technology) डेटा नहीं पढ़ सकते हैं, इसलिए वे शुरुआती चेतावनियाँ जिन पर VPS पर डिस्क हेल्थ मॉनिटरिंग निर्भर करती है, वे शायद उपलब्ध ही न हों। आपके scrubs से मिलने वाला CKSUM काउंटर आपका मुख्य सिग्नल बन जाता है।

यदि आप चाहते हैं कि ZFS केवल रिपोर्ट करने के बजाय मरम्मत भी करे, तो पूल को एक ही इंस्टेंस के भीतर एक से अधिक डिवाइस की आवश्यकता होती है, और यह एक ट्यूनिंग निर्णय के बजाय एक योजना निर्णय है। सामान्य VPS के बजाय स्टोरेज VPS चुनने से आपको क्षमता तो मिल जाती है, हालाँकि यह आपको दो स्वतंत्र डिवाइस देगा या नहीं, यह प्लान पर निर्भर करता है। lsblk चलाएँ और मिरर बनाने से पहले पुष्टि कर लें कि कहीं वे एक ही वॉल्यूम के दो हिस्से तो नहीं हैं। हम Linux और FreeBSD सर्वर किराए पर देते हैं, न कि कोई मैनेज्ड ZFS एप्लायंस, इसलिए scrub शेड्यूल और बैकअप चलाना आपकी जिम्मेदारी है। यही समझौता है: पूल का पूर्ण नियंत्रण, और इसके रखरखाव का पूर्ण स्वामित्व।

FAQ

VPS पर ZFS pool को कितनी बार scrub करना चाहिए?

अधिकांश छोटे pools के लिए मासिक scrub पर्याप्त है, और यह उन कार्यों के अनुरूप है जो packages पहले से करते हैं: Debian और Ubuntu पर दूसरे रविवार का cron job, और FreeBSD के periodic system में 35 दिनों की डिफ़ॉल्ट सीमा। साप्ताहिक scrub केवल तभी उचित है जब आपने scrub का समय मापा हो और देखा हो कि यह खाली पड़े सर्वर पर जल्दी पूरा हो जाता है। एक या दो devices वाले व्यस्त pool पर, साप्ताहिक scrub हर हफ्ते वास्तविक application I/O का उपयोग करता है और बदले में केवल कुछ हफ्तों की पूर्व चेतावनी देता है।

क्या सिंगल-डिस्क ZFS pool पर scrub करना व्यर्थ है?

नहीं, जब तक आप यह स्पष्ट रूप से जानते हैं कि इससे आपको क्या मिलता है। बिना redundancy के, scrub corruption का पता लगाता है लेकिन उसे ठीक नहीं कर सकता, सिवाय metadata के, जिसकी एक अतिरिक्त प्रति ZFS डिफ़ॉल्ट रूप से रखता है। आपको zpool status -v में क्षतिग्रस्त फाइलों की एक सूची मिलती है, जो इतनी जल्दी मिल जाती है कि आप उन्हें कहीं और मौजूद अच्छी प्रति से restore कर सकते हैं। सही प्रतिक्रिया बेहतर backups लेना है, क्योंकि scrub आपको ठीक-ठीक बता देता है कि कौन सी फाइल restore करनी है।

क्या मैं ZFS scrub को रोककर बाद में पूरा कर सकता हूँ?

हाँ। zpool scrub -p tank इसे रोक देता है, और pause की स्थिति और प्रगति को समय-समय पर डिस्क पर लिखा जाता है, इसलिए export या reboot के बाद भी scrub रुका रहता है। अंतिम checkpoint से फिर से शुरू करने के लिए zpool scrub tank चलाएँ। इसके लिए zpool scrub -s tank का उपयोग न करें: -s scrub को पूरी तरह बंद कर देता है, और अगला scrub फिर से शुरुआत से शुरू होता है।

मेरा ZFS scrub इतना धीमा क्यों है, और क्या मैं इसे तेज़ कर सकता हूँ?

Scrub का समय डिस्क की क्षमता पर नहीं, बल्कि आवंटित डेटा और fragmentation पर निर्भर करता है। 90% से अधिक भरा हुआ pool धीमा होता है क्योंकि 4% से कम खाली जगह होने पर metaslabs allocator को first-fit से best-fit पर ले जाते हैं, और इसके बाद होने वाला fragmentation scrub को कई छोटे reads में बदल देता है। जगह खाली करना आमतौर पर किसी भी tunable सेटिंग से अधिक मदद करता है। आप scrub को queue का बड़ा हिस्सा देने के लिए zfs_scrub_min_time_ms या zfs_vdev_scrub_max_active को बढ़ा सकते हैं, लेकिन एक या दो device वाले pool पर वह हिस्सा सीधे आपके application के प्रदर्शन से कम हो जाएगा।