ZFS کے لیے VPS میں کتنی RAM درکار ہے؟

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

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

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

FreeBSD اور Linux پر OpenZFS: ایک codebase، دو packaging طریقے

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 پہلے سے موجود ہوتا ہے۔ عملی طور پر پوری بات اتنی ہی ہے: packaging میں ایک فرق ہے، اور آپ کو کسی ایک فریق کا انتخاب کرنے کی ضرورت نہیں۔

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 دو lines دکھاتا ہے: userland version اور kernel module version۔ صرف ایک line کا مطلب ہے کہ module load نہیں ہوا۔ package universe component میں موجود ہے، جسے Ubuntu server images پہلے سے enable کرتی ہیں؛ اگر 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

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

FreeBSD میں کچھ بھی install نہیں ہوتا۔ Service کو enable کریں اور start کریں۔

sysrc zfs_enable=YES
service zfs start

اب pool بنائیں۔ پہلے stable device paths دیکھیں، کیونکہ /dev/vdb detection order کے مطابق device names جاری کرتا ہے اور کوئی دوسرا 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 کے سب سے چھوٹے block کو 4 KiB پر مقرر کرتا ہے۔ یہ موجودہ SSDs کے مطابق ہے اور creation کے بعد تبدیل نہیں کیا جا سکتا۔

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

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 دوبارہ لکھا جاتا ہے، اور یہ event 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 کے لیے ماہانہ schedule کافی ہے۔

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

ڈیٹا سیٹس پالیسی کی اکائی ہیں

ڈیٹا سیٹ pool کے اندر ایک filesystem ہوتا ہے، اور اسے بنانا آسان ہوتا ہے، اس لیے ہر کام کے لیے ایک الگ ڈیٹا سیٹ بنائیں۔ Properties، pool سے نچلی سطح تک inherit ہوتی ہیں۔ اس کا مطلب ہے کہ default ایک بار set کریں اور جہاں ضرورت ہو وہاں اسے override کریں۔

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 سے معلوم کریں کہ آپ کو حقیقت میں کیا compression مل رہی ہے، اور یاد رکھیں کہ ratio صرف اس data کو شمار کرتا ہے جو property set ہونے کے بعد لکھا گیا ہو۔

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

quota کے ذریعے آپ کسی ایک dataset کو پورے pool کو بھرنے سے روک سکتے ہیں۔ تقریباً 100% full ZFS pool سست ہو جاتا ہے اور اس کی صفائی مشکل ہو جاتی ہے، اس لیے جان بوجھ کر کچھ headroom باقی رکھیں۔

Snapshots کی لاگت ڈیٹا تبدیل ہونے تک کچھ نہیں ہوتی

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 صرف اسی snapshot کے زیرِ استعمال space دکھاتا ہے۔ یہ ابتدا میں تقریباً صفر ہوتا ہے اور ڈیٹا تبدیل یا delete کرنے کے ساتھ بڑھتا ہے، کیونکہ پرانے blocks اب release نہیں کیے جا سکتے۔

فائل واپس حاصل کرنے کے لیے 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 ضرورت پیش آنے سے پہلے بنائیں، کیونکہ snapshot نہ ہو تو ایک معمولی rm -rf آپ کو ext4 recovery path میں لے جاتا ہے۔ اس عمل کا آغاز disk کو unmount کرنے سے ہوتا ہے اور اس کے بعد صورتِ حال مزید خراب ہو سکتی ہے۔

Rollback snapshot کے بعد لکھا گیا تمام ڈیٹا ضائع کر دیتا ہے۔

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

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

Snapshot backup نہیں ہوتا۔ یہ اسی pool، اسی volume اور اسی server پر موجود رہتا ہے۔ اگر volume fail ہو جائے یا کوئی zpool destroy واقع ہو، تو snapshots بھی ڈیٹا کے ساتھ ضائع ہو جاتے ہیں۔ 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 کے درمیان صرف تبدیل شدہ مواد بھیجیں۔

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"

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

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

یہ شرط کے ساتھ ایک حقیقی off-site backup ہے۔ دور والے سرے پر ZFS pool ہونا چاہیے، کیونکہ object storage stream وصول نہیں کر سکتا۔ اگر 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 سرور تقریباً مکمل memory والا دکھائی دیتا ہے، عموماً اس کا cache بھر چکا ہوتا ہے۔ زیادہ تر "ZFS نے میری RAM کھا لی" رپورٹس کی یہی وجہ ہوتی ہے۔

default limit جان بوجھ کر کافی زیادہ رکھی گئی ہے۔ OpenZFS 2.3، ARC کا maximum size RAM میں سے 1 GiB منہا کرنے کے بعد حاصل ہونے والی مقدار اور RAM کے 5/8 میں سے جو زیادہ ہو، اسے مقرر کرتا ہے۔ OpenZFS 2.2 اور اس سے پہلے Linux پر RAM کا نصف استعمال کرتے تھے، جبکہ FreeBSD پہلے ہی نیا اصول استعمال کرتا تھا۔ اپنے سسٹم پر لاگو اصول دیکھنے کے لیے 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
  }
]

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

table پر انحصار کرنے کے بجائے اپنے server سے اصل اعداد حاصل کریں:

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

تیسرا column bytes میں ہے۔ c_max اس وقت نافذ ceiling ہے، جبکہ size موجودہ ARC کے زیرِ استعمال memory ہے۔

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

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

پہلے workload کی memory ضرورت طے کریں۔ Database اور application کی ضروریات جمع کریں، operating system کے لیے کچھ گنجائش رکھیں، اور باقی memory ARC کو دیں۔ Postgres اور ایک web application چلانے والے 4 GB instance پر 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 میں خود دو احتیاطیں بیان کی گئی ہیں۔ System چلتے ہوئے value کو دوبارہ 0 مقرر نہیں کیا جا سکتا، اس لیے اسے واپس کرنے کے لیے file edit کر کے reboot کرنا ہوگا۔ اور number کم کرنے سے بڑی ARC فوراً چھوٹی نہیں ہوتی۔

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

چھوٹے server کے لیے memory کے دو مزید اصول ہیں۔ Deduplication بند رکھیں، کیونکہ dedup table memory میں رہتی ہے، اور عام طور پر شائع شدہ اندازہ یہ ہے کہ ہر TB unique data کے لیے 1 سے 3 GB RAM درکار ہوتی ہے۔ zvol پر swap نہ رکھیں۔ 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 کو پوری RAM درکار ہو۔
• صرف ایک 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 کو صرف enable کرنے کے بجائے حقیقتاً استعمال کرے۔ باقی تمام حالات میں ext4 کے ساتھ restic encrypted اور deduplicated backups ایسے storage پر لکھتا ہے جسے server control نہیں کرتا، اور تقریباً یہی ضروریات memory کے بغیر پوری ہو جاتی ہیں۔

خرابی کی صورتیں اور دکھائی دینے والے strings

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

kernel upgrade کے بعد Debian پر 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 بھر گیا ہے، لیکن آپ نے files delete کر دی ہیں۔ Deleted data اس وقت تک disk پر رہتا ہے جب تک کوئی snapshot اس کا حوالہ دیتا رہے۔ اسی لیے du اور df مختلف نتائج دکھاتے ہیں۔ zfs list -o space -r tank استعمال کو 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

ZFS کو VPS پر کتنی 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 spare کر سکتا ہو، پھر /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 پر ایک ہی طرح کام کرتا ہے؟

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

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

یہ corruption detect کرکے file کا نام بتا دیتا ہے، لیکن اسے repair نہیں کر سکتا، کیونکہ repair کے لیے block کی دوسری copy درکار ہوتی ہے۔ dataset پر zfs set copies=2 آپ کو یہ دوسری copy فراہم کرتا ہے، مگر اس کے لیے space دگنی درکار ہوتی ہے۔ یہ خراب block کو handle کر لیتا ہے، لیکن lost volume کو نہیں۔ دو volumes پر mirror ہی وہ حل ہے جو واقعی data کو heal کرتا ہے۔

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

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