FreeBSD और Linux पर ZFS के लिए RAM की आवश्यकता

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

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

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

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

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

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

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

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

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

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

zfs version दो लाइनें print करता है: userland version और kernel module version। यदि केवल एक लाइन दिखती है, तो इसका मतलब है कि 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 किया जाता है। Components: लाइन में contrib को /etc/apt/sources.list.d/debian.sources के भीतर जोड़ें, sudo apt update चलाएँ, और फिर:

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

इंस्टॉलेशन module को compile करता है और Building initial module for 6.12.0-... print करता है, जिसमें कुछ मिनट लगते हैं। याद रखें कि इसका क्या अर्थ है: हर 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 के आधार पर दिए जाते हैं और कोई अन्य 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 print करना चाहिए, जिसमें आपकी device tank के अंतर्गत सूचीबद्ध हो। ashift=12 pool के सबसे छोटे block को 4 KiB पर सेट करता है, जो आधुनिक SSDs के अनुकूल है और इसे creation के बाद बदला नहीं जा सकता।

अधिकांश रेंट पर ली गई images ext4 root से boot होती हैं, इसलिए यहाँ ZFS root filesystem के बजाय दूसरी volume पर एक data pool के रूप में होता है। उस पर काम शुरू करने से पहले सुनिश्चित करें कि device वही है जो आप सोच रहे हैं, क्योंकि आपको बेची गई NVMe disk की पुष्टि करना एक मिनट का काम है, जबकि 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 कर देते हैं। FreeBSD पर jails आमतौर पर इसी तरह चलाई जाती हैं, प्रत्येक jail के लिए एक dataset, ताकि एक single jail का snapshot लिया जा सके और उसे स्वतंत्र रूप से roll back किया जा सके, जो कि 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 का उपयोग होता है और यह उन bytes को कम करता है जिन्हें disk तक पहुँचना होता है, इसलिए compressible data पर यह आमतौर पर reads और writes को तेज़ बनाता है। zstd अधिक CPU के बदले बेहतर compression देता है, जो उन logs और archives के लिए उपयुक्त है जिन्हें आप शायद ही कभी पढ़ते हैं। zfs get compressratio tank के साथ जाँचें कि आपको वास्तव में क्या मिल रहा है, और याद रखें कि ratio केवल उस data की गणना करता है जिसे property सेट करने के बाद लिखा गया है।

recordsize वह सबसे बड़ा block है जिसे एक dataset लिखता है, जो default रूप से 128K होता है। 8 KiB pages को 128 KiB records में लिखने वाला 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 column वह space है जिसे केवल उस snapshot ने रोक रखा है। यह शून्य के करीब शुरू होता है और जैसे-जैसे आप डेटा बदलते या हटाते हैं, यह बढ़ता जाता है, क्योंकि पुराने blocks को अब मुक्त नहीं किया जा सकता है।

किसी 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 box जो लगभग भरा हुआ दिखता है, वह आमतौर पर एक warm cache वाला box होता है, और "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 आकारों पर लागू होने वाले दस्तावेजी डिफ़ॉल्ट नियम हैं, न कि किसी चल रहे box से लिए गए माप। 4 GB के instance पर 2.3 नियम 3 GiB के ARC की अनुमति देता है। 2.2 पर वही box 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 के box पर, यह कोई दुर्लभ घटना नहीं है। OpenZFS manual मैन्युअल परिवर्तनों के बारे में भी यही कहता है: सीमा को कम करने से "memory pressure के बिना ARC को सिकुड़ने के लिए प्रेरित नहीं किया जा सकेगा"।

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

सबसे पहले workload की memory तय करें। database और application की कुल आवश्यकता को जोड़ें, operating system के लिए कुछ margin रखें, और बची हुई memory ARC को दें। 4 GB के instance पर, जो Postgres और एक web application चला रहा हो, 512 MiB से 1 GiB का ARC एक उचित शुरुआती बिंदु है।

इसे bytes में live सेट करें। यह 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 वाला चरण महत्वपूर्ण है क्योंकि module root filesystem mount होने से पहले initramfs से load हो सकता है, जिसका अर्थ है कि यह आपके द्वारा बनाई गई file को कभी नहीं पढ़ेगा। Reboot के बाद, arcstats से c_max line के साथ पुष्टि करें।

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

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

छोटे server के लिए memory के दो और नियम। Deduplication को बंद रखें, क्योंकि dedup table memory में रहती है और सामान्य नियम यह है कि प्रति TB unique data के लिए 1 से 3 GB RAM की आवश्यकता होती है। और swap को zvol (pool से बना block device) पर न रखें, क्योंकि जो filesystem memory खाली करने की कोशिश कर रहा है, उसी के माध्यम से swap करने पर machine deadlock हो सकती है। Swap को pool के बाहर एक साधारण partition या swap file पर रखें।

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

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

• instance में 2 GB या 4 GB RAM हो और workload को पूरी RAM की आवश्यकता हो।
• केवल एक virtual disk हो और कोई दूसरी copy न हो, जिससे ZFS आपको repair के बिना केवल detection की सुविधा देता है।
• आपका backup target object storage या कोई साधारण Linux host हो, जहाँ कोई भी चीज़ zfs send stream को receive न कर सके।
• आप DKMS के साथ Debian चला रहे हों और आप ऐसे kernel upgrade का जोखिम न उठा सकें जिसमें module build न हो पाए।
• आपको root filesystem पर ZFS की आवश्यकता हो और provider की images केवल ext4 प्रदान करती हों।

ZFS का उपयोग तब जारी रखें जब आपके पास अलग data volume हो, अतिरिक्त RAM हो (8 GB और उससे अधिक आरामदायक है), और आपके पास ऐसी योजना हो जो snapshots और zfs send का सक्रिय उपयोग करती हो। बाकी सभी स्थितियों के लिए, ext4 के साथ restic का उपयोग करके ऐसे storage पर encrypted और deduplicated backups रखना, जिसे सर्वर नियंत्रित नहीं करता, बिना किसी अतिरिक्त मेमोरी खपत के लगभग वही सुरक्षा प्रदान करता है।

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

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) कर देता है।

modprobe: FATAL: Module zfs not found in directory /lib/modules/6.12.0-... Debian पर kernel upgrade के बाद। DKMS नए kernel के लिए 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 से नष्ट करें और space वापस मिल जाएगा।

zpool status में CKSUM की संख्या बढ़ रही है। ZFS के नीचे किसी स्तर पर गलत data प्राप्त हुआ है। Mirror setup में यह संख्या केवल एक चेतावनी है और block को ठीक कर लिया गया है। Single-disk pool पर वह file खो जाती है, zpool status -v उसका नाम बताता है, और आपको उस file को ऐसे backup से restore करना होगा जो इस pool में न हो।

Server धीमा है और swapping कर रहा है। ऊपर बताए अनुसार ARC की सीमा तय करें, फिर arc_summary चलाएं और hit ratio देखें। यदि ARC इतना छोटा है कि working set को नहीं संभाल पा रहा, तो हर read operation 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 में 3 GiB तक cache के लिए दिया जा सकता है। 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 पर लिखता हो जिसे यह सर्वर नियंत्रित नहीं करता है।

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

OpenZFS 2.0 (दिसंबर 2020) के बाद से 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 दुगुनी जगह पर मिल जाती है, जो एक bad block को तो संभाल सकती है लेकिन lost volume को नहीं। दो volumes के बीच mirror बनाना ही वह समाधान है जो वास्तव में data को ठीक करता है।

क्या compression सर्वर को धीमा करता है?

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