लहान VPS pool साठी ZFS scrub किती वेळा करावे?

ZFS scrub प्रत्यक्षात काय करते

ZFS scrub pool मधील प्रत्येक allocated block वाचते, त्याचा checksum पुन्हा मोजते आणि तो परिणाम parent block pointer मध्ये साठवलेल्या checksum शी तुलना करते. दोन्ही जुळत नसतील, तर pool कडे उपलब्ध असलेल्या redundancy मधून ZFS तो block दुरुस्त करते. ZFS मधील इतर कोणतीही प्रक्रिया हे काम करत नाही. सामान्य read मध्ये तुम्ही प्रत्यक्षात वापरलेले blocksच पडताळले जातात. त्यामुळे दोन वर्षांत न उघडलेली file scrub ने वाचेपर्यंत पडताळली जात नाही.

Scrub म्हणजे fsck नाही. इतर filesystems ला आवश्यक असलेली ही offline repair pass आहे. Structural repair phase नसते, कारण ZFS on-disk format कधीही broken state मध्ये ठेवत नाही. प्रत्येक write नवीन location वर केली जाते आणि pool चा root pointer असलेला uberblock शेवटी update केला जातो. Scrub संपूर्ण device देखील वाचत नाही. ती केवळ allocated blocks वाचते. त्यामुळे जवळजवळ रिकाम्या pool वर scrub काही मिनिटांत पूर्ण होते, तर तोच pool 80% भरलेला असल्यास बराच जास्त वेळ लागतो.

Scrub ZFS कडे उपलब्ध असलेल्या सर्वात कमी I/O priority वर चालते. Linux वर, zfs_vdev_scrub_max_active चे default मूल्य 2 आहे. त्यामुळे प्रत्येक vdev वर जास्तीत जास्त दोन scrub reads एकाच वेळी सुरू असतात. vdev म्हणजे virtual device; ZFS ज्या disks ना एक unit मानते तो समूह. zfs_scrub_min_time_ms चे default मूल्य 750 आहे. हे transaction group flushes दरम्यान sync thread scrub work वर घालवतो तो किमान वेळ आहे. Transaction groups म्हणजे ZFS ज्या periodic commits मध्ये writes एकत्रित करते. निष्क्रिय machine वर scrub संपूर्ण disk वापरते. Load असताना ती बाजूला राहते. एक किंवा दोन devices असलेल्या pool मध्ये बाजूला राहण्यासाठी जागाच नसते. म्हणून large chassis मधील sixty drives पेक्षा अशा pool वर scheduling अधिक महत्त्वाची ठरते.

स्वतः दुरुस्ती करू न शकणाऱ्या pool चे scrub का करावे?

लहान pool बाबत पुढील सर्व निर्णय ठरवणारे हेच मूलभूत तथ्य आहे. Redundancy नसल्यास scrub corruption शोधतो, पण ती दुरुस्त करू शकत नाही. VPS मधील एकच virtual disk म्हणजे mirror आणि parity नसलेला pool होय. ZFS खराब block वाचतो, checksum पडताळणी अयशस्वी झाल्याचे नोंदवतो, ते CKSUM column मध्ये मोजतो, file चे नाव दाखवतो आणि तिथेच थांबतो, कारण पुनर्बांधणी करण्यासाठी दुसरी copy उपलब्ध नसते.

दोन अंशतः लागू होणारे अपवाद लक्षात ठेवण्यासारखे आहेत. ZFS metadata ची एक अतिरिक्त copy default ने साठवतो (redundant_metadata=all). ती device च्या वेगळ्या भागात लिहिली जाते. त्यामुळे one-device pool वरही scrub खराब directory entry किंवा block pointer दुरुस्त करू शकतो. तसेच copies=2 असलेल्या dataset मध्ये data blocks च्या दोन copies ठेवल्या जातात. यासाठी दुप्पट storage space लागते. Device उपलब्धच राहिला नाही, तर यापैकी कोणतीही पद्धत उपयोगी ठरत नाही. copies property च्या documentation मध्ये याबाबत स्पष्ट इशारा आहे: striped pool तयार करू नका, copies=2 सेट करू नका आणि तुमच्याकडे redundancy आहे असे समजू नका.

म्हणून single-device pool वर scrub एकच गोष्ट देतो: लवकर आणि अचूक सूचना. तुमच्या backup मध्ये त्या file ची चांगली आवृत्ती अजून उपलब्ध असताना तो silent corruption चे रूपांतर zpool status -v मधील filename मध्ये करतो. हा backups च्या बाजूने असलेला मुद्दा आहे; scrubbing टाळण्याचा नाही. Point-in-time image आणि प्रत्यक्ष off-box copy यांतील फरक तुम्ही अद्याप स्पष्ट केला नसेल, तर VPS snapshot हा backup का नाही यापासून सुरुवात करा. कारण scrub चा परिणाम तेव्हाच उपयोगी ठरतो, जेव्हा दुसऱ्या ठिकाणी intact copy उपलब्ध असते.

Scrub मध्ये काहीही आढळले नाही, हेसुद्धा एक परिणाम आहे. तुम्ही ज्यावर विश्वास ठेवणार आहात तो data intact असल्याचे ते सांगते. Restore किंवा migration करण्यापूर्वी तुम्हाला हेच जाणून घ्यायचे असते.

लहान VPS pool वर scrub किती वेळा करावे?

मासिक scrub हा योग्य default आहे आणि packages मध्येही हीच अपेक्षा असते. Debian आणि Ubuntu मध्ये प्रत्येक महिन्याच्या दुसऱ्या रविवारी निरोगी pool वर scrub करणारे cron job समाविष्ट असते. FreeBSD ची periodic system दिवसांच्या threshold वर कार्य करते आणि daily_scrub_zfs_default_threshold चे default मूल्य 35 आहे. Manual मध्ये याचे वर्णन पाच आठवडे असे केले आहे.

व्यस्त लहान pool वर साप्ताहिक scrub केल्याने मिळणाऱ्या फायद्यापेक्षा त्याची किंमत सहसा जास्त असते. एक किंवा दोन devices असताना scrub तुमच्या application सारख्याच queue साठी स्पर्धा करतो आणि त्याचा भार घेण्यासाठी अतिरिक्त device उपलब्ध नसते. VPS वर I/O allowance मर्यादित असते. त्यामुळे scrub ज्या reads साठी allowance वापरतो, त्या reads तुमच्या database ला मिळत नाहीत. या खर्चाच्या तुलनेत, साप्ताहिक scrub मुळे अशा fault ची सूचना जास्तीत जास्त तीन आठवडे आधी मिळते, जी तुम्ही दुरुस्त करू शकत नाही. Scrub स्वस्त असेल तेव्हाच हा trade-off योग्य ठरतो.

कालावधी मोजा आणि मग निर्णय घ्या. एक scrub manually चालवा आणि त्याला किती वेळ लागतो ते monitor करा.

1. शांत संध्याकाळी sudo zpool scrub tank चालवा आणि zpool status पासून लागलेला एकूण वेळ नोंदवा.
2. तो एका तासापेक्षा बराच कमी वेळात पूर्ण झाला आणि box रात्रभर idle असेल, तर साप्ताहिक scrub परवडणारा आहे.
3. pool network traffic serve करत असताना scrub ला अनेक तास लागले, तर मासिक schedule ठेवा आणि packaged job कडे ही जबाबदारी सोपवा.
4. pool मध्ये लक्षणीय वाढ झाल्यावर पुन्हा कालावधी मोजा, कारण scrub चा कालावधी disk capacity नुसार नव्हे, तर allocated data नुसार बदलतो.

तुम्ही कोणताही पर्याय निवडला तरी तो इतर नियमित server कामांच्या शेजारी नोंदवा. Scrub चा समावेश package upgrades आणि log rotation यांच्यासारख्याच यादीत असावा: मासिक Linux server maintenance checklist पहा.

स्क्रब सुरू करणे, विराम देणे आणि थांबवणे

sudo zpool scrub tank
sudo zpool status tank

विराम देणे आणि थांबवणे या वेगवेगळ्या क्रिया आहेत. चुकीची क्रिया निवडल्यास आधीचे काम पुन्हा करावे लागू शकते आणि अनेक तास वाया जाऊ शकतात.

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

-p विराम देते. विरामाची स्थिती आणि प्रगती ठरावीक अंतराने डिस्कवर समक्रमित केली जाते. त्यामुळे export किंवा reboot नंतरही विराम दिलेला scrub तसाच राहतो. pool पुन्हा उपलब्ध झाल्यावर scrub तुमची पुढील कृती होईपर्यंत विरामित राहतो. zpool scrub पुन्हा चालवल्यास डिस्कवर लिहिलेल्या शेवटच्या checkpoint पासून प्रक्रिया पुन्हा सुरू होते. त्याऐवजी -s scrub थांबवते. त्यानंतर सुरू केलेला पुढील scrub सुरुवातीपासून सुरू होतो. डिस्क एका तासासाठी उपलब्ध करून घ्यायची असल्यास -p वापरा. Scrub पूर्णपणे थांबवायचा असल्यास -s वापरा.

आणखी दोन flags माहिती असणे उपयुक्त आहे. -w परत येण्यापूर्वी scrub पूर्ण होईपर्यंत प्रतीक्षा करते. Script मध्ये हेच अपेक्षित असते, जेणेकरून पुढील पायरी लवकर सुरू होणार नाही. -e फक्त zpool status -v ने नोंदवलेल्या ज्ञात data errors असलेल्या files वर scrub चालवते. Backup मधून restore केलेली file आता स्वच्छ आहे का हे त्वरेने तपासण्याचा हा मार्ग आहे.

प्रत्येक pool साठी ZFS एकावेळी एकच scrub किंवा resilver चालवते. Resilver म्हणजे device बदलल्यानंतर होणारी rebuild प्रक्रिया. दोन्ही प्रक्रिया I/O वर मोठा भार टाकतात. एखाद्या device वर resilver सुरू असल्यास scrub आपली पाळी येईपर्यंत प्रतीक्षा करतो.

scrub सुरू असताना zpool status कसे वाचावे

`sudo zpool status tank चालवा आणि इतरांच्या आकड्यांशी तुलना करण्याऐवजी तुमचे स्वतःचे आकडे वाचा. scrub सुरू असताना scan:` ओळीत scanned आकडा, issued आकडा, एकूण आकडा, repaired आकडा, पूर्ण झालेली टक्केवारी आणि उर्वरित वेळेचा अंदाज दिसतो.

Scanned हा metadata टप्पा आहे: ZFS block tree मधून पुढे जाते आणि वाचण्यासाठी आवश्यक असलेले पत्ते गोळा करते. Issued हा data टप्पा आहे: device कडे प्रत्यक्ष पाठवलेले reads, disk order नुसार क्रमबद्ध केलेले. Sorted scrub मुळे हे दोन counters असतात आणि प्रत्यक्ष प्रगतीचा मागोवा issued घेतो. सुरुवातीला scanned हा issued पेक्षा खूप पुढे असतो आणि वेळेचा अंदाज फारसा अर्थपूर्ण नसतो. पहिली दहा टक्के प्रगती झाल्यानंतर त्याचे मूल्यमापन करा.

Repaired मध्ये चांगल्या copy मधून पुन्हा लिहिलेल्या bytes ची संख्या असते. Redundancy नसलेल्या pool मध्ये scrub ला काहीही आढळले तरी हा आकडा शून्यच राहतो. हा आधी सांगितलेला मुद्दा संख्येच्या स्वरूपात पुन्हा स्पष्ट करतो आणि तुम्ही त्याचा मागोवा घेऊ शकता.

त्यानंतर प्रत्येक device चे columns वाचा. READ आणि WRITE मध्ये device ने स्वतः नोंदवलेल्या I/O errors ची संख्या असते. CKSUM मध्ये checksum verification अयशस्वी झालेल्या blocks ची संख्या असते आणि scrub चा मुख्य उद्देश CKSUM column मध्ये ही माहिती भरणे हा असतो. निरोगी दिसणाऱ्या device वर CKSUM शून्य नसल्यास ते वास्तविक आहे: data परत आले, पण चुकीचे आले.

शेवटची ओळ निकाल सांगते. `errors: No known data errors म्हणजे pass. इतर कोणताही निकाल आल्यास sudo zpool status -v tank चालवा. हा command शेवटच्या पूर्ण scrub नंतर झालेल्या data errors ची संपूर्ण यादी दाखवतो आणि त्यात प्रभावित filenames देखील असतात. त्या files backup मधून restore करा, counters reset करण्यासाठी sudo zpool clear tank` चालवा आणि scrub पुन्हा चालवा. प्रत्येक पूर्ण scrub ही यादी नव्याने तयार करतो. त्यामुळे पूर्णपणे clean scrub झाल्यानंतर एखादे filename दिसत नसेल, तर ते खरोखरच नष्ट झालेले आहे.

तुमच्या मशीनवर कोणते नियतकालिक scrub job चालू आहे?

असे एखादे job आहेच असे गृहीत धरू नका. तसेच, फक्त एकच job आहे असेही गृहीत धरू नका. ही यंत्रणा platform आणि package नुसार बदलते. Pool format सर्वत्र समान असतो. त्यामुळे त्याभोवतीची tooling वेगळी असू शकते हे सहज विसरले जाते. येथे महत्त्वाचा फरक म्हणजे FreeBSD वर ZFS कसे release केले जाते आणि Linux वर कसे.

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 names ची space-separated यादी आहे. ती रिकामी ठेवल्यास प्रत्येक pool वर scrub चालतो. Pool-specific threshold सेट केलेला नसताना दोन scrub मधील दिवसांची संख्या daily_scrub_zfs_default_threshold मध्ये दिली जाते. Manual मध्ये default म्हणून 35 दिले आहे. Daily job दररोज चालते. Threshold पूर्ण झाल्यानंतरच ते scrub सुरू करते.

Linux वर हे तुमच्या distribution च्या ZFS package वर अवलंबून असते. काही systems मध्ये दोन्ही यंत्रणा एकाच वेळी असतात. Per-pool systemd timers, zfs-scrub-monthly@tank.timer आणि zfs-scrub-weekly@tank.timer, एकावेळी एका pool साठी enable केले जातात. Debian आणि Ubuntu मध्ये /etc/cron.d/zfsutils-linux देखील release केले जाते. ते प्रत्येक महिन्याच्या दुसऱ्या Sunday ला ONLINE असलेल्या प्रत्येक pool वर scrub चालवणारी script सुरू करते. काहीही जोडण्यापूर्वी तुमच्याकडे नेमके काय आहे ते तपासा:

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

zpool history हे अचूक उत्तर देते, कारण pool ने प्रत्यक्षात सुरू केलेल्या scrub ची dates सहित नोंद त्यात असते. महिन्यात दोन scrub होत असतील, तर दोन्ही यंत्रणा सक्रिय आहेत आणि त्यांपैकी एक बंद केली पाहिजे. Timer enable करण्यासाठी:

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

मोकळी जागा कोणत्याही tunable पेक्षा अधिक महत्त्वाची

लहान pool वरील scrub चा कालावधी किती data allocate केला आहे आणि तो किती विखुरलेला आहे यावर ठरतो. pool भरल्यामुळे या दोन्ही बाबी आणखी खराब होतात.

OpenZFS च्या मार्गदर्शनानुसार pool मध्ये 10% पेक्षा जास्त free space ठेवावी. त्याखाली allocator ज्या chunks मध्ये काम करतो त्या metaslabs 4% free threshold ओलांडू लागतात आणि allocator first-fit ऐवजी best-fit पद्धतीवर स्विच करतो. best-fit साठी CPU चा वापर लक्षणीयरीत्या अधिक होतो. Write latency वाढते, fragmentation निर्माण होते आणि पुढील scrub आणखी धीमा होतो, कारण तेवढाच data आता अधिक आणि लहान reads म्हणून वाचला जातो.

त्यामुळे पहिला उपाय tunable बदलणे नाही. अनावश्यक गोष्टी delete करणे हा पहिला उपाय आहे. ZFS box वर जुन्या snapshots हे याचे सर्वसाधारण कारण असते. त्यानंतर prune न केलेल्या Docker images आणि layers आणि upgrades नंतर मागे राहिलेली kernel packages ही कारणे असतात. इतर काहीही करण्यापूर्वी zfs list -o space चालवा, कारण त्यातून snapshots ने व्यापलेली space आणि live data ने व्यापलेली space वेगळी दिसते.

आता knobs थोडक्यात पाहू. Linux वर सध्याची values वाचण्यासाठी:

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

FreeBSD मध्ये हीच parameters sysctl द्वारे उपलब्ध असतात. त्यामुळे तुमच्या values sysctl -a | grep scrub वापरून शोधा. त्या वाढवल्यास scrub लवकर पूर्ण होतो, पण तुमचे application धीमे होते. त्या कमी केल्यास उलट परिणाम होतो. एक किंवा दोन devices असलेल्या pool वर कोणतीही setting दोन्ही फायदे देऊ शकत नाही, कारण विभागण्यासाठी एकच queue असते. एखादा knob design मधील समस्या क्वचितच सोडवतो. Monthly scrub मुळे अडथळा येत असेल, तर याचा सरळ अर्थ pool खूप भरलेला आहे किंवा device खूप धीमा आहे. Tunable केवळ समस्या दुसरीकडे ढकलतो.

Scrub वेळ हा resilver च्या कालावधीचा अंदाज आहे

resilver प्रक्रियेत scrub प्रमाणेच तपासणी केली जाते: वाटप केलेले blocks वाचले जातात, त्यांची पडताळणी केली जाते आणि replacement device वर नसलेले blocks लिहिले जातात. त्यामुळे scrub पूर्ण होण्यासाठी लागणारा वेळ हा rebuild ला लागणाऱ्या कालावधीचा आणि त्या काळात pool कमी redundancy सह चालण्याच्या कालावधीचा सर्वात विश्वासार्ह अंदाज आहे.

ZFS, scrub पेक्षा resilver काम अधिक आक्रमकपणे schedule करते. त्यामुळे समान pool चा rebuild सहसा scrub पेक्षा लवकर पूर्ण होतो. Scrub चा वेळ हा सावधगिरीचा कमाल अंदाज समजा. Scrub ला नऊ तास लागत असतील, तर rebuild साठी त्याच आसपासचा कालावधी गृहीत धरा. त्या कालावधीत दुसरे device fail झाल्यास pool नष्ट होईल, हे लक्षात ठेवा. म्हणूनच एका रुंद raidz group ऐवजी mirrored pairs वापरण्याचा व्यावहारिक आधार मिळतो. ZFS मध्ये RAID 5 ऐवजी वापरल्या जाणाऱ्या parity layout असलेल्या raidz मध्ये rebuild करण्यासाठी सर्व उपलब्ध devices वाचावे लागतात.

single-device pool मध्ये resilver होतच नाही. device fail झाले की pool देखील fail होतो. तुमचा recovery time म्हणजे restore time असतो. त्यामुळे त्याऐवजी restore चा कालावधी मोजा. तुम्ही कधीही चालवलेला नसलेला restore हा recovery plan नाही.

डिस्क भाड्याने घेतल्यावर काय बदलते

VPS मध्ये block device आभासी असते. Hypervisor एक volume उपलब्ध करून देतो. त्यामागे स्थानिक NVMe किंवा स्वतःची parity असलेले replicated network volume असू शकते. यामुळे scrub बाबत दोन परिणाम होतात.

पहिला परिणाम असा की platform ची redundancy ZFS ला दिसत नाही आणि ZFS तिचा वापर करू शकत नाही. Platform तुमच्या स्तराखालील media error दुरुस्त करत असेल, तर ZFS ला समस्या कधीच दिसणार नाही. Platform ने चुकीचा block उपलब्ध करून दिल्यास ZFS तो ओळखेल, पण दुरुस्त करू शकणार नाही. कारण योग्य प्रत त्या सीमारेषेच्या दुसऱ्या बाजूला असते.

दुसरा परिणाम असा की virtual disk च्या खालील device साठी SMART (self-monitoring, analysis and reporting technology) data सहसा वाचता येत नाही. त्यामुळे VPS वरील disk health monitoring ज्या पूर्वसूचनांवर अवलंबून असते, त्या कदाचित उपलब्धच नसतील. तुमच्या scrub मधील CKSUM counter हा तुमच्याकडे असलेला मुख्य संकेत ठरतो.

ZFS ने केवळ अहवाल न देता दुरुस्ती करावी असे असल्यास, त्याच instance मध्ये pool मध्ये एकापेक्षा अधिक device आवश्यक असतात. हा tuning चा नव्हे, तर नियोजनाचा निर्णय आहे. नियमित VPS ऐवजी storage VPS निवडल्यास capacity मिळते. मात्र त्या plan मध्ये दोन स्वतंत्र device मिळतील का, हे plan वर अवलंबून असते. दोन वेगवेगळ्या slices एका volume च्या असल्याचे नंतर लक्षात येऊ नये म्हणून mirror तयार करण्यापूर्वी lsblk चालवून पडताळा. आम्ही managed ZFS appliance नव्हे, तर Linux आणि FreeBSD servers भाड्याने देतो. त्यामुळे scrub schedule आणि backups चालवणे ही तुमची जबाबदारी आहे. हा तडजोडीचा मुद्दा आहे: pool वर पूर्ण नियंत्रण आणि त्याच्या देखभालीची पूर्ण जबाबदारी.

FAQ

VPS वरील ZFS pool किती वेळाने scrub करावा?

बहुतेक लहान pool साठी महिन्यातून एकदा योग्य आहे. आधीपासून असलेली package configuration देखील याच वेळापत्रकाशी जुळते: Debian आणि Ubuntu मध्ये दुसऱ्या रविवारचा cron job, तसेच FreeBSD च्या periodic system मध्ये 35 दिवसांची default threshold. आठवड्यातून एकदा scrub करणे तेव्हाच योग्य आहे, जेव्हा तुम्ही scrub ला लागणारा वेळ मोजला असेल आणि अन्यथा निष्क्रिय असलेल्या मशीनवर तो लवकर पूर्ण होत असल्याचे पाहिले असेल. एक किंवा दोन devices असलेल्या व्यस्त pool वर आठवड्याला scrub केल्याने दर आठवड्याला प्रत्यक्ष application I/O खर्च होतो, पण काही आठवडे आधी corruption ची सूचना मिळण्याइतकाच मर्यादित फायदा मिळतो.

एकाच disk च्या ZFS pool वर scrub करणे निरर्थक आहे का?

नाही. मात्र त्यातून नेमके काय मिळते हे स्पष्ट असले पाहिजे. Redundancy नसल्यास scrub corruption शोधतो, पण ते दुरुस्त करू शकत नाही. Metadata याला अपवाद आहे, कारण ZFS ते default ने अतिरिक्त copy म्हणून ठेवते. zpool status -v मध्ये खराब झालेल्या files ची नावांसह list मिळते. दुसरीकडे चांगली copy अजून उपलब्ध असताना files restore करण्यासाठी ही माहिती पुरेशी लवकर मिळते. योग्य उपाय म्हणजे चांगल्या backups ठेवणे, कारण कोणती file restore करायची हे scrub नेमके सांगतो.

ZFS scrub थांबवून नंतर पूर्ण करता येतो का?

होय. zpool scrub -p tank scrub pause करते. Pause state आणि progress ठराविक अंतराने disk वर लिहिले जातात. त्यामुळे export किंवा reboot नंतरही scrub paused राहतो. शेवटच्या checkpoint पासून पुन्हा सुरू करण्यासाठी zpool scrub tank चालवा. यासाठी zpool scrub -s tank वापरू नका: -s scrub थांबवते आणि पुढील scrub पुन्हा सुरुवातीपासून सुरू होतो.

माझा ZFS scrub इतका धीम्या गतीने का चालतो आणि तो वेगवान कसा करता येईल?

Scrub ला लागणारा वेळ disk capacity वर नव्हे, तर allocated data आणि fragmentation वर अवलंबून असतो. Pool 90% पेक्षा जास्त भरलेला असल्यास तो धीमा होतो. याचे कारण 4% पेक्षा कमी free space असलेले metaslabs allocator ला first-fit ऐवजी best-fit पद्धत वापरण्यास भाग पाडतात. त्यानंतर निर्माण होणाऱ्या fragmentation मुळे scrub ला अनेक लहान reads करावे लागतात. कोणत्याही tunable पेक्षा space मोकळी केल्याने सहसा अधिक फायदा होतो. Scrub साठी queue मधील मोठा वाटा देण्यासाठी zfs_scrub_min_time_ms किंवा zfs_vdev_scrub_max_active चे मूल्य वाढवू शकता. मात्र एक किंवा दोन devices असलेल्या pool मध्ये हा वाटा थेट तुमच्या application च्या I/O मधून कमी होतो.