ZFS VPS میں RAM کا خرچ: FreeBSD بمقابلہ Linux

ZFS آپ کو کیا فراہم کرتا ہے، اور اس کے لیے کیا درکار ہے

FreeBSD اور Linux پر ZFS اب ایک ہی codebase، OpenZFS، استعمال کرتا ہے، اس لیے دونوں نظاموں پر اس کی خصوصیات یکساں ہیں۔ ZFS چلانے والے سرور میں checksummed data، ایسے snapshots جو data تبدیل ہونے تک کوئی اضافی جگہ نہیں لیتے، zfs send کے ذریعے replication، اور صرف ایک property فعال کرنے سے compression دستیاب ہوتی ہے۔ اس کے لیے درکار بنیادی وسیلہ memory ہے: ARC (adaptive replacement cache) پہلے سے RAM کا بڑا حصہ استعمال کرتا ہے، اور 2 GB یا 4 GB VPS (virtual private server) میں یہی memory آپ کی application کو درکار ہوتی ہے۔

یہ guide ZFS کا جائزہ ایسے rented VPS سے لیتی ہے جس میں ایک یا دو virtual disks ہوں، نہ کہ ایسے storage box سے جس میں چالیس drive bays ہوں۔ اس منتقلی کے بعد جو خصوصیات برقرار رہتی ہیں، وہی آپ کے وقت کے قابل ہیں۔ جو خصوصیات برقرار نہیں رہتیں، pool بنانے سے پہلے ان کے بارے میں جاننا ضروری ہے۔

FreeBSD اور Linux پر OpenZFS: ایک codebase، پیکیجنگ کی دو صورتیں

FreeBSD نے 2008 میں FreeBSD 7.0 سے ZFS کو base system میں شامل رکھا ہے، ابتدا میں یہ experimental feature تھا۔ دسمبر 2020 میں OpenZFS 2.0 کے بعد FreeBSD اور Linux ایک ہی source tree سے build ہوتے ہیں، اس لیے zfs اور zpool دونوں پر ایک ہی طرح کام کرتے ہیں، اور ایک پر بنایا گیا pool دوسرے پر import ہو جاتا ہے۔

Linux پر ZFS ایک package اور FreeBSD پر base system کا حصہ ہونے کی وجہ licensing ہے۔ OpenZFS، CDDL (common development and distribution license) کے تحت ہے۔ Linux kernel، GPL (general public license) version 2 کے تحت ہے۔ kernel project ان دونوں licenses کو باہم incompatible سمجھتا ہے، اس لیے ZFS code کو mainline Linux میں merge نہیں کیا گیا، اور ہر distribution خود فیصلہ کرتی ہے کہ اسے کس طرح ship کرنا ہے۔ FreeBSD میں ایسا کوئی conflict نہیں، اس لیے ZFS پہلے سے موجود ہوتا ہے۔ عملی طور پر پوری بات یہی ہے: پیکیجنگ میں ایک فرق ہے، اور آپ کو کسی ایک فریق کا انتخاب کرنے کی ضرورت نہیں۔

SSD Nodes، FreeBSD images فراہم نہیں کرتا، اس لیے یہاں کرائے پر لیے گئے server پر اس guide کا Linux والا حصہ لاگو ہوتا ہے۔ اگر آپ کہیں اور FreeBSD چلاتے ہیں تو FreeBSD server پر ZFS کے لیے نہ module build کرنا پڑتا ہے اور نہ kernel upgrade کے بعد اسے دوبارہ برقرار رکھنا پڑتا ہے۔

ZFS انسٹال کریں اور pool بنائیں

Ubuntu میں module، kernel packages کے اندر شامل ہوتا ہے، اس لیے صرف commands انسٹال کریں۔

sudo apt update
sudo apt install -y zfsutils-linux
zfs version

zfs version دو سطریں دکھاتا ہے: userland version اور kernel module version۔ صرف ایک سطر کا مطلب ہے کہ module load نہیں ہوا۔ package، universe component میں موجود ہے، جسے Ubuntu server images پہلے سے فعال کرتی ہیں؛ اگر apt اسے تلاش نہ کر سکے تو پہلے sudo add-apt-repository universe چلائیں۔

Debian میں packages، contrib component میں موجود ہوتے ہیں اور module آپ کی machine پر DKMS (dynamic kernel module support) کے ذریعے build ہوتا ہے۔ contrib کو /etc/apt/sources.list.d/debian.sources میں موجود Components: line میں شامل کریں، پھر sudo apt update چلائیں، اور اس کے بعد:

sudo apt install -y linux-headers-$(dpkg --print-architecture) zfs-dkms zfsutils-linux

یہ installation module کو compile کرتی ہے اور Building initial module for 6.12.0-... دکھاتی ہے، جس میں چند منٹ لگتے ہیں۔ اس کا مطلب یاد رکھیں: ہر kernel upgrade پر یہ دوبارہ build ہوگا، اور build ناکام ہونے کی صورت میں مسئلہ حل کرنے تک آپ کا pool import نہیں ہوگا۔

FreeBSD میں کچھ بھی انسٹال نہیں ہوتا۔ service کو enable کریں اور start کریں۔

sysrc zfs_enable=YES
service zfs start

اب pool بنائیں۔ پہلے stable device paths دیکھیں، کیونکہ /dev/vdb detection order کے مطابق نام assign کرتا ہے اور ایک اور volume attach کرنے پر بدل سکتا ہے۔

ls -l /dev/disk/by-id/
sudo zpool create -o ashift=12 tank /dev/disk/by-id/virtio-abc123def456
zpool status tank

zpool status کو state: ONLINE دکھانا چاہیے، اور آپ کا device tank کے تحت درج ہونا چاہیے۔ ashift=12 pool کے smallest block کو 4 KiB پر مقرر کرتا ہے۔ یہ موجودہ SSDs کے لیے موزوں ہے اور creation کے بعد تبدیل نہیں کیا جا سکتا۔

زیادہ تر rented images، ext4 root سے boot ہوتی ہیں، اس لیے یہاں ZFS، root filesystem کے بجائے دوسرے volume پر data pool کے طور پر استعمال ہوگا۔ pool بنانے سے پہلے تصدیق کریں کہ device وہی ہے جسے آپ سمجھ رہے ہیں، کیونکہ آپ کو فروخت کی گئی NVMe disk کی تصدیق میں ایک منٹ لگتا ہے، جبکہ rebuild میں پوری دوپہر لگ سکتی ہے۔

Checksums صرف اسی وقت مرمت کرتے ہیں جب pool میں redundancy ہو

ZFS کے لکھے ہوئے ہر block کے ساتھ checksum شامل ہوتا ہے، اور ہر read پر اس کی تصدیق کی جاتی ہے۔ خرابی کی نشاندہی ہمیشہ کام کرتی ہے۔ مرمت کے لیے دوسری copy درکار ہوتی ہے۔

single-disk pool میں ZFS آپ کو اصل صورت حال بتا کر رک جاتا ہے۔ zpool status -v اسے یوں رپورٹ کرتا ہے:

status: One or more devices has experienced an error resulting in data
        corruption.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
errors: Permanent errors have been detected in the following files:

        /tank/data/archive.tar

خراب file کا نام دیا جاتا ہے۔ ext4 ان bytes کو کسی اطلاع کے بغیر واپس کر دیتا، اس لیے یہ نتیجہ بھی اہم ہے۔ ZFS پھر بھی اسے درست نہیں کر سکتا، کیونکہ pool میں ایسی دوسری copy موجود نہیں جس سے مرمت کی جا سکے۔

mirror کے ساتھ یہی read درست side سے فراہم کیا جاتا ہے، خراب block دوبارہ لکھا جاتا ہے، اور یہ واقعہ zpool status کے CKSUM column میں ظاہر ہوتا ہے۔ یہ self-healing ہے، اور اس کے لیے دو devices درکار ہوتے ہیں۔

sudo zpool create -o ashift=12 tank mirror /dev/disk/by-id/DISK1 /dev/disk/by-id/DISK2

VPS پر host storage عموماً پہلے ہی redundant ہوتی ہے، اکثر hypervisor کے تحت RAID 10 کی صورت میں۔ یہ آپ کو dead drive سے تحفظ دیتی ہے۔ لیکن یہ نہیں بتاتی کہ کوئی block غلط واپس آیا ہے، کیونکہ array کے پاس یہ جاننے کا کوئی طریقہ نہیں ہوتا کہ کون سی copy درست ہے۔ ZFS یہ جان سکتا ہے، کیونکہ وہ data کا موازنہ اپنے لکھے ہوئے checksum سے کرتا ہے۔

اگر آپ کے پاس ایک virtual disk ہے اور آپ کچھ repair capability چاہتے ہیں تو sudo zfs set copies=2 tank/important اس dataset کے ہر block کی دو copies اسی disk پر محفوظ کرتا ہے۔ اس سے dataset کے استعمال کردہ space کی مقدار دوگنی ہو جاتی ہے، یہ bad block سے بچا لیتا ہے، اور پورا volume غائب ہو جانے پر کوئی مدد نہیں کرتا۔

scrub پورے pool کو پڑھتا اور اس کی تصدیق کرتا ہے۔

sudo zpool scrub tank
zpool status tank

صحت مند pool کا اختتام scan: scrub repaired 0B in 00:04:11 with 0 errors جیسی line پر ہوتا ہے۔ اسے schedule پر چلائیں؛ چھوٹے pool کے لیے ماہانہ شیڈول کافی ہے۔

systemctl list-unit-files 'zfs-scrub*'
sudo systemctl enable --now zfs-scrub-monthly@tank.timer

ڈیٹاسیٹس پالیسی کی بنیادی اکائی ہیں

ڈیٹاسیٹ pool کے اندر موجود ایک filesystem ہوتا ہے، اور اسے بنانا سستا ہوتا ہے، اس لیے ہر کام کے لیے ایک الگ ڈیٹاسیٹ بنائیں۔ Properties، pool سے نچلی سطحوں تک inherit ہوتی ہیں۔ اس کا مطلب ہے کہ default ایک بار set کریں اور جہاں ضرورت ہو وہاں override کریں۔ FreeBSD پر jails عموماً اسی طرح چلائے جاتے ہیں: ہر jail کے لیے ایک الگ dataset ہوتا ہے، تاکہ کسی ایک jail کا snapshot لے کر اسے الگ سے rollback کیا جا سکے۔ یہی ان خصوصیات میں شامل ہے جو jail کو Docker container سے مختلف بناتی ہیں۔

sudo zfs create tank/data
sudo zfs create tank/pg
sudo zfs set compression=lz4 tank
sudo zfs set atime=off tank
sudo zfs set quota=20G tank/data
sudo zfs set recordsize=16K tank/pg
zfs get -r compression,compressratio,quota tank

Compression وہ property ہے جسے لوگ احتیاط کی وجہ سے فعال نہیں کرتے، حالانکہ یہ درست طریقہ نہیں ہے۔ lz4 کے لیے CPU کی معمولی مقدار درکار ہوتی ہے اور disk تک پہنچنے والے bytes کم ہو جاتے ہیں۔ اس لیے compressible data پر reads اور writes عموماً تیز ہو جاتے ہیں۔ zstd زیادہ CPU استعمال کرکے زیادہ مؤثر compression کرتا ہے۔ یہ ان logs اور archives کے لیے موزوں ہے جنہیں آپ شاذونادر ہی دوبارہ پڑھتے ہیں۔ zfs get compressratio tank سے معلوم کریں کہ حقیقت میں کیا حاصل ہو رہا ہے، اور یاد رکھیں کہ ratio میں صرف وہ data شمار ہوتا ہے جو property set ہونے کے بعد لکھا گیا ہو۔

recordsize dataset کے ذریعے لکھے جانے والے سب سے بڑے block کا سائز ہے۔ اس کی default قدر 128K ہے۔ اگر database، 128 KiB records میں 8 KiB pages لکھے تو ایک چھوٹی write کے نتیجے میں پورا record read، تبدیل اور دوبارہ write کرنا پڑتا ہے۔ Data load کرنے سے پہلے database dataset پر recordsize=16K set کریں، کیونکہ یہ property صرف نئے لکھے جانے والے blocks پر لاگو ہوتی ہے۔

quota ایک dataset کو پورے pool کو بھرنے سے روکنے کا طریقہ ہے۔ تقریباً 100% بھرا ہوا ZFS pool سست ہو جاتا ہے اور اس کی صفائی مشکل ہوتی ہے، اس لیے جان بوجھ کر کچھ اضافی جگہ خالی رکھیں۔

Snapshots میں data تبدیل ہونے تک کوئی لاگت نہیں آتی

ZFS کسی فعال block کو کبھی overwrite نہیں کرتا۔ یہ نیا block لکھتا ہے اور pointers کو update کرتا ہے۔ اسی عمل کو copy-on-write کہتے ہیں۔ Snapshot ایک ہدایت ہوتی ہے کہ "اس وقت اس dataset کے جن blocks کی طرف اشارہ ہے، انہیں محفوظ رکھیں"۔ اس لیے snapshot بنانا فوری اور مفت ہوتا ہے۔

sudo zfs snapshot tank/data@2026-08-11
zfs list -t snapshot -o name,used,refer -r tank/data

Snapshot کے لیے USED column میں صرف وہ space دکھائی جاتی ہے جو اسی snapshot نے محفوظ کر رکھی ہے۔ ابتدا میں یہ تقریباً صفر ہوتی ہے اور data تبدیل یا delete کرنے کے ساتھ بڑھتی ہے، کیونکہ پرانے blocks کو اب release نہیں کیا جا سکتا۔

کسی file کو واپس حاصل کرنے کے لیے restore step درکار نہیں ہوتا۔

ls /tank/data/.zfs/snapshot/
cp /tank/data/.zfs/snapshot/2026-08-11/notes.txt /tank/data/notes.txt

.zfs directory ls -a سے بھی hidden رہتی ہے، جب تک آپ sudo zfs set snapdir=visible tank/data نہ چلائیں۔ Snapshot اس وقت بنائیں جب ابھی اس کی ضرورت نہ ہو، کیونکہ اس کے بغیر ایک غلط rm -rf آپ کو ext4 recovery path میں لے جاتا ہے۔ یہ عمل disk کو unmount کرنے سے شروع ہوتا ہے اور اس کے بعد صورت حال مزید پیچیدہ ہو جاتی ہے۔

Rollback snapshot کے بعد لکھی گئی تمام چیزیں ضائع کر دیتا ہے۔

sudo zfs rollback tank/data@2026-08-11

اگر نئے snapshots موجود ہوں تو یہ انکار کر دیتا ہے، اور -r کارروائی جاری رکھنے کے لیے ان نئے snapshots کو delete کر دیتا ہے۔ enter دبانے سے پہلے dataset name دو بار پڑھیں۔

Snapshot backup نہیں ہوتا۔ یہ اسی pool، اسی volume اور اسی server پر موجود رہتا ہے۔ اگر volume fail ہو جائے یا ایک zpool destroy واقع ہو، تو snapshots بھی data کے ساتھ ضائع ہو جاتے ہیں۔ Snapshots آپ کی اپنی rm اور خراب upgrade سے تحفظ دیتے ہیں۔ یہ حقیقی incidents کے ایک بڑے حصے کے لیے کافی ہے، لیکن pool کے ساتھ پیش آنے والے کسی واقعے سے تحفظ نہیں دیتے۔ مکمل وضاحت یہاں موجود ہے: VPS snapshot backup کیوں نہیں ہوتا۔

بھیجنا اور وصول کرنا: ایک کمانڈ میں replication

zfs send snapshot کو standard output پر byte stream میں تبدیل کرتا ہے، جبکہ zfs receive اسی stream کو دوبارہ dataset میں تبدیل کرتا ہے۔ پہلی copy مکمل send ہوتی ہے۔

sudo zfs snapshot tank/data@daily-2026-08-11
sudo zfs send tank/data@daily-2026-08-11 | ssh backup.example.com "sudo zfs recv -F backup/data"

اس کے بعد دو snapshots کے درمیان صرف تبدیل شدہ data بھیجیں۔

sudo zfs snapshot tank/data@daily-2026-08-12
sudo zfs send -i tank/data@daily-2026-08-11 tank/data@daily-2026-08-12 | ssh backup.example.com "sudo zfs recv backup/data"

Receiving side پر وہ snapshot موجود ہونا چاہیے جس سے آپ send کر رہے ہیں۔ اگر وہ موجود نہ ہو تو receive cannot receive incremental stream: most recent snapshot of backup/data does not match incremental source کے ساتھ رک جاتا ہے، کیونکہ ZFS کے پاس فرق لاگو کرنے کے لیے base موجود نہیں ہوتا۔ ایسے snapshot سے send کریں جو دونوں sides پر موجود ہو، یا full send کے ساتھ دوبارہ شروع کریں۔

Remote root استعمال کرنے کے بجائے target پر rights دیں: sudo zfs allow -u backupuser create,mount,receive backup/data۔

یہ واقعی off-site backup ہے، لیکن ایک شرط کے ساتھ۔ دوسری طرف ZFS pool ہونا چاہیے، کیونکہ object storage stream receive نہیں کر سکتا۔ اگر آپ کا target S3-compatible storage یا سادہ Linux host ہے تو اس سے بات کرنے والا tool استعمال کریں، اور VPS سے restic backups اس طریقے کی وضاحت کرتا ہے۔

ZFS اتنی زیادہ RAM کیوں استعمال کرتا ہے؟ ARC

ARC (adaptive replacement cache)، ZFS کا read cache ہے۔ یہ معمول کے Linux page cache کے بجائے kernel memory میں رہتا ہے، اس لیے free -h اسے buff/cache کے تحت رپورٹ نہیں کرتا۔ یہ استعمال شدہ memory کے طور پر نظر آتا ہے۔ جو ZFS box تقریباً مکمل نظر آئے، عموماً اس میں cache گرم ہوتا ہے، اور زیادہ تر "ZFS نے میری RAM ختم کر دی" رپورٹس کی یہی وجہ ہوتی ہے۔

Default limit جان بوجھ کر فراخ رکھی گئی ہے۔ OpenZFS 2.3 میں ARC size کی زیادہ سے زیادہ حد RAM میں سے 1 GiB کم اور RAM کے 5/8 میں سے جو زیادہ ہو، وہ مقرر کی جاتی ہے۔ OpenZFS 2.2 اور اس سے پہلے Linux پر RAM کا نصف استعمال کرتے تھے، جبکہ FreeBSD پہلے ہی نیا rule استعمال کرتا تھا۔ اپنے سسٹم پر لاگو rule دیکھنے کے لیے zfs version چلائیں۔

[
  {
    "label": "2 GB VPS",
    "openzfs_2_2_linux_gib": 1,
    "openzfs_2_3_gib": 1.25
  },
  {
    "label": "4 GB VPS",
    "openzfs_2_2_linux_gib": 2,
    "openzfs_2_3_gib": 3
  },
  {
    "label": "8 GB VPS",
    "openzfs_2_2_linux_gib": 4,
    "openzfs_2_3_gib": 7
  },
  {
    "label": "16 GB VPS",
    "openzfs_2_2_linux_gib": 8,
    "openzfs_2_3_gib": 15
  }
]

یہ اعداد و شمار عام instance sizes پر documented default rule لاگو کرنے سے حاصل ہوئے ہیں، running box کی measurements نہیں ہیں۔ 4 GB instance پر 2.3 rule ARC کو 3 GiB تک جانے دیتا ہے۔ اسی box پر 2.2 کی حد 2 GiB ہے۔ 2.3 rule کے تحت 2 GB instance بھی 1.25 GiB تک ARC رکھ سکتا ہے۔ آپ کی application کو باقی memory ملتی ہے۔

Table پر انحصار کرنے کے بجائے اپنے server سے اصل اعداد و شمار حاصل کریں:

grep -E '^(size|c_max) ' /proc/spl/kstat/zfs/arcstats
arc_summary | head -n 20

تیسرا column bytes میں ہے۔ c_max اس وقت نافذ maximum limit ہے، جبکہ size ARC میں موجودہ data کی مقدار ہے۔

ARC memory واپس کرتا ہے۔ Kernel memory pressure کا signal دیتا ہے اور ARC سکڑ جاتا ہے۔ مسئلہ timing کا ہے، کیونکہ یہ shrink اسی pressure سے شروع ہوتی ہے۔ اس لیے ایک ہی وقت میں کئی سو MiB memory مانگنے والا process OOM (out of memory) killer کا سامنا کر سکتا ہے، جبکہ ARC ابھی memory واپس کر رہا ہو۔ 2 GB box پر database اور web server چل رہے ہوں تو یہ کوئی نادر واقعہ نہیں ہے۔ OpenZFS manual میں manual changes کے بارے میں بھی یہی بات کہی گئی ہے: limit کم کرنے سے "memory pressure کے بغیر ARC shrink نہیں ہوگا جو shrinking شروع کرے"۔

چھوٹے VPS پر ARC کی حد کیسے مقرر کریں

پہلے workload کی memory کی ضرورت طے کریں۔ Database اور application کی مطلوبہ memory جمع کریں، operating system کے لیے کچھ گنجائش رکھیں، اور باقی memory ARC کو دیں۔ 4 GB کی ایسی instance پر جو Postgres اور ایک web application چلا رہی ہو، 512 MiB سے 1 GiB تک ARC ایک مناسب ابتدائی حد ہے۔

اسے live حالت میں bytes میں مقرر کریں۔ یہ مثال 1 GiB کی ہے۔

echo 1073741824 | sudo tee /sys/module/zfs/parameters/zfs_arc_max

اس ترتیب کو reboot کے بعد بھی برقرار رکھیں۔

echo 'options zfs zfs_arc_max=1073741824' | sudo tee /etc/modprobe.d/zfs.conf
sudo update-initramfs -u

initramfs کا مرحلہ اس لیے اہم ہے کہ root filesystem mount ہونے سے پہلے module، initramfs سے load ہو سکتا ہے۔ ایسی صورت میں وہ آپ کی ابھی لکھی ہوئی file نہیں پڑھے گا۔ reboot کے بعد arcstats سے c_max والی line کے ذریعے تصدیق کریں۔

Manual سے دو caveats معلوم ہوتی ہیں۔ system چلتے وقت value کو واپس 0 پر مقرر نہیں کیا جا سکتا، اس لیے اسے ختم کرنے کے لیے file میں ترمیم اور reboot ضروری ہے۔ اور number کم کرنے سے بڑی ARC فوراً چھوٹی نہیں ہوتی۔

FreeBSD میں یہی limit vfs.zfs.arc کے تحت sysctl کے طور پر موجود ہوتی ہے۔ موجودہ values اور آپ کے version میں استعمال ہونے والا درست نام دیکھنے کے لیے sysctl vfs.zfs.arc چلائیں، پھر زیادہ سے زیادہ value /boot/loader.conf میں لکھیں۔

چھوٹے server کے لیے memory کے دو مزید اصول ہیں۔ Deduplication بند رکھیں، کیونکہ dedup table memory میں رہتی ہے اور عام طور پر شائع کیا جانے والا اندازہ unique data کے ہر TB کے لیے 1 سے 3 GB RAM ہے۔ اس کے علاوہ swap کو zvol پر نہ رکھیں؛ zvol ایک block device ہے جو pool سے بنایا جاتا ہے۔ جس filesystem کے ذریعے memory خالی کرنے کی کوشش ہو رہی ہو، اسی کے ذریعے swapping machine کو deadlock کر سکتی ہے۔ Swap کو plain partition یا pool سے باہر موجود swap file پر رکھیں۔

جب ext4 یا XFS کے ساتھ restic بہتر انتخاب ہو

ZFS ایسے سرور پر مفید ثابت ہوتا ہے جس میں اضافی memory اور دوسری volume موجود ہو۔ اس کے علاوہ، سادہ filesystem کے ساتھ حقیقی backup tool زیادہ بہتر رہتا ہے۔ ان حالات میں ext4 یا XFS منتخب کریں:

• instance میں 2 GB یا 4 GB RAM ہو اور workload کو اس کی تمام memory درکار ہو۔
• صرف ایک virtual disk ہو اور دوسری copy موجود نہ ہو، اس لیے ZFS صرف خرابی کا پتہ لگائے گا، اسے درست نہیں کر سکے گا۔
• آپ کا backup target object storage یا سادہ Linux host ہو، جہاں کوئی چیز zfs send stream وصول نہیں کر سکتی۔
• آپ DKMS کے ساتھ Debian چلا رہے ہوں اور ایسا kernel upgrade برداشت نہ کر سکتے ہوں جس کے بعد module build نہ ہو۔
• آپ کو root filesystem پر ZFS درکار ہو، لیکن provider کی images صرف ext4 پیش کرتی ہوں۔

ZFS اس وقت برقرار رکھیں جب الگ data volume، اضافی RAM (8 GB یا اس سے زیادہ موزوں ہے)، اور ایسا منصوبہ موجود ہو جو snapshots اور zfs send کو صرف فعال کرنے کے بجائے حقیقی طور پر استعمال کرے۔ باقی تمام صورتوں میں، ext4 کے ساتھ restic کے ذریعے encrypted اور deduplicated backups ایسے storage پر لکھنا، جسے سرور control نہیں کرتا، تقریباً وہی ضرورت پوری کر دیتا ہے اور memory بھی نہیں لیتا۔

خرابی کی صورتیں، اور وہ strings جو آپ دیکھیں گے

reboot کے بعد pool موجود نہیں۔ zpool status، no pools available دکھاتا ہے۔ import service، /etc/zfs/zpool.cache پڑھتی ہے، اس لیے اس file میں موجود نہ ہونے والا pool boot کے وقت کبھی import نہیں ہوتا۔ sudo zpool import بتاتا ہے کہ کیا import کیا جا سکتا ہے، sudo zpool import tank اسے واپس لاتا ہے، اور sudo zpool set cachefile=/etc/zfs/zpool.cache tank اس configuration کو مستقل کر دیتا ہے۔ جو pool کسی دوسرے system سے درست طریقے سے export نہ کیا گیا ہو، وہ cannot import 'tank': pool may be in use from other system دکھاتا ہے۔ جب آپ کو یقین ہو کہ کسی دوسرے host کے پاس وہ pool موجود نہیں، تو sudo zpool import -f tank اس حالت کو override کرتا ہے۔

Debian پر kernel upgrade کے بعد modprobe: FATAL: Module zfs not found in directory /lib/modules/6.12.0-...۔ DKMS نے نئے kernel کے لیے build نہیں کیا، عموماً اس لیے کہ متعلقہ headers install نہیں ہیں۔ dkms status دکھاتا ہے کہ کون سی چیز کس kernel کے لیے build ہے۔ اس کے بعد sudo apt install -y linux-headers-$(uname -r)، sudo dkms autoinstall کو چلا کر اسے دوبارہ build کرتا ہے، اور sudo zpool import tank pool واپس لاتا ہے۔

pool full ہے، لیکن آپ نے files delete کر دی ہیں۔ Deleted data disk پر موجود رہتا ہے جب تک کوئی snapshot اس کا حوالہ دیتا رہے۔ اسی لیے du اور df کے نتائج مختلف ہوتے ہیں۔ zfs list -o space -r tank usage کو USEDDS اور USEDSNAP میں تقسیم کرتا ہے۔ بڑا USEDSNAP اس کی وجہ بتاتا ہے۔ sudo zfs destroy tank/data@2026-06-01 کے ذریعے پرانے snapshots destroy کریں؛ اس کے بعد space واپس آ جائے گی۔

zpool status میں CKSUM کی تعداد بڑھ رہی ہے۔ ZFS کے نیچے موجود کسی component نے خراب data واپس کیا ہے۔ mirror پر یہ count warning ہوتا ہے اور block repair ہو چکا ہوتا ہے۔ single-disk pool پر file ضائع ہو جاتی ہے، zpool status -v اس کا نام بتاتا ہے، اور آپ اس ایک file کو ایسے backup سے restore کرتے ہیں جو اس pool میں موجود نہ ہو۔

server سست ہے اور swapping کر رہا ہے۔ اوپر بیان کیے گئے طریقے کے مطابق ARC کی حد مقرر کریں، پھر arc_summary چلائیں اور hit ratio دیکھیں۔ اگر ARC اتنا چھوٹا ہو کہ working set محفوظ نہ کر سکے تو ہر read disk پر جائے گا۔ اس صورت میں page cache استعمال کرنے والا عام filesystem آپ کے لیے بہتر کارکردگی دے گا۔

FAQ

VPS پر ZFS کو کتنی RAM درکار ہوتی ہے؟

ZFS، 2 GB instance پر چلتا ہے۔ اصل سوال یہ ہے کہ آپ کی application کے لیے کتنی RAM باقی رہتی ہے۔ کسی tuning کے بغیر، OpenZFS 2.3، ARC کو RAM میں سے 1 GiB کم یا RAM کے 5/8 میں سے جو مقدار زیادہ ہو، اتنا بڑھنے دیتا ہے؛ اس لیے 4 GB کا server cache کے لیے 3 GiB دے سکتا ہے۔ zfs_arc_max کو اس مقدار پر set کریں جو آپ کا workload فراہم کر سکتا ہو، پھر /proc/spl/kstat/zfs/arcstats سے c_max line پڑھ کر اس کی تصدیق کریں۔

کیا ZFS snapshot backup ہوتا ہے؟

نہیں۔ Snapshot اسی pool میں رہتا ہے جس میں data موجود ہوتا ہے۔ یہ خراب rm اور ناکام upgrade کے بعد بھی برقرار رہتا ہے، لیکن pool یا instance کے ساتھ ہی ختم ہو جاتا ہے۔ اسے backup میں تبدیل کرنے کے لیے zfs send کے ذریعے دوسری machine پر بھیجیں، یا ایسا backup tool چلائیں جو data اس storage پر لکھے جسے یہ server control نہیں کرتا۔

کیا ZFS، FreeBSD اور Linux پر ایک ہی طرح کام کرتا ہے؟

December 2020 میں OpenZFS 2.0 کے بعد سے codebase، commands اور on-disk format ایک جیسے ہیں، اور pools دونوں systems کے درمیان منتقل کیے جا سکتے ہیں۔ فرق packaging میں ہے۔ FreeBSD، ZFS کو base system میں شامل کرکے جاری کرتا ہے۔ Linux پر ہر distribution اپنا فیصلہ کرتی ہے: Ubuntu، module کو اپنے kernel packages میں build کرتا ہے، جبکہ Debian اسے DKMS کے ذریعے آپ کی machine پر build کرتا ہے۔ اس لیے kernel upgrade کے بعد rebuild کامیاب ہونے تک module دستیاب نہ رہے۔

کیا ایک disk والے VPS پر ZFS corruption کی repair کر سکتا ہے؟

یہ corruption کا پتا چلا کر file کا نام بتا دیتا ہے، لیکن اسے repair نہیں کر سکتا، کیونکہ repair کے لیے block کی دوسری copy درکار ہوتی ہے۔ Dataset پر zfs set copies=2 لگانے سے double space استعمال کرتے ہوئے یہ دوسری copy مل جاتی ہے۔ اس سے bad block سنبھالا جا سکتا ہے، لیکن lost volume نہیں۔ دو volumes پر mirror ہی وہ حل ہے جو واقعی data کو heal کرتا ہے۔

کیا compression server کو سست کر دیتا ہے؟

lz4 عموماً server کو تیز کرتا ہے۔ Compressed blocks کا مطلب ہے کہ کم bytes write اور read کرنے پڑتے ہیں، اور ہر block پر CPU کی لاگت اس disk کے مقابلے میں کم ہوتی ہے جس کی I/O یہ بچاتا ہے۔ compression=lz4 کو pool root پر set کریں تاکہ ہر dataset اسے inherit کرے، پھر حقیقی data لکھے جانے کے بعد zfs get compressratio tank check کریں۔