FreeBSD और Linux पर ZFS: RAM का सही उपयोग कैसे करें

ZFS आपको क्या देता है, और क्या लेता है

FreeBSD और Linux पर ZFS अब एक ही कोडबेस, OpenZFS है, इसलिए दोनों सिस्टम पर फीचर्स समान हैं। ZFS चलाने वाले सर्वर को checksummed डेटा, ऐसे snapshots जो डेटा बदलने तक मुफ्त रहते हैं, zfs send के साथ replication, और compression मिलता है जो केवल एक property दूर है। यह जो लेता है वह है मेमोरी: ARC (adaptive replacement cache) डिफ़ॉल्ट रूप से RAM का एक बड़ा हिस्सा ले लेता है, और 2 GB या 4 GB के VPS (virtual private server) पर वही मेमोरी वह होती है जिसकी आपके एप्लिकेशन को आवश्यकता होती है।

यह गाइड ZFS का मूल्यांकन एक या दो virtual disks वाले किराए के VPS से करती है, न कि चालीस drive bays वाले स्टोरेज बॉक्स से। जो फीचर्स इस बदलाव में टिके रहते हैं, वे ही आपके समय के लायक हैं। जो हिस्से इसमें नहीं टिकते, उन्हें pool बनाने से पहले जान लेना बेहतर है।

FreeBSD और Linux पर OpenZFS: एक कोडबेस, दो पैकेजिंग कहानियाँ

FreeBSD में 2008 से FreeBSD 7.0 के बाद से ZFS बेस सिस्टम का हिस्सा रहा है, शुरुआत में यह एक प्रयोगात्मक फीचर था। दिसंबर 2020 में OpenZFS 2.0 के आने के बाद से, FreeBSD और Linux दोनों एक ही सोर्स ट्री से बिल्ड होते हैं, इसलिए zfs और zpool दोनों पर एक समान व्यवहार करते हैं, और एक सिस्टम पर बनाया गया पूल दूसरे पर आसानी से इम्पोर्ट हो जाता है।

Linux पर ZFS का एक पैकेज होने और FreeBSD पर बेस सिस्टम का हिस्सा होने का कारण लाइसेंसिंग है। OpenZFS, CDDL (कॉमन डेवलपमेंट एंड डिस्ट्रीब्यूशन लाइसेंस) के अंतर्गत आता है। Linux कर्नल, GPL (जनरल पब्लिक लाइसेंस) वर्जन 2 के अंतर्गत आता है। कर्नल प्रोजेक्ट इन दोनों को असंगत मानता है, इसलिए ZFS कोड को मेनलाइन Linux में मर्ज नहीं किया गया है, और प्रत्येक डिस्ट्रीब्यूशन यह तय करता है कि इसे कैसे उपलब्ध कराना है। FreeBSD में ऐसा कोई विवाद नहीं है, इसलिए ZFS वहां पहले से मौजूद होता है। व्यावहारिक रूप से पूरी कहानी यही है: पैकेजिंग में एक अंतर है, और आपको इस पर किसी पक्ष का चुनाव करने की आवश्यकता नहीं है।

SSD Nodes FreeBSD इमेज प्रदान नहीं करता है, इसलिए यहाँ किराए पर लिए गए सर्वर पर इस गाइड का Linux वाला हिस्सा ही लागू होता है। यदि आप कहीं और FreeBSD चलाते हैं, तो एक FreeBSD सर्वर पर ZFS बिना किसी मॉड्यूल को बिल्ड किए और बिना किसी कर्नल अपग्रेड की चिंता के उपलब्ध हो जाता है।

ZFS इंस्टॉल करें और एक pool बनाएँ

Ubuntu पर यह मॉड्यूल kernel packages के भीतर आता है, इसलिए आपको केवल commands इंस्टॉल करनी होती हैं।

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

zfs version दो लाइनें प्रिंट करता है, userland वर्ज़न और kernel मॉड्यूल वर्ज़न। यदि केवल एक लाइन दिखे, तो इसका मतलब है कि मॉड्यूल लोड नहीं हुआ है। यह पैकेज universe component में होता है, जिसे Ubuntu server images डिफ़ॉल्ट रूप से सक्षम रखती हैं; यदि apt इसे न ढूँढ पाए, तो पहले sudo add-apt-repository universe चलाएँ।

Debian पर ये पैकेज contrib component में होते हैं और मॉड्यूल को आपकी मशीन पर DKMS (dynamic kernel module support) द्वारा build किया जाता है। /etc/apt/sources.list.d/debian.sources में Components: लाइन में contrib जोड़ें, sudo apt update चलाएँ, और फिर:

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

इंस्टॉलेशन मॉड्यूल को compile करता है और Building initial module for 6.12.0-... प्रिंट करता है, जिसमें कुछ मिनट लगते हैं। याद रखें कि इसका क्या अर्थ है: हर kernel अपग्रेड इसे फिर से build करता है, और यदि build विफल हो जाए, तो जब तक आप इसे ठीक नहीं करते, आपका pool import नहीं होगा।

FreeBSD पर कुछ भी इंस्टॉल करने की आवश्यकता नहीं है। बस service को enable करें और start करें।

sysrc zfs_enable=YES
service zfs start

अब pool की बात करते हैं। पहले stable device paths देखें, क्योंकि /dev/vdb detection order के आधार पर दिए जाते हैं और कोई अन्य volume जोड़ने पर बदल सकते हैं।

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 के बाद बदला नहीं जा सकता।

अधिकांश रेंट पर ली गई images ext4 root से बूट होती हैं, इसलिए यहाँ ZFS root filesystem के बजाय दूसरे volume पर एक data pool है। उस पर कुछ भी बनाने से पहले जाँच लें कि device वही है जो आप सोच रहे हैं, क्योंकि आपको बेची गई NVMe डिस्क की पुष्टि करना एक मिनट का काम है, जबकि rebuild में पूरी दोपहर लग सकती है।

Checksums केवल तभी मरम्मत करते हैं जब pool में redundancy हो

ZFS द्वारा लिखा गया प्रत्येक block एक checksum वहन करता है, और प्रत्येक read इसे verify करता है। detection हमेशा काम करता है। मरम्मत के लिए एक दूसरी copy की आवश्यकता होती है।

एक single-disk pool पर, ZFS आपको सच्चाई बताता है और वहीं रुक जाता है। zpool status -v इसे इस तरह report करता है:

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 से serve की जाती है, खराब 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 है और आप कुछ मरम्मत क्षमता चाहते हैं, तो sudo zfs set copies=2 tank/important उस dataset के प्रत्येक block की दो copies उसी disk पर store करता है। यह उस dataset द्वारा उपयोग की जाने वाली जगह को दोगुना कर देता है, यह एक खराब block से बच जाता है, और जब पूरा volume गायब हो जाता है तो यह कुछ नहीं करता है।

एक scrub pool में सब कुछ पढ़ता है और इसे verify करता है।

sudo zpool scrub tank
zpool status tank

एक healthy 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

Datasets नीति की इकाई हैं

Dataset पूल के भीतर एक filesystem होता है, और इसे बनाना बहुत आसान है, इसलिए प्रत्येक कार्य (job) के लिए एक अलग dataset बनाएँ। Properties पूल से नीचे की ओर inherit होती हैं, जिसका अर्थ है कि आप एक बार default सेट करते हैं और जहाँ आवश्यक हो वहाँ उसे 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 का उपयोग होता है और यह डिस्क तक पहुँचने वाले bytes की संख्या को कम करता है, इसलिए compressible डेटा पर यह आमतौर पर reads और writes को तेज़ बनाता है। zstd अधिक CPU के बदले बेहतर compression प्रदान करता है, जो logs और archives के लिए उपयुक्त है जिन्हें आप शायद ही कभी पढ़ते हैं। zfs get compressratio tank के साथ जाँचें कि आपको वास्तव में क्या परिणाम मिल रहे हैं, और याद रखें कि ratio केवल उस डेटा की गणना करता है जो property सेट होने के बाद लिखा गया है।

recordsize वह सबसे बड़ा block है जिसे एक dataset लिखता है, जो default रूप से 128K होता है। 128 KiB records में 8 KiB pages लिखने वाला database एक छोटे write को पूरे record के read, बदलाव और वापस write में बदल देता है। डेटा लोड करने से पहले database dataset पर recordsize=16K सेट करें, क्योंकि यह property केवल नए लिखे गए blocks पर लागू होती है।

quota वह तरीका है जिससे आप किसी एक dataset को पूरा पूल भरने से रोकते हैं। 100% भरा हुआ ZFS पूल धीमा हो जाता है और उसे साफ करना कठिन होता है, इसलिए जानबूझकर कुछ जगह खाली छोड़ें।

Snapshots की कोई लागत नहीं होती जब तक डेटा बदल न जाए

ZFS कभी भी live block को overwrite नहीं करता है। यह एक नया block लिखता है और pointers को update करता है, जिसे copy-on-write कहा जाता है। Snapshot एक नोट की तरह है जो कहता है "उन blocks को सुरक्षित रखें जिनकी ओर यह dataset अभी इशारा कर रहा है", इसलिए इसे लेना तत्काल और मुफ्त है।

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

Snapshot के लिए USED कॉलम वह space है जो केवल उस snapshot द्वारा घेरा गया है। यह शून्य के करीब शुरू होता है और जैसे-जैसे आप डेटा बदलते या हटाते हैं, यह बढ़ता जाता है, क्योंकि पुराने blocks को अब release नहीं किया जा सकता है।

किसी file को वापस पाने के लिए किसी restore चरण की आवश्यकता नहीं होती है।

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

.zfs directory तब तक छिपी रहती है, यहाँ तक कि ls -a से भी, जब तक आप sudo zfs set snapdir=visible tank/data नहीं चलाते। Snapshot को उसकी आवश्यकता पड़ने से पहले ही ले लें, क्योंकि इसके बिना एक गलत rm -rf आपको the ext4 recovery path पर ले जाता है, जो disk को unmount करने से शुरू होता है और उसके बाद स्थिति और खराब होती जाती है।

Rollback snapshot के बाद लिखी गई हर चीज़ को हटा देता है।

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

यदि नए snapshots मौजूद हों तो यह rollback करने से मना कर देता है, और -r आगे बढ़ने के लिए उन नए snapshots को नष्ट कर देता है। Enter दबाने से पहले dataset का नाम दो बार पढ़ें।

Snapshot एक backup नहीं है। यह उसी pool में, उसी volume पर, उसी server पर रहता है। एक विफल volume या zpool destroy डेटा के साथ-साथ snapshots को भी ले डूबता है। Snapshots आपको अपनी खुद की rm और खराब upgrade से बचाते हैं, जो कई वास्तविक घटनाओं को कवर करता है, लेकिन वे pool के साथ होने वाली किसी भी समस्या से सुरक्षा नहीं देते हैं। पूरा विवरण यहाँ दिया गया है: why a VPS snapshot is not a backup।

भेजना और प्राप्त करना: एक कमांड में replication

zfs send एक snapshot को standard output पर byte stream में बदल देता है, और zfs receive उस stream को वापस dataset में बदल देता है। पहली copy एक full 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"

प्राप्त करने वाले पक्ष (receiving side) के पास वह snapshot होना चाहिए जिससे आप भेज रहे हैं। जब ऐसा नहीं होता है, तो receive cannot receive incremental stream: most recent snapshot of backup/data does not match incremental source के साथ रुक जाता है, क्योंकि ZFS के पास अंतर लागू करने के लिए कोई आधार (base) नहीं होता है। ऐसे snapshot से भेजें जो दोनों पक्षों के पास हो, या full send के साथ फिर से शुरू करें।

Remote root का उपयोग करने के बजाय target पर अधिकार प्रदान करें: sudo zfs allow -u backupuser create,mount,receive backup/data।

यह एक शर्त के साथ वास्तविक off-site backup है। दूरस्थ छोर (far end) पर एक ZFS pool होना चाहिए, क्योंकि object storage एक stream प्राप्त नहीं कर सकता है। जब आपका target S3-compatible storage या कोई साधारण Linux host हो, तो ऐसे tool का उपयोग करें जो उससे बात कर सके, और restic backups from a VPS उस मार्ग को कवर करता है।

ZFS इतनी RAM का उपयोग क्यों करता है? ARC

ARC (adaptive replacement cache) ZFS का read cache है। यह सामान्य Linux page cache के बजाय kernel memory में रहता है, इसलिए free -h इसे buff/cache के अंतर्गत रिपोर्ट नहीं करता है। यह उपयोग में मौजूद memory के रूप में दिखाई देता है। एक ZFS बॉक्स जो लगभग भरा हुआ दिखता है, वह आमतौर पर एक warm cache वाला बॉक्स होता है, और "ZFS ने मेरी RAM खा ली" वाली अधिकांश रिपोर्टों का यही कारण है।

डिफ़ॉल्ट सीमा जानबूझकर उदार रखी गई है। OpenZFS 2.3 अधिकतम ARC आकार को 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
  }
]

ये आंकड़े सामान्य instance आकारों पर लागू होने वाले दस्तावेजी डिफ़ॉल्ट नियम हैं, न कि किसी चल रहे बॉक्स से लिए गए माप। 4 GB के instance पर 2.3 का नियम 3 GiB के ARC की अनुमति देता है। 2.2 पर वही बॉक्स 2 GiB पर रुक जाता है। 2.3 नियम के तहत 2 GB का instance अभी भी 1.25 GiB की अनुमति देता है। आपके application को जो बचता है, वह मिलता है।

तालिका पर भरोसा करने के बजाय अपने सर्वर से वास्तविक संख्याएँ पढ़ें:

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

तीसरा कॉलम bytes में है। c_max वर्तमान में लागू अधिकतम सीमा है, और size वह है जो ARC वर्तमान में धारण किए हुए है।

ARC वास्तव में memory वापस देता है। Kernel pressure का संकेत देता है और ARC सिकुड़ जाता है। समस्या समय (timing) की है, क्योंकि यह सिकुड़न उस pressure से प्रेरित होती है, इसलिए एक साथ कई सौ MiB की मांग करने वाली प्रक्रिया OOM (out of memory) killer का सामना कर सकती है, जबकि ARC अभी भी memory मुक्त कर रहा होता है। database और web server चलाने वाले 2 GB के बॉक्स पर, यह कोई दुर्लभ घटना नहीं है। OpenZFS manual मैन्युअल परिवर्तनों के बारे में भी यही कहता है: सीमा कम करने से "memory pressure के बिना ARC अपने आप नहीं सिकुड़ेगा"।

छोटे VPS पर ARC को सीमित कैसे करें

सबसे पहले वर्कलोड की मेमोरी तय करें। डेटाबेस और एप्लिकेशन की जरूरतों को जोड़ें, ऑपरेटिंग सिस्टम के लिए कुछ मार्जिन रखें, और बाकी बची मेमोरी ARC को दें। 4 GB वाले इंस्टेंस पर, जहाँ Postgres और एक वेब एप्लिकेशन चल रहा हो, 512 MiB से 1 GiB ARC एक उचित शुरुआती बिंदु है।

इसे bytes में लाइव सेट करें। यहाँ 1 GiB का उदाहरण है।

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

इसे रीबूट के बाद भी प्रभावी बनाए रखें।

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

initramfs वाला चरण महत्वपूर्ण है क्योंकि मॉड्यूल रूट फाइलसिस्टम माउंट होने से पहले ही initramfs से लोड हो सकता है, जिसका अर्थ है कि यह आपके द्वारा बनाई गई फाइल को कभी नहीं पढ़ेगा। रीबूट के बाद, arcstats से c_max लाइन के साथ पुष्टि करें।

मैनुअल में दो सावधानियां दी गई हैं। सिस्टम चलते समय आप मान को वापस 0 पर सेट नहीं कर सकते, इसलिए इसे हटाने का मतलब है फाइल को एडिट करना और रीबूट करना। साथ ही, संख्या कम करने से पहले से मौजूद बड़ा ARC तुरंत छोटा नहीं होता।

FreeBSD पर यही सीमा vfs.zfs.arc के अंतर्गत एक sysctl है। वर्तमान मान और आपके वर्जन द्वारा उपयोग किया जाने वाला सटीक नाम देखने के लिए sysctl vfs.zfs.arc चलाएं, फिर अधिकतम मान को /boot/loader.conf में लिखें।

छोटे सर्वर के लिए मेमोरी के दो और नियम हैं। Deduplication को बंद रखें, क्योंकि dedup टेबल मेमोरी में रहती है और सामान्य नियम यह है कि प्रति TB यूनिक डेटा के लिए 1 से 3 GB RAM की आवश्यकता होती है। और swap को zvol (पूल से बना एक ब्लॉक डिवाइस) पर न रखें, क्योंकि जो फाइलसिस्टम मेमोरी खाली करने की कोशिश कर रहा है, उसी के माध्यम से स्वैपिंग करने से मशीन डेडलॉक हो सकती है। स्वैप को एक साधारण पार्टीशन या पूल के बाहर एक स्वैप फाइल पर रखें।

कब ext4 या XFS और restic बेहतर विकल्प हैं

ZFS उन सर्वरों पर उपयोगी है जिनमें अतिरिक्त मेमोरी और दूसरा वॉल्यूम उपलब्ध हो। इसके अलावा, एक साधारण filesystem और एक वास्तविक backup tool का उपयोग करना अधिक प्रभावी है। ext4 या XFS चुनें जब:

• instance में 2 GB या 4 GB RAM हो और workload को पूरी मेमोरी की आवश्यकता हो।
• केवल एक 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 पर लिखना, जिसे सर्वर नियंत्रित नहीं करता, कम मेमोरी खपत में लगभग समान सुरक्षा प्रदान करता है।

विफलता के प्रकार और दिखाई देने वाले संदेश

Reboot के बाद pool गायब हो जाता है। zpool status, no pools available प्रिंट करता है। Import service, /etc/zfs/zpool.cache को पढ़ती है, इसलिए जो pool उस file में नहीं होता, वह boot के समय कभी import नहीं होता। sudo zpool import उन pools की सूची दिखाता है जिन्हें import किया जा सकता है, sudo zpool import tank उन्हें वापस लाता है, और sudo zpool set cachefile=/etc/zfs/zpool.cache tank उन्हें स्थायी बनाता है। यदि किसी अन्य system से pool को ठीक से export नहीं किया गया था, तो वह cannot import 'tank': pool may be in use from other system रिपोर्ट करता है, और जब आप सुनिश्चित हो जाएं कि किसी अन्य host के पास वह नहीं है, तो sudo zpool import -f tank उस त्रुटि को अनदेखा (override) कर देता है।

Kernel upgrade के बाद Debian पर modprobe: FATAL: Module zfs not found in directory /lib/modules/6.12.0-...। नए kernel के लिए DKMS build नहीं हुआ, आमतौर पर इसलिए क्योंकि संबंधित headers installed नहीं हैं। 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 उसे reference करता है, इसलिए du और df के परिणाम मेल नहीं खाते। zfs list -o space -r tank उपयोग को USEDDS और USEDSNAP में विभाजित करता है, और एक बड़ा USEDSNAP ही इसका उत्तर है। पुराने snapshots को sudo zfs destroy tank/data@2026-06-01 के साथ नष्ट (destroy) करें और space वापस मिल जाएगा।

zpool status में CKSUM की संख्या बढ़ रही है। ZFS के नीचे किसी चीज़ ने खराब data लौटाया है। Mirror पर यह संख्या केवल एक चेतावनी है और block को ठीक कर दिया गया है। 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 का box cache के लिए 3 GiB दे सकता है। zfs_arc_max को उस संख्या पर सेट करें जिसे आपका workload वहन कर सके, फिर /proc/spl/kstat/zfs/arcstats से c_max लाइन पढ़कर इसकी पुष्टि करें।

क्या ZFS snapshot एक backup है?

नहीं। Snapshot उसी pool में रहता है जिसमें data होता है। यह एक खराब rm और failed upgrade से तो बच सकता है, लेकिन pool या instance के नष्ट होने पर यह भी खत्म हो जाता है। इसे backup में बदलने के लिए इसे zfs send के माध्यम से किसी अन्य machine पर भेजें, या किसी ऐसे backup tool का उपयोग करें जो उस storage पर लिखता हो जिसे यह server नियंत्रित नहीं करता है।

क्या ZFS, FreeBSD और Linux पर एक समान काम करता है?

दिसंबर 2020 में OpenZFS 2.0 के बाद से codebase समान है, commands समान हैं, on-disk format समान है, और pools को इनके बीच move किया जा सकता है। अंतर केवल packaging का है। FreeBSD, ZFS को base system में देता है। Linux पर हर distribution अपना निर्णय लेती है: Ubuntu module को अपने kernel packages में build करती है, जबकि Debian इसे आपकी machine पर DKMS के साथ build करती है, इसलिए kernel upgrade के बाद rebuild सफल होने तक आप module के बिना रह सकते हैं।

क्या ZFS एक disk वाले VPS पर corruption को ठीक कर सकता है?

यह corruption का पता लगाता है और file का नाम बताता है, लेकिन यह उसे ठीक नहीं कर सकता, क्योंकि repair के लिए block की दूसरी copy की आवश्यकता होती है। dataset पर zfs set copies=2 का उपयोग करने से आपको दुगुनी जगह पर वह दूसरी copy मिल जाती है, जो एक खराब block को तो संभाल सकती है लेकिन खोए हुए volume को नहीं। दो volumes के बीच mirror बनाना ही वह समाधान है जो वास्तव में data को ठीक करता है।

क्या compression server को धीमा कर देता है?

lz4 आमतौर पर इसे तेज बनाता है। Compressed blocks का मतलब है कम bytes लिखना और कम bytes पढ़ना, और disk की बचत की तुलना में प्रति block CPU की लागत बहुत कम है। pool root पर compression=lz4 सेट करें ताकि हर dataset इसे inherit कर ले, फिर वास्तविक data लिखे जाने के बाद zfs get compressratio tank की जाँच करें।