ছোট VPS pool-এ ZFS scrub কত ঘন ঘন চালাবেন

ZFS scrub আসলে কী করে

একটি ZFS scrub pool-এর প্রতিটি allocated block পড়ে, তার checksum পুনরায় গণনা করে এবং ফলাফলটি parent block pointer-এ সংরক্ষিত checksum-এর সঙ্গে তুলনা করে। দুটি checksum না মিললে ZFS pool-এ থাকা redundancy ব্যবহার করে block-টি মেরামত করে। ZFS-এর অন্য কোনো কাজ এই প্রক্রিয়াটি করে না। সাধারণ read কেবল আপনি যে block-গুলো ব্যবহার করেন সেগুলোই যাচাই করে। তাই দুই বছর ধরে খোলা হয়নি এমন কোনো file scrub সেটি পড়া পর্যন্ত যাচাইহীন থাকে।

একটি scrub হলো না fsck, যা অন্য filesystem-গুলোর প্রয়োজন হয়। আলাদা structural repair phase নেই, কারণ ZFS কখনো on-disk format-কে ভাঙা অবস্থায় রাখে না। প্রতিটি write নতুন location-এ যায় এবং pool-এর root pointer uberblock সর্বশেষে update হয়। একটি scrub পুরো device-ও পড়ে না। এটি কেবল allocated block পড়ে। এ কারণেই প্রায় খালি pool scrub হতে কয়েক মিনিট লাগে, কিন্তু একই pool 80% পূর্ণ হলে অনেক বেশি সময় লাগে।

scrub ZFS-এর সর্বনিম্ন I/O priority-তে চলে। Linux-এ zfs_vdev_scrub_max_active-এর default মান 2। তাই প্রতি vdev-এ সর্বোচ্চ দুইটি scrub read একসঙ্গে চলতে পারে। vdev হলো virtual device, অর্থাৎ ZFS যে disk group-কে একটি unit হিসেবে বিবেচনা করে। zfs_scrub_min_time_ms-এর default মান 750। এটি হলো transaction group flush-এর মাঝখানে sync thread scrub কাজের জন্য যে সর্বনিম্ন সময় ব্যয় করে; transaction group হলো ZFS-এর batch করা periodic commit, যেখানে write জমা হয়। অব্যবহৃত machine-এ scrub পুরো disk-এর I/O ব্যবহার করে। load থাকলে এটি অন্য কাজকে অগ্রাধিকার দেয়। একটি বা দুটি device-যুক্ত pool-এ সরে দাঁড়ানোর মতো অতিরিক্ত জায়গা থাকে না। তাই 60টি drive-যুক্ত বড় chassis-এর তুলনায় এখানে scheduling বেশি গুরুত্বপূর্ণ।

যে pool নিজে থেকে repair করতে পারে না, সেটি scrub করবেন কেন?

ছোট pool-এর ক্ষেত্রে পরবর্তী সব সিদ্ধান্ত এই বিষয়টির ওপর নির্ভর করে। কোনো redundancy না থাকলে scrub corruption শনাক্ত করতে পারে, কিন্তু তা ঠিক করতে পারে না। VPS-এর একটি single virtual disk হলো এমন একটি pool, যাতে mirror বা parity কোনোটিই নেই। ZFS খারাপ block পড়বে, checksum ব্যর্থ হবে, সেটিকে CKSUM column-এ গণনা করবে, সংশ্লিষ্ট file-এর নাম দেখাবে, তারপর থেমে যাবে। কারণ পুনর্গঠনের জন্য দ্বিতীয় কোনো copy নেই।

দুটি আংশিক ব্যতিক্রম জানা দরকার। ZFS ডিফল্টভাবে metadata-এর অতিরিক্ত একটি copy সংরক্ষণ করে (redundant_metadata=all), যা device-এর ভিন্ন একটি অংশে লেখা হয়। তাই এক-device pool-এও scrub ক্ষতিগ্রস্ত directory entry বা block pointer repair করতে পারে। এছাড়া copies=2 সেট করা dataset তার data block-এর দুটি copy রাখে, যার জন্য দ্বিগুণ storage space লাগে। তবে device সম্পূর্ণভাবে unavailable হয়ে গেলে এর কোনোটিই কাজে আসে না। copies property-এর documentation-এ ঠিক এই বিষয়ে সতর্ক করা হয়েছে: একটি striped pool তৈরি করে copies=2 সেট করবেন না এবং ধরে নেবেন না যে আপনার redundancy আছে।

সুতরাং single-device pool-এ scrub আপনাকে একটি বিষয় দেয়: আগেভাগে এবং নির্ভুলভাবে notification। আপনার backup-এ file-এর একটি ভালো সংস্করণ থাকা অবস্থায় scrub নীরব corruption-কে zpool status -v-এ একটি filename হিসেবে প্রকাশ করে। এটি backup রাখার পক্ষে যুক্তি, scrub না করার পক্ষে নয়। point-in-time image এবং প্রকৃত off-box copy-এর পার্থক্য এখনো পরিষ্কার না হলে কেন VPS snapshot backup নয় দিয়ে শুরু করুন। কারণ scrub-এর ফলাফল তখনই কাজে আসে, যখন অন্য কোথাও file-এর একটি অক্ষত copy থাকে।

Scrub কোনো সমস্যা না পেলেও সেটি একটি ফলাফল। এটি জানায় যে আপনি যে data-এর ওপর ভরসা করতে যাচ্ছেন তা অক্ষত আছে। Restore বা migration-এর আগে এটিই আপনার জানা দরকার।

একটি ছোট VPS pool কত ঘন ঘন scrub করা উচিত?

মাসে একবারই উপযুক্ত default, এবং packages-ও এটিই ধরে নেয়। Debian ও Ubuntu এমন একটি cron job সরবরাহ করে, যা প্রতি মাসের দ্বিতীয় রবিবার healthy pool scrub করে। FreeBSD-এর periodic system দিনের একটি threshold ব্যবহার করে, এবং daily_scrub_zfs_default_threshold-এর default মান 35; manual-এ এটিকে পাঁচ সপ্তাহ হিসেবে বর্ণনা করা হয়েছে।

ব্যস্ত ছোট pool-এ সাপ্তাহিক scrub সাধারণত যতটা সুবিধা দেয়, তার চেয়ে বেশি খরচ সৃষ্টি করে। এক বা দুটি device থাকলে scrub আপনার application-এর সঙ্গে একই queue ব্যবহারের জন্য প্রতিযোগিতা করে, এবং scrub-এর কাজ সামলানোর জন্য অতিরিক্ত কোনো device থাকে না। VPS-এ I/O allowance সীমিত, তাই scrub যে reads ব্যবহার করে, আপনার database সেই reads পায় না। এর বিপরীতে, সাপ্তাহিক scrub এমন কোনো fault সম্পর্কে সর্বোচ্চ তিন সপ্তাহ আগে সতর্ক করতে পারে, যা আপনি যেভাবেই হোক repair করতে পারবেন না। scrub-এর খরচ কম হলেই শুধু এই trade-off যুক্তিসঙ্গত।

সময় মেপে সিদ্ধান্ত নিন। হাতে একটি scrub চালান এবং কতক্ষণ লাগে তা monitor করুন।

1. শান্ত সন্ধ্যায় sudo zpool scrub tank চালান এবং zpool status থেকে মোট সময় record করুন।
2. এটি এক ঘণ্টার অনেক কম সময়ে শেষ হলে এবং box রাতে idle থাকলে, সাপ্তাহিক scrub-এর খরচ বহন করা সম্ভব।
3. pool traffic serve করার সময় এটি অনেক ঘণ্টা চললে, মাসিক schedule বজায় রাখুন এবং packaged job-কেই এটি পরিচালনা করতে দিন।
4. pool-এর আকার উল্লেখযোগ্যভাবে বাড়লে আবার সময় মাপুন, কারণ scrub-এর সময় disk capacity নয়, allocated data-এর সঙ্গে পরিবর্তিত হয়।

আপনি যে schedule-ই বেছে নিন, recurring server work-এর অন্য কাজগুলোর পাশে সেটি লিখে রাখুন। Scrub-এর স্থান package upgrade এবং log rotation-এর একই তালিকায়: মাসিক Linux server maintenance checklist।

Scrub শুরু, বিরতি এবং বন্ধ করা

sudo zpool scrub tank
sudo zpool status tank

বিরতি দেওয়া এবং বন্ধ করা আলাদা কাজ। ভুলটি বেছে নিলে একই কাজ আবার করতে গিয়ে আপনার কয়েক ঘণ্টা নষ্ট হতে পারে।

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

-p বিরতি দেয়। বিরতির অবস্থা ও অগ্রগতি নিয়মিতভাবে disk-এ সংরক্ষিত হয়। তাই export বা reboot-এর পরেও paused scrub টিকে থাকে। pool ফিরে এলে scrub বিরত অবস্থায় অপেক্ষা করে। zpool scrub আবার চালালে disk-এ লেখা সর্বশেষ checkpoint থেকে কাজ চালু হয়। অন্যদিকে -s scrub বন্ধ করে। এরপর আপনি যে scrub শুরু করবেন, সেটি শুরু থেকেই চলবে। এক ঘণ্টার জন্য disk প্রয়োজন হলে -p ব্যবহার করুন। scrub পুরোপুরি সরিয়ে দিতে চাইলে -s ব্যবহার করুন।

আরও দুটি flag জানা দরকার। -w ফিরে আসার আগে scrub শেষ হওয়া পর্যন্ত অপেক্ষা করে। পরের ধাপ যেন আগেভাগে শুরু না হয়, তাই script-এর মধ্যে এটি ব্যবহার করুন। -e শুধু zpool status -v-এ report করা known data error থাকা file-গুলো 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 অনুসরণ করে যে address-গুলো পড়তে হবে, সেগুলো সংগ্রহ করে। Issued হলো data পর্যায়: বাস্তবে device-এ পাঠানো read request, যা disk order অনুযায়ী সাজানো থাকে। Sorted scrub-এর কারণেই দুটি counter থাকে, এবং বাস্তব অগ্রগতি বোঝার জন্য issued counter-টিই ব্যবহার করতে হবে। শুরুতে scanned, issued-এর চেয়ে অনেক এগিয়ে থাকে এবং সময়ের আনুমানিক হিসাব খুব বেশি নির্ভরযোগ্য নয়। প্রথম দশ শতাংশ সম্পন্ন হওয়ার পর অগ্রগতি বিচার করুন।

Repaired ভালো copy থেকে পুনরায় লেখা byte-এর সংখ্যা দেখায়। Redundancy না থাকা pool-এ scrub যা-ই শনাক্ত করুক, এই সংখ্যা zero-ই থাকে। এটি আগের বক্তব্যের সংখ্যাগত প্রকাশ, যা আপনি পর্যবেক্ষণ করতে পারেন।

এরপর প্রতিটি device-এর column পড়ুন। READ এবং WRITE device নিজে জানানো I/O error-এর সংখ্যা দেখায়। CKSUM checksum verification-এ ব্যর্থ block-এর সংখ্যা দেখায়, এবং scrub-এর উদ্দেশ্যই হলো CKSUM column-এ এই ত্রুটিগুলো শনাক্ত করা। স্বাভাবিক দেখাচ্ছে এমন device-এ CKSUM non-zero হলে সেটি বাস্তব ত্রুটি: data ফিরে এসেছে, কিন্তু ভুল অবস্থায় ফিরে এসেছে।

শেষ লাইনটি চূড়ান্ত ফলাফল দেখায়। `errors: No known data errors হলো সফল ফলাফল। অন্য যেকোনো ফলাফলের ক্ষেত্রে sudo zpool status -v tank চালান। এটি শেষ সম্পূর্ণ scrub-এর পর থেকে হওয়া data error-এর পূর্ণ তালিকা দেখায়, যার মধ্যে প্রভাবিত filename-ও থাকে। সেই file-গুলো backup থেকে restore করুন, counter reset করতে sudo zpool clear tank` চালান, তারপর আবার scrub করুন। প্রতিটি সম্পূর্ণ scrub এই তালিকা নতুন করে তৈরি করে। তাই সম্পূর্ণ এবং ত্রুটিমুক্ত scrub-এর পরে কোনো filename না থাকলে সেটি সত্যিই আর অবশিষ্ট নেই।

আপনার সিস্টেমে কোন periodic scrub job চলছে?

এমন কোনো job আছে ধরে নেবেন না। একটির বেশি job আছে, এটিও ধরে নেবেন না। এই প্রক্রিয়া platform এবং package অনুযায়ী ভিন্ন হয়। Pool format সর্বত্র একই। তাই এর আশপাশের tooling-ও একই—এমনটি সহজেই মনে হতে পারে। কিন্তু 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 হলো space-separated pool name-এর তালিকা। এটি খালি রাখলে প্রতিটি pool scrub হবে। কোনো pool-এর জন্য আলাদা threshold নির্ধারণ না থাকলে scrub-এর মধ্যবর্তী দিনের সংখ্যা daily_scrub_zfs_default_threshold নির্ধারণ করে। Manual-এ default হিসেবে 35 দেওয়া আছে। Daily job প্রতিদিন চলে। Threshold পার হওয়ার পরেই এটি scrub শুরু করে।

Linux-এ বিষয়টি আপনার distribution-এর ZFS package-এর ওপর নির্ভর করে। কিছু system-এ একই সঙ্গে উভয় mechanism থাকতে পারে। Per-pool systemd timer থাকে, zfs-scrub-monthly@tank.timer এবং zfs-scrub-weekly@tank.timer। এগুলো একবারে একটি pool-এর জন্য enable করা হয়। Debian এবং Ubuntu-তে /etc/cron.d/zfsutils-linux-ও থাকে। এটি এমন একটি script চালায়, যা মাসের দ্বিতীয় Sunday-তে প্রতিটি ONLINE pool scrub করে। নতুন কিছু যোগ করার আগে আপনার সিস্টেমে কী আছে তা পরীক্ষা করুন:

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

zpool history-ই নির্ভরযোগ্য উত্তর। এটি pool বাস্তবে যে scrub শুরু করেছে, তার তারিখসহ রেকর্ড রাখে। মাসে দুইবার scrub হলে উভয় mechanism সক্রিয় আছে, এবং একটিকে সরিয়ে দেওয়া উচিত। একটি timer enable করতে:

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

খালি জায়গা যেকোনো tunable-এর চেয়ে বেশি গুরুত্বপূর্ণ

ছোট pool-এ scrub-এর সময় নির্ভর করে কতটা data allocated আছে এবং তা কতটা ছড়ানো অবস্থায় আছে তার ওপর। pool ভরে গেলে উভয় সমস্যাই বাড়ে।

OpenZFS-এর নির্দেশনা হলো pool-এর free space 10%-এর ওপরে রাখা। এর নিচে গেলে allocator যে অংশগুলোর মধ্যে কাজ করে, সেই metaslab-গুলোর free space 4%-এর সীমার নিচে যেতে শুরু করে এবং allocator first-fit থেকে best-fit পদ্ধতিতে বদলে যায়। best-fit-এ CPU ব্যবহার অনেক বেশি হয়। Write latency বাড়ে, fragmentation তৈরি হয় এবং পরের scrub আরও ধীর হয়, কারণ একই পরিমাণ data তখন আরও বেশি সংখ্যক ছোট read হিসেবে আসে।

তাই প্রথম পদক্ষেপ কোনো tunable পরিবর্তন করা নয়। বরং data মুছে ফেলুন। ZFS server-এ পুরোনো snapshot-ই সাধারণত এর প্রধান কারণ। এর পরে থাকে যে Docker image ও layer কেউ prune করেনি এবং upgrade-এর পরে পড়ে থাকা kernel package। অন্য কিছু করার আগে zfs list -o space চালান। এতে snapshot দ্বারা ব্যবহৃত space এবং live data দ্বারা ব্যবহৃত space আলাদা করে দেখা যায়।

এবার knob-গুলোর সংক্ষিপ্ত আলোচনা। Linux-এ বর্তমান value পড়তে পারেন:

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

FreeBSD একই parameter-গুলো sysctl-এর মাধ্যমে প্রকাশ করে। তাই sysctl -a | grep scrub ব্যবহার করে আপনার value খুঁজে নিন। এগুলো বাড়ালে scrub দ্রুত শেষ হয়, কিন্তু application ধীর হয়ে যায়। কমালে এর বিপরীত হয়। এক বা দুইটি device-যুক্ত pool-এ কোনো setting একই সঙ্গে উভয় সুবিধা দিতে পারে না, কারণ ভাগ করার জন্য সেখানে একটিই queue আছে। কোনো knob সাধারণত design-এর সমস্যা সমাধান করে না। মাসিক scrub-এ সমস্যা হলে সঠিক ব্যাখ্যা হলো pool অতিরিক্ত পূর্ণ, অথবা device ধীর। tunable শুধু সমস্যাটিকে অন্য জায়গায় সরিয়ে দেয়।

Scrub-এর সময়ই resilver-এর সম্ভাব্য সময় বোঝার সবচেয়ে নির্ভরযোগ্য উপায়

Resilver এবং scrub একইভাবে কাজ করে: allocated block পড়ে, সেগুলো যাচাই করে, তারপর replacement device-এ অনুপস্থিত block লিখে। তাই scrub শেষ হতে যত সময় লাগে, rebuild শেষ হতে সাধারণত তার কাছাকাছি সময় লাগে। এই সময়ে pool কম redundancy নিয়ে চলবে কতক্ষণ, scrub-এর সময় তা বোঝা যায়।

ZFS scrub-এর তুলনায় resilver-এর কাজ বেশি অগ্রাধিকার দিয়ে চালায়। তাই একই pool-এর scrub-এর চেয়ে rebuild সাধারণত দ্রুত শেষ হয়। Scrub-এর সময়কে একটি conservative upper bound হিসেবে ধরুন। Scrub শেষ হতে যদি নয় ঘণ্টা লাগে, তাহলে একই মাত্রার rebuild window ধরে পরিকল্পনা করুন। এই window-এর মধ্যে দ্বিতীয় কোনো device নষ্ট হলে pool হারিয়ে যাবে। এটাই একটি প্রশস্ত raidz group-এর বদলে mirrored pair ব্যবহারের বাস্তব কারণ। ZFS RAID 5-এর পরিবর্তে যে parity layout ব্যবহার করে, সেই raidz surviving প্রতিটি device পড়ে rebuild করে।

একটি single-device pool-এ কোনো resilver হয় না। Device নষ্ট হলে pool-ও নষ্ট হয়। আপনার recovery time হলো restore time। তাই restore-এর সময় মাপুন। যে restore কখনও চালিয়ে পরীক্ষা করা হয়নি, সেটিকে recovery plan বলা যায় না।

ডিস্ক ভাড়া নিলে কী পরিবর্তন হয়

VPS-এ block device ভার্চুয়াল। hypervisor একটি volume উপস্থাপন করে। এর নিচে local NVMe থাকতে পারে, অথবা নিজস্ব parity-সহ replicated network volume থাকতে পারে। Scrub-এর ক্ষেত্রে এর দুটি ফল হয়।

প্রথমত, platform-এর redundancy ZFS-এর কাছে অদৃশ্য থাকে, এবং ZFS এটি ব্যবহার করতে পারে না। platform যদি আপনার নিচের স্তরে media error মেরামত করে, ZFS কখনো সমস্যাটি দেখতে পায় না। platform যদি ভুল block উপরে পাঠায়, ZFS সেটি শনাক্ত করে, কিন্তু মেরামত করতে পারে না। কারণ সঠিক copy সেই boundary-এর অন্য পাশে থাকে।

দ্বিতীয়ত, virtual disk-এর নিচে থাকা device-এর SMART (self-monitoring, analysis and reporting technology) data সাধারণত পড়তে পারবেন না। তাই VPS-এ disk health monitoring যে আগাম সতর্কতার ওপর নির্ভর করে, তা একেবারেই নাও পাওয়া যেতে পারে। আপনার scrub থেকে পাওয়া CKSUM counter-ই আপনার নিয়ন্ত্রণে থাকা প্রধান signal হয়ে ওঠে।

আপনি যদি শুধু report নয়, ZFS-এর মাধ্যমে repair-ও করতে চান, তাহলে একই instance-এর ভেতরে pool-এ একাধিক device থাকতে হবে। এটি tuning-এর সিদ্ধান্ত নয়; এটি পরিকল্পনার সিদ্ধান্ত। সাধারণ VPS-এর বদলে storage VPS নিলে capacity পাবেন। তবে এতে দুটি independent device পাবেন কি না, তা plan-এর ওপর নির্ভর করে। একটি volume-এর দুটি slice-কে mirror বানানোর আগে lsblk চালিয়ে নিশ্চিত হন। আমরা Linux এবং FreeBSD server ভাড়া দিই, managed ZFS appliance নয়। তাই scrub schedule এবং backup আপনাকেই চালাতে হবে। এটাই বিনিময়: pool-এর ওপর পূর্ণ নিয়ন্ত্রণ, এবং এর maintenance-এর সম্পূর্ণ দায়িত্বও আপনার।

FAQ

ZFS pool-কে VPS-এ কত ঘন ঘন scrub করা উচিত?

বেশিরভাগ ছোট pool-এর জন্য মাসে একবার যথেষ্ট। বিদ্যমান package-এর ডিফল্ট আচরণের সঙ্গেও এটি মেলে: Debian এবং Ubuntu-তে second-Sunday cron job, আর FreeBSD-এর periodic system-এ 35 day default threshold। অন্যদিকে, একটি scrub-এর সময় মেপে সেটি অন্যথায় নিষ্ক্রিয় server-এ দ্রুত শেষ হয় নিশ্চিত হওয়ার পরেই শুধু সাপ্তাহিক scrub বিবেচনা করুন। এক বা দুটি device-যুক্ত ব্যস্ত pool-এ প্রতি সপ্তাহে scrub চালালে প্রকৃত application I/O ব্যয় হয়, কিন্তু কয়েক সপ্তাহ আগে সতর্কতা পাওয়া ছাড়া অতিরিক্ত সুবিধা কম।

একটি single-disk ZFS pool scrub করা কি অর্থহীন?

না, তবে এতে কী সুবিধা পাওয়া যায় তা স্পষ্টভাবে বুঝতে হবে। Redundancy না থাকলে scrub corruption শনাক্ত করতে পারে, কিন্তু তা repair করতে পারে না। Metadata এর ব্যতিক্রম, কারণ ZFS ডিফল্টভাবে এর একটি অতিরিক্ত copy রাখে। আপনি zpool status -v-এ ক্ষতিগ্রস্ত file-এর একটি নামযুক্ত তালিকা পান। অন্য কোথাও ভালো copy থাকা অবস্থায় file পুনরুদ্ধার করার জন্য এটি যথেষ্ট আগাম সতর্কতা দেয়। সঠিক পদক্ষেপ হলো backup উন্নত করা, কারণ কোন file পুনরুদ্ধার করতে হবে scrub তা নির্দিষ্ট করে জানায়।

ZFS scrub pause করে পরে কি শেষ করা যায়?

হ্যাঁ। zpool scrub -p tank এটি pause করে, এবং pause state ও progress পর্যায়ক্রমে disk-এ লেখা হয়। তাই export বা reboot-এর পরও scrub paused অবস্থায় থাকে। শেষ checkpoint থেকে resume করতে আবার zpool scrub tank চালান। এর জন্য zpool scrub -s tank ব্যবহার করবেন না। -s scrub বন্ধ করে দেয়, এবং পরের scrub শুরু থেকে আবার চালু হয়।

আমার ZFS scrub এত ধীর কেন, এবং এটি কি দ্রুত করা যায়?

Scrub-এর সময় disk capacity-এর সঙ্গে নয়, allocated data ও fragmentation-এর সঙ্গে সম্পর্কিত। 90% এর বেশি পূর্ণ pool ধীর হয়, কারণ 4% এর কম free থাকা metaslab allocator-কে first-fit থেকে best-fit-এ নিয়ে যায়। এর ফলে তৈরি হওয়া fragmentation scrub-কে অনেক ছোট read-এ পরিণত করে। সাধারণত কোনো tunable পরিবর্তনের চেয়ে space খালি করা বেশি কার্যকর। Scrub-কে queue-এর বড় অংশ দিতে zfs_scrub_min_time_ms অথবা zfs_vdev_scrub_max_active-এর মান বাড়াতে পারেন। তবে এক বা দুটি device-যুক্ত pool-এ সেই অতিরিক্ত অংশ সরাসরি application-এর I/O থেকে আসে।