چھوٹے VPS pool کے لیے ZFS scrub کتنی بار چلائیں؟

ZFS scrub دراصل کیا کرتا ہے

ZFS pool میں موجود ہر allocated block پڑھتا ہے، اس کا checksum دوبارہ شمار کرتا ہے، اور نتیجے کا موازنہ parent block pointer میں محفوظ checksum سے کرتا ہے۔ جہاں دونوں مختلف ہوں، وہاں ZFS pool میں موجود redundancy سے block کی مرمت کرتا ہے۔ ZFS کا کوئی اور عمل یہ کام نہیں کرتا۔ عام reads صرف ان blocks کی تصدیق کرتی ہیں جنہیں آپ استعمال کرتے ہیں، اس لیے جس file کو آپ نے دو سال سے نہیں کھولا، وہ اس وقت تک غیرمصدقہ رہتی ہے جب تک scrub اسے پڑھ نہ لے۔

scrub fsck نہیں ہے، جو offline repair pass دوسرے filesystems کو درکار ہوتا ہے۔ اس میں structural repair کا مرحلہ نہیں ہوتا، کیونکہ ZFS on-disk format کو کبھی خراب حالت میں نہیں چھوڑتا: ہر write نئی جگہ پر کی جاتی ہے اور 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 value 2 ہے، اس لیے ہر vdev پر زیادہ سے زیادہ دو scrub reads زیرِ عمل ہوتی ہیں۔ vdev سے مراد virtual device ہے، یعنی disks کا وہ group جسے ZFS ایک unit سمجھتا ہے۔ zfs_scrub_min_time_ms کی default value 750 ہے۔ یہ وہ کم از کم وقت ہے جو sync thread، transaction group flushes کے درمیان، scrub کے کام پر صرف کرتا ہے۔ Transaction group وہ periodic commits ہیں جن میں ZFS writes کو batch کرتا ہے۔ idle machine پر scrub پورا disk استعمال کرتا ہے۔ load کی صورت میں یہ پس منظر میں چلا جاتا ہے۔ ایک یا دو devices والے pool میں اس کے لیے پس منظر میں جانے کی گنجائش کم ہوتی ہے، اسی لیے یہاں scheduling کی اہمیت ساٹھ drives والے بڑے chassis کے مقابلے میں زیادہ ہوتی ہے۔

ایسے pool کو scrub کیوں کریں جو خود repair نہیں کر سکتا؟

یہ وہ جملہ ہے جو چھوٹے pool کے بارے میں باقی تمام فیصلے طے کرتا ہے۔ Redundancy نہ ہونے کی صورت میں scrub corruption کا پتا چلاتا ہے، مگر اسے درست نہیں کر سکتا۔ VPS میں موجود ایک virtual disk ایسا pool ہوتا ہے جس میں نہ mirror ہوتا ہے اور نہ parity۔ ZFS خراب block کو پڑھتا ہے، checksum ناکام ہونے کی تصدیق کرتا ہے، اسے CKSUM column میں شمار کرتا ہے، file کا نام بتاتا ہے، اور وہیں رک جاتا ہے، کیونکہ rebuild کرنے کے لیے دوسری copy موجود نہیں ہوتی۔

دو جزوی استثناؤں سے آگاہ رہنا مفید ہے۔ ZFS بطور default metadata کی ایک اضافی copy محفوظ کرتا ہے (redundant_metadata=all)۔ یہ copy device کے مختلف حصے میں لکھی جاتی ہے، اس لیے one-device pool پر بھی scrub خراب directory entry یا block pointer کو repair کر سکتا ہے۔ اسی طرح copies=2 والا dataset اپنے data blocks کی دو copies رکھتا ہے، جس کے لیے دگنی جگہ درکار ہوتی ہے۔ Device کے unavailable ہونے کی صورت میں ان میں سے کوئی بھی محفوظ نہیں رہتا۔ copies property کی documentation بالکل اسی بارے میں خبردار کرتی ہے: striped pool نہ بنائیں، copies=2 set نہ کریں، اور یہ نہ سمجھیں کہ آپ کے پاس redundancy ہے۔

اس لیے single-device pool پر scrub آپ کو ایک چیز دیتا ہے: corruption کی بروقت اور درست اطلاع۔ یہ خاموش corruption کو zpool status -v میں ایک file name میں بدل دیتا ہے، جبکہ آپ کے backup میں اس file کا درست ورژن اب بھی موجود ہوتا ہے۔ یہ backups کے حق میں دلیل ہے، scrubbing کے خلاف نہیں۔ اگر آپ نے ابھی تک point-in-time image اور واقعی off-box copy کا فرق واضح نہیں کیا، تو VPS snapshot backup کیوں نہیں ہوتا سے شروع کریں، کیونکہ scrub کا نتیجہ اسی وقت مفید ہوتا ہے جب کسی دوسری جگہ سالم copy موجود ہو۔

ایسا scrub جس میں کچھ بھی نہ ملے، وہ بھی ایک نتیجہ ہے۔ اس سے معلوم ہوتا ہے کہ جس data پر آپ بھروسا کرنے والے ہیں وہ سالم ہے۔ Restore یا migration سے پہلے آپ یہی جاننا چاہتے ہیں۔

ایک چھوٹے VPS pool کو کتنی بار scrub کرنا چاہیے؟

ماہانہ شیڈول درست ابتدائی انتخاب ہے، اور packages بھی اسی کو فرض کرتے ہیں۔ Debian اور Ubuntu ایسا cron job فراہم کرتے ہیں جو ہر ماہ کے دوسرے اتوار کو صحت مند pools کو scrub کرتا ہے۔ FreeBSD کا periodic system دنوں کی ایک threshold کے مطابق کام کرتا ہے، اور daily_scrub_zfs_default_threshold کی default قدر 35 ہے، جسے manual پانچ ہفتے بیان کرتا ہے۔

مصروف چھوٹے pool پر ہفتہ وار scrubbing سے عموماً فائدے کے مقابلے میں لاگت زیادہ ہوتی ہے۔ ایک یا دو devices کے ساتھ scrub اسی queue کے لیے آپ کی application سے مقابلہ کرتا ہے، اور اسے سنبھالنے کے لیے کوئی اضافی device موجود نہیں ہوتا۔ VPS پر I/O allowance محدود ہوتی ہے، اس لیے scrub کے دوران ہونے والی reads وہ reads ہیں جو آپ کا database نہیں کر پاتا۔ اس لاگت کے مقابلے میں ہفتہ وار scrubbing زیادہ سے زیادہ کسی ایسی خرابی کے بارے میں تین ہفتے پہلے اطلاع دیتی ہے جس کی آپ ویسے بھی مرمت نہیں کر سکتے۔ یہ تبادلہ صرف اسی وقت مناسب ہے جب scrub کم لاگت والا ہو۔

اس کا وقت ناپیں، پھر فیصلہ کریں۔ ایک scrub دستی طور پر چلائیں اور دیکھیں کہ اسے مکمل ہونے میں کتنا وقت لگتا ہے۔

1. پرسکون شام میں sudo zpool scrub tank چلائیں اور zpool status سے کل وقت نوٹ کریں۔
2. اگر یہ ایک گھنٹے سے کافی کم وقت میں مکمل ہو جائے اور box رات بھر idle رہے، تو ہفتہ وار شیڈول قابلِ عمل ہے۔
3. اگر pool کے network traffic فراہم کرنے کے دوران یہ کئی گھنٹے چلے، تو ماہانہ شیڈول برقرار رکھیں اور packaged job کو یہ کام کرنے دیں۔
4. جب بھی pool نمایاں طور پر بڑھے، وقت دوبارہ ناپیں، کیونکہ scrub کا دورانیہ disk capacity کے بجائے allocated data کے مطابق بڑھتا ہے۔

آپ جو بھی انتخاب کریں، اسے server کے دیگر recurring کاموں کے ساتھ لکھ کر رکھیں۔ 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 اسکرب کو عارضی طور پر روکتا ہے۔ عارضی توقف کی حالت اور پیش رفت وقفے وقفے سے disk پر sync کی جاتی ہے، اس لیے export یا reboot کے بعد بھی paused scrub برقرار رہتا ہے: pool دوبارہ دستیاب ہونے پر scrub اسی طرح paused رہتا ہے اور آپ کے اقدام کا انتظار کرتا ہے۔ zpool scrub دوبارہ چلانے سے scrub، disk پر لکھے گئے آخری checkpoint سے جاری ہوتا ہے۔ اس کے برعکس -s scrub کو بند کر دیتا ہے، اور اگلا scrub شروع سے شروع ہوتا ہے۔ جب آپ کو ایک گھنٹے کے لیے disk دوبارہ درکار ہو تو -p استعمال کریں۔ جب آپ scrub کو مکمل طور پر ختم کرنا چاہیں تو -s استعمال کریں۔

دو مزید flags جاننا مفید ہے۔ -w واپس آنے سے پہلے scrub کے مکمل ہونے کا انتظار کرتا ہے۔ اسے script میں استعمال کریں تاکہ اگلا مرحلہ وقت سے پہلے شروع نہ ہو۔ -e صرف ان files کو scrub کرتا ہے جن میں zpool status -v کے مطابق معلوم data errors موجود ہوں۔ یہ اس بات کی فوری تصدیق کا طریقہ ہے کہ backup سے restore کی گئی file اب درست ہے۔

ZFS ہر pool میں ایک وقت میں صرف ایک scrub یا resilver چلاتا ہے۔ resilver وہ rebuild ہے جو device تبدیل کرنے کے بعد ہوتا ہے، کیونکہ دونوں کارروائیوں میں I/O کی بہت زیادہ ضرورت ہوتی ہے۔ اگر کوئی device resilver ہو رہا ہو تو آپ کا scrub اپنی باری کا انتظار کرے گا۔

scrub کے دوران zpool status کیسے پڑھیں

sudo zpool status tank چلائیں اور اپنے اعداد پڑھیں؛ انہیں کسی اور کے اعداد سے ملانے کی کوشش نہ کریں۔ scrub کے دوران scan: لائن میں scanned figure، issued figure، total، repaired figure، مکمل ہونے کا percentage، اور باقی وقت کا تخمینہ شامل ہوتا ہے۔

Scanned metadata phase کو ظاہر کرتا ہے: ZFS block tree کو دیکھتا ہے اور وہ addresses جمع کرتا ہے جنہیں اسے پڑھنا ہوتا ہے۔ Issued data phase کو ظاہر کرتا ہے: وہ reads جو حقیقتاً device کو بھیجی گئی ہوں اور disk order کے مطابق ترتیب دی گئی ہوں۔ sorted scrub کی وجہ سے یہ دو counters ہوتے ہیں، اور حقیقی progress کو issued counter track کرتا ہے۔ شروع میں scanned، issued سے بہت آگے ہوتا ہے، اس لیے time estimate زیادہ قابلِ اعتماد نہیں ہوتا۔ پہلے ten percent مکمل ہونے کے بعد اس کا جائزہ لیں۔

Repaired ان bytes کو شمار کرتا ہے جو اچھی copy سے دوبارہ لکھے گئے ہوں۔ ایسے pool میں جس میں redundancy نہ ہو، scrub کو کچھ بھی ملے یہ value zero ہی رہتی ہے۔ یہ اسی سابقہ نکتے کو ایک قابلِ نگرانی number کی صورت میں ظاہر کرتا ہے۔

اس کے بعد ہر device کے per-device columns پڑھیں۔ READ اور WRITE ان I/O errors کو شمار کرتے ہیں جن کی device نے خود اطلاع دی ہو۔ CKSUM ان blocks کو شمار کرتا ہے جو checksum verification میں ناکام رہے، اور CKSUM وہ column ہے جسے scrub بھرنے کے لیے چلایا جاتا ہے۔ کسی بظاہر صحت مند device پر non-zero CKSUM حقیقی مسئلہ ہے: data واپس آیا، مگر غلط حالت میں آیا۔

آخری line فیصلہ بتاتی ہے۔ errors: No known data errors کامیابی کی حالت ہے۔ اس کے علاوہ ہر حالت میں sudo zpool status -v tank چلائیں۔ یہ آخری مکمل scrub کے بعد سے data errors کی مکمل فہرست دکھاتا ہے، جس میں متاثرہ filenames بھی شامل ہوتے ہیں۔ ان files کو backup سے restore کریں، counters reset کرنے کے لیے sudo zpool clear tank چلائیں، پھر دوبارہ scrub کریں۔ ہر مکمل scrub یہ فہرست نئے سرے سے بناتا ہے، اس لیے full clean scrub کے بعد غائب filename واقعی ختم ہو چکا ہوتا ہے۔

آپ کے سرور پر کون سا periodic scrub job موجود ہے؟

یہ فرض نہ کریں کہ ایسا کوئی job موجود ہے، اور یہ بھی فرض نہ کریں کہ صرف ایک ہی job ہے۔ طریقۂ کار platform اور package کے لحاظ سے مختلف ہوتا ہے۔ pool format ہر جگہ یکساں ہے، اس لیے یہ بھولنا آسان ہے کہ اس کے اردگرد موجود tooling یکساں نہیں ہے، اور FreeBSD پر ZFS کے Linux کے مقابلے میں جاری ہونے کا طریقہ یہاں اہم فرق ہے۔

FreeBSD پر یہ job periodic system میں موجود ہوتا ہے۔ /etc/periodic.conf میں یہ values set کریں:

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 ہوتا ہے۔ daily_scrub_zfs_default_threshold ان دنوں کی تعداد ہے جو pool-specific threshold set نہ ہونے کی صورت میں scrubs کے درمیان گزرنے چاہئیں، اور manual میں default value 35 دی گئی ہے۔ daily job ہر روز چلتا ہے؛ یہ صرف threshold گزرنے کے بعد scrub شروع کرتا ہے۔

Linux پر یہ آپ کی distribution کے ZFS package پر منحصر ہے، اور بعض systems میں دونوں mechanisms بیک وقت موجود ہوتے ہیں۔ ہر 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 کرتا ہے۔ کچھ شامل کرنے سے پہلے دیکھیں کہ آپ کے system میں کیا موجود ہے:

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

zpool history درست جواب ہے، کیونکہ یہ ان scrubs کا record رکھتا ہے جو pool نے حقیقتاً شروع کیے، تاریخوں کے ساتھ۔ مہینے میں دو scrubs ہونے کا مطلب ہے کہ دونوں mechanisms فعال ہیں، اور ان میں سے ایک کو ہٹا دینا چاہیے۔ کسی timer کو enable کرنے کے لیے:

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

خالی جگہ کسی بھی tunable سے زیادہ اہم ہے

چھوٹے pool پر scrub کا دورانیہ اس بات سے طے ہوتا ہے کہ کتنا data allocated ہے اور وہ کتنا بکھرا ہوا ہے۔ pool کو بھرنے سے دونوں مسائل بڑھ جاتے ہیں۔

OpenZFS کی ہدایت ہے کہ pool میں free space 10% سے زیادہ رکھی جائے۔ اس سے کم ہونے پر metaslabs، یعنی وہ chunks جن میں allocator کام کرتا ہے، 4% free threshold سے نیچے جانے لگتے ہیں، اور allocator first-fit سے best-fit پر منتقل ہو جاتا ہے۔ best-fit کے لیے CPU زیادہ درکار ہوتا ہے۔ Write latency بڑھتی ہے، fragmentation پیدا ہوتی ہے، اور اگلا scrub مزید سست ہو جاتا ہے، کیونکہ اب اتنا ہی data زیادہ تعداد میں اور چھوٹے reads کی صورت میں آتا ہے۔

اس لیے پہلا حل کوئی tunable نہیں بلکہ غیر ضروری چیزیں delete کرنا ہے۔ ZFS سسٹم پر عموماً پرانے snapshots اس کی وجہ ہوتے ہیں۔ اس کے بعد وہ Docker images اور layers آتی ہیں جنہیں کسی نے prune نہیں کیا اور پھر وہ kernel packages رہ جاتے ہیں جو upgrades کے بعد باقی رہ گئے ہیں۔ کسی اور تبدیلی سے پہلے 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 کے ذریعے فراہم کرتا ہے، اس لیے sysctl -a | grep scrub سے اپنی values تلاش کریں۔ انہیں بڑھانے سے scrub جلد مکمل ہو جاتا ہے، لیکن آپ کی application سست ہو جاتی ہے۔ انہیں کم کرنے سے اس کے برعکس اثر ہوتا ہے۔ ایک یا دو devices والے pool میں کوئی setting دونوں فائدے نہیں دے سکتی، کیونکہ تقسیم کرنے کے لیے صرف ایک queue ہوتی ہے۔ کوئی knob شاذ و نادر ہی design کی خامی درست کرتا ہے۔ اگر ماہانہ scrub کارکردگی متاثر کرتا ہے تو حقیقت یہ ہے کہ pool بہت زیادہ بھرا ہوا ہے یا device بہت سست ہے، اور tunable صرف مسئلے کو دوسری جگہ منتقل کرتا ہے۔

Scrub کا وقت resilver کا پیش نظارہ ہے

resilver میں scrub جیسا ہی عمل ہوتا ہے: یہ allocated blocks پڑھتا ہے، ان کی تصدیق کرتا ہے، اور جو blocks موجود نہ ہوں انہیں replacement device پر لکھتا ہے۔ اس لیے scrub میں لگنے والا وقت rebuild کی مدت کا سب سے قابلِ اعتماد عملی اندازہ ہے۔ اسی سے یہ بھی معلوم ہوتا ہے کہ rebuild کے دوران pool کتنی دیر reduced redundancy کے ساتھ چلے گا۔

ZFS، scrub کے مقابلے میں resilver کے کام کو زیادہ ترجیح کے ساتھ schedule کرتا ہے، اس لیے عموماً rebuild اسی pool کے scrub کے مقابلے میں جلد مکمل ہو جاتا ہے۔ اپنے scrub کے وقت کو محتاط زیادہ سے زیادہ حد سمجھیں۔ اگر scrub میں نو گھنٹے لگتے ہیں تو تقریباً اسی مدت کا rebuild window مقرر کریں۔ یہ بھی سمجھیں کہ اس window کے دوران دوسرے device کی خرابی pool ختم کر سکتی ہے۔ یہی عملی وجہ ہے کہ ایک وسیع raidz group کے بجائے mirrored pairs استعمال کیے جائیں، کیونکہ raidz، یعنی وہ parity layout جسے ZFS، RAID 5 کے متبادل کے طور پر استعمال کرتا ہے، rebuild کے لیے ہر surviving device کو پڑھتا ہے۔

single-device pool میں resilver بالکل نہیں ہوتا۔ device خراب ہوتا ہے تو pool بھی اس کے ساتھ ختم ہو جاتا ہے۔ آپ کا recovery time، restore time کے برابر ہے، اس لیے restore کی مدت ناپیں۔ جس restore کو آپ نے کبھی چلایا ہی نہ ہو، وہ recovery plan نہیں ہے۔

ڈسک کرائے پر لینے سے کیا بدلتا ہے

VPS میں block device virtual ہوتا ہے۔ hypervisor ایک volume پیش کرتا ہے، اور اس کے پیچھے local NVMe یا اپنی parity کے ساتھ replicated network volume ہو سکتا ہے۔ Scrub کے لیے اس کے دو نتائج نکلتے ہیں۔

اول، platform کی redundancy ZFS کو نظر نہیں آتی، اور ZFS اسے استعمال نہیں کر سکتا۔ اگر platform آپ کے نیچے media error درست کر دے تو ZFS کو مسئلہ کبھی نظر نہیں آتا۔ اگر platform کوئی غلط block اوپر فراہم کرے تو ZFS اسے پکڑ لیتا ہے، لیکن درست نہیں کر سکتا، کیونکہ درست copy اس حد کے دوسری طرف موجود ہوتی ہے۔

دوم، عموماً virtual disk کے نیچے موجود device کے لیے SMART (self-monitoring, analysis and reporting technology) data پڑھنا ممکن نہیں ہوتا۔ اس لیے ابتدائی انتباہات، جن پر VPS پر disk health monitoring انحصار کرتی ہے، بالکل دستیاب نہ ہوں۔ آپ کے scrubs کا CKSUM counter آپ کے اختیار میں موجود بنیادی signal بن جاتا ہے۔

اگر آپ چاہتے ہیں کہ ZFS صرف رپورٹ کرنے کے بجائے repair بھی کرے تو اسی instance کے اندر pool میں ایک سے زیادہ devices درکار ہیں۔ یہ tuning کا نہیں بلکہ منصوبہ بندی کا فیصلہ ہے۔ regular VPS کے بجائے storage VPS منتخب کرنے سے capacity مل جاتی ہے، لیکن دو independent devices ملیں گے یا نہیں، اس کا انحصار plan پر ہے۔ lsblk چلائیں اور تصدیق کریں، اس سے پہلے کہ بظاہر دو devices دراصل ایک ہی volume کے دو slices پر mirror بنائیں۔ ہم managed ZFS appliance نہیں بلکہ Linux اور FreeBSD servers کرائے پر دیتے ہیں، اس لیے scrub schedule اور backups چلانا آپ کی ذمہ داری ہے۔ یہی اس انتظام کا trade-off ہے: pool پر مکمل control، اور اس کی maintenance کی مکمل ذمہ داری بھی۔

FAQ

ZFS pool کو VPS پر کتنی بار scrub کرنا چاہیے؟

زیادہ تر چھوٹے pools کے لیے ماہانہ scrub کافی ہے، اور یہ ان settings سے بھی مطابقت رکھتا ہے جو packages پہلے سے استعمال کرتے ہیں: Debian اور Ubuntu میں دوسرے اتوار کو چلنے والا cron job، اور FreeBSD کے periodic system میں 35 دن کی default threshold۔ ہفتہ وار scrub صرف اس وقت مناسب ہے جب آپ نے اس کا وقت ناپ لیا ہو اور دیکھا ہو کہ یہ عام طور پر idle server پر جلد مکمل ہو جاتا ہے۔ ایک یا دو devices والے مصروف pool میں ہر ہفتے scrub چلانے سے application I/O نمایاں طور پر استعمال ہوتا ہے، جبکہ پہلے warning ملنے کا فائدہ صرف چند ہفتوں تک محدود رہتا ہے۔

کیا single-disk ZFS pool کو scrub کرنا بے فائدہ ہے؟

نہیں، بشرطیکہ آپ واضح طور پر سمجھتے ہوں کہ اس سے کیا حاصل ہوتا ہے۔ Redundancy نہ ہونے کی صورت میں scrub corruption کا پتا لگا سکتا ہے، لیکن اسے repair نہیں کر سکتا؛ البتہ metadata اس سے مستثنیٰ ہے، کیونکہ ZFS اسے default طور پر ایک اضافی copy کے ساتھ محفوظ رکھتا ہے۔ آپ کو zpool status -v میں خراب files کی نامزد فہرست ملتی ہے، اور اتنا وقت باقی ہوتا ہے کہ انہیں اس وقت restore کر لیں جب کہیں اور اچھی copy موجود ہو۔ درست طریقہ بہتر backups رکھنا ہے، کیونکہ scrub آپ کو بالکل بتا دیتا ہے کہ کون سی file restore کرنی ہے۔

کیا ZFS scrub کو pause کرکے بعد میں مکمل کیا جا سکتا ہے؟

ہاں۔ zpool scrub -p tank اسے 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 کے مطابق بڑھتا ہے۔ 90% سے زیادہ بھرا ہوا pool سست ہوتا ہے، کیونکہ 4% سے کم free space والے metaslabs allocator کو first-fit سے best-fit کی طرف لے جاتے ہیں، اور اس کے بعد پیدا ہونے والی fragmentation scrub کو بہت سی چھوٹی reads میں تبدیل کر دیتی ہے۔ عموماً space خالی کرنا کسی بھی tunable کو تبدیل کرنے سے زیادہ مؤثر ہوتا ہے۔ آپ scrub کو queue کا بڑا حصہ دینے کے لیے zfs_scrub_min_time_ms یا zfs_vdev_scrub_max_active کی value بڑھا سکتے ہیں، لیکن ایک یا دو devices والے pool میں یہ حصہ براہ راست آپ کی application سے کم ہوگا۔