FreeBSD आणि Linux वर ZFS वापरताना RAM चे नियोजन

ZFS तुम्हाला काय देते आणि काय घेते

FreeBSD आणि Linux वरील ZFS आता एकच कोडबेस आहे, ज्याला OpenZFS म्हणतात, त्यामुळे दोन्ही सिस्टिम्सवर याची वैशिष्ट्ये समान आहेत. ZFS चालवणाऱ्या सर्व्हरला डेटाचे चेकसमिंग, डेटा बदलेपर्यंत मोफत असणारे स्नॅपशॉट्स, zfs send सह रेप्लिकेशन आणि एका प्रॉपर्टीच्या अंतरावर असणारे कॉम्प्रेशन मिळते. या बदल्यात ZFS मेमरी घेते: ARC (adaptive replacement cache) डीफॉल्टनुसार RAM चा मोठा हिस्सा व्यापतो आणि 2 GB किंवा 4 GB च्या VPS (virtual private server) वर तीच मेमरी तुमच्या ॲप्लिकेशनला हवी असते.

हे मार्गदर्शक ZFS चे मूल्यमापन एका किंवा दोन व्हर्च्युअल डिस्क असलेल्या भाड्याच्या VPS च्या संदर्भात करते, चाळीस ड्राइव्ह बे असलेल्या स्टोरेज बॉक्सच्या संदर्भात नाही. या बदलामध्ये जी वैशिष्ट्ये टिकून राहतात, तीच तुमच्या वेळेसाठी योग्य आहेत. जी वैशिष्ट्ये टिकत नाहीत, ती पूल तयार करण्यापूर्वी जाणून घेणे आवश्यक आहे.

FreeBSD आणि Linux वर OpenZFS: एकच कोडबेस, दोन पॅकेजिंग पद्धती

FreeBSD मध्ये 2008 पासून, FreeBSD 7.0 आवृत्तीपासून ZFS बेस सिस्टमचा भाग आहे, सुरुवातीला ते प्रायोगिक वैशिष्ट्य म्हणून होते. डिसेंबर 2020 मधील OpenZFS 2.0 पासून, FreeBSD आणि Linux दोन्ही एकाच सोर्स ट्रीवरून बिल्ड होतात, त्यामुळे zfs आणि zpool दोन्ही प्लॅटफॉर्मवर सारख्याच प्रकारे काम करतात आणि एकावर तयार केलेला पूल दुसऱ्यावर सहजपणे इम्पोर्ट करता येतो.

Linux वर ZFS हे एक पॅकेज आहे आणि FreeBSD वर ते बेस सिस्टमचा भाग आहे, याचे मुख्य कारण लायसन्सिंग हे आहे. OpenZFS हे CDDL (common development and distribution license) अंतर्गत येते. Linux कर्नल हे GPL (general public license) आवृत्ती 2 अंतर्गत येते. कर्नल प्रकल्प या दोन्ही लायसन्सना विसंगत मानतो, त्यामुळे ZFS कोड मुख्य Linux कर्नलमध्ये विलीन केला जात नाही आणि प्रत्येक डिस्ट्रिब्युशन ते कसे वितरित करायचे हे स्वतः ठरवते. FreeBSD मध्ये असा कोणताही संघर्ष नाही, त्यामुळे ZFS तिथे थेट उपलब्ध असते. हीच यामागची संपूर्ण व्यावहारिक गोष्ट आहे: पॅकेजिंगमधील हा एक फरक आहे आणि तुम्हाला यापैकी कोणतीही एक बाजू घेण्याची गरज नाही.

SSD Nodes वर FreeBSD इमेजेस उपलब्ध नाहीत, त्यामुळे येथे भाड्याने घेतलेल्या सर्व्हरवर या मार्गदर्शिकेतील Linux संबंधित भाग लागू होतो. जर तुम्ही इतर कुठे FreeBSD चालवत असाल, तर a FreeBSD server वर ZFS कोणत्याही मॉड्यूल बिल्डशिवाय किंवा कर्नल अपग्रेडच्या त्रासाशिवाय थेट मिळते.

ZFS इन्स्टॉल करा आणि पूल तयार करा

Ubuntu वर हे मॉड्युल कर्नल पॅकेजमध्येच समाविष्ट असते, त्यामुळे तुम्हाला फक्त कमांड्स इन्स्टॉल कराव्या लागतात.

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

zfs version दोन ओळी प्रिंट करते, एक युजरलँड व्हर्जन आणि दुसरी कर्नल मॉड्युल व्हर्जन. जर फक्त एकच ओळ दिसत असेल, तर याचा अर्थ मॉड्युल लोड झालेले नाही. हे पॅकेज universe कंपोनंटमध्ये असते, जे Ubuntu सर्व्हर इमेजमध्ये डीफॉल्टनुसार सुरू असते; जर apt ला ते सापडत नसेल, तर आधी sudo add-apt-repository universe रन करा.

Debian वर ही पॅकेजेस contrib कंपोनंटमध्ये असतात आणि मॉड्युल DKMS (dynamic kernel module support) द्वारे तुमच्या मशीनवर बिल्ड केले जाते. contrib ला /etc/apt/sources.list.d/debian.sources मधील Components: ओळीत जोडा, sudo apt update रन करा आणि त्यानंतर:

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

इन्स्टॉलेशन दरम्यान मॉड्युल कंपाईल होते आणि Building initial module for 6.12.0-... प्रिंट होते, ज्याला काही मिनिटे लागतात. हे लक्षात ठेवा: प्रत्येक कर्नल अपग्रेडनंतर ते पुन्हा बिल्ड होते आणि जर बिल्ड अयशस्वी झाले, तर तुम्ही ते दुरुस्त करेपर्यंत तुमचा पूल इम्पोर्ट होणार नाही.

FreeBSD वर काहीही इन्स्टॉल करण्याची गरज नाही. फक्त सर्व्हिस इनेबल करा आणि सुरू करा.

sysrc zfs_enable=YES
service zfs start

आता पूल तयार करा. सर्वप्रथम स्टेबल डिव्हाइस पाथ तपासा, कारण /dev/vdb हे डिटेक्शनच्या क्रमानुसार दिले जातात आणि दुसरे व्हॉल्यूम जोडल्यावर ते बदलू शकतात.

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 प्रिंट केले पाहिजे आणि तुमचे डिव्हाइस tank अंतर्गत दिसले पाहिजे. ashift=12 पूलमधील सर्वात लहान ब्लॉक 4 KiB वर सेट करते, जे सध्याच्या SSDs शी जुळते आणि एकदा तयार केल्यावर ते बदलता येत नाही.

बहुतेक रेंटेड इमेजेस ext4 रूटवरून बूट होतात, त्यामुळे येथे ZFS हे रूट फाइलसिस्टम नसून दुसऱ्या व्हॉल्यूमवरील डेटा पूल आहे. त्यावर काम सुरू करण्यापूर्वी डिव्हाइस तेच आहे का याची खात्री करा, कारण तुम्हाला मिळालेल्या NVMe डिस्कची खात्री करणे एक मिनिटाचे काम आहे, तर पुन्हा बिल्ड करायला संपूर्ण दुपार लागू शकते.

चेकसम फक्त तेव्हाच दुरुस्त होतात जेव्हा पूलमध्ये रिडंडन्सी असते

ZFS प्रत्येक ब्लॉक लिहिताना एक चेकसम तयार करते आणि प्रत्येक वाचनाच्या वेळी त्याची पडताळणी करते. त्रुटी शोधण्याचे काम नेहमीच होते, परंतु दुरुस्तीसाठी दुसरी प्रत आवश्यक असते.

सिंगल-डिस्क पूलमध्ये, 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

येथे खराब फाईलचे नाव दिले जाते. ext4 सारखी फाईल सिस्टिम कोणतीही सूचना न देता चुकीचे बाइट्स परत करते, त्यामुळे ZFS ची ही पद्धत अधिक सुरक्षित आहे. तरीही, ZFS ती फाईल दुरुस्त करू शकत नाही, कारण पूलमध्ये दुरुस्तीसाठी दुसरी प्रत उपलब्ध नसते.

मिरर (mirror) सेटअपमध्ये, तीच माहिती चांगल्या डिस्कवरून वाचली जाते, खराब ब्लॉक पुन्हा लिहिला जातो आणि zpool status च्या CKSUM कॉलममध्ये ही घटना नोंदवली जाते. याला 'सेल्फ-हिलिंग' म्हणतात आणि यासाठी दोन उपकरणांची (devices) गरज असते.

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

VPS वर होस्ट स्टोरेज सहसा आधीच रिडंडंट असते, अनेकदा हायपरव्हायझरच्या खाली RAID 10 वापरले जाते. हे तुम्हाला डिस्क निकामी होण्यापासून वाचवते. परंतु, एखादा ब्लॉक चुकीच्या पद्धतीने वाचला गेला तर ते तुम्हाला सांगू शकत नाही, कारण ॲरेला कोणती प्रत बरोबर आहे हे माहित नसते. ZFS ला हे माहित असते, कारण ते स्वतः लिहिलेल्या चेकसमशी डेटाची तुलना करते.

जर तुमच्याकडे एकच व्हर्च्युअल डिस्क असेल आणि तुम्हाला काही प्रमाणात दुरुस्तीची क्षमता हवी असेल, तर sudo zfs set copies=2 tank/important वापरून तुम्ही त्या डेटासेटच्या प्रत्येक ब्लॉकच्या दोन प्रती त्याच डिस्कवर साठवू शकता. यामुळे डेटासेटची जागा दुप्पट लागते, खराब ब्लॉकपासून संरक्षण मिळते, परंतु संपूर्ण व्हॉल्यूम निकामी झाल्यास याचा काहीही उपयोग होत नाही.

स्क्रब (scrub) प्रक्रिया पूल मधील सर्व डेटा वाचते आणि त्याची पडताळणी करते.

sudo zpool scrub tank
zpool status tank

एक निरोगी पूल scan: scrub repaired 0B in 00:04:11 with 0 errors सारख्या ओळीने संपतो. हे काम वेळापत्रकानुसार (schedule) करा; लहान पूलसाठी दरमहा एकदा करणे पुरेसे आहे.

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

डेटासेट हे धोरणांचे एकक आहेत

डेटासेट म्हणजे पूलच्या आतील एक फाइलसिस्टम असते. डेटासेट तयार करणे सोपे असल्याने, प्रत्येक कामासाठी एक स्वतंत्र डेटासेट तयार करा. गुणधर्म (properties) पूलपासून खालील स्तरांकडे वारशाने मिळतात, याचा अर्थ असा की तुम्ही एकदाच डीफॉल्ट सेट करून आवश्यक तिथे ते बदलू शकता.

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) हा असा गुणधर्म आहे जो लोक सावधगिरी म्हणून वापरत नाहीत, परंतु ही पद्धत चुकीची आहे. lz4 साठी थोड्या प्रमाणात CPU वापरला जातो, परंतु यामुळे डिस्कवर लिहिण्यासाठी लागणाऱ्या बाइट्सची संख्या कमी होते. त्यामुळे, कॉम्प्रेशन शक्य असलेल्या डेटासाठी हे वाचन (reads) आणि लेखन (writes) वेगवान करते. zstd अधिक CPU वापरून डेटा अधिक घट्ट कॉम्प्रैस करते, जे लॉग्स आणि क्वचितच वाचल्या जाणाऱ्या अर्काइव्हसाठी योग्य ठरते. zfs get compressratio tank वापरून तुम्हाला प्रत्यक्ष किती फायदा मिळत आहे ते तपासा. लक्षात ठेवा की हे गुणोत्तर (ratio) केवळ गुणधर्म सेट केल्यानंतर लिहिलेल्या डेटासाठीच मोजले जाते.

recordsize हे डेटासेटद्वारे लिहिलेले सर्वात मोठे ब्लॉक असते, जे डीफॉल्टनुसार 128K असते. जर एखादा डेटाबेस 128 KiB रेकॉर्डमध्ये 8 KiB पेजेस लिहित असेल, तर एक लहान लेखन प्रक्रिया संपूर्ण रेकॉर्ड वाचणे, त्यात बदल करणे आणि पुन्हा लिहिणे अशा चक्रात अडकते. डेटा लोड करण्यापूर्वी डेटाबेस डेटासेटवर recordsize=16K सेट करा, कारण हा गुणधर्म केवळ नवीन लिहिलेल्या ब्लॉक्सना लागू होतो.

quota वापरून तुम्ही एका डेटासेटला संपूर्ण पूल भरण्यापासून रोखू शकता. ZFS पूल 100% भरल्यास तो संथ होतो आणि त्यातील डेटा साफ करणे कठीण होते, म्हणून मुद्दाम काही जागा रिकामी ठेवा.

डेटा बदलेपर्यंत Snapshots साठी कोणताही खर्च येत नाही

ZFS कधीही लाइव्ह ब्लॉक ओव्हरराईट करत नाही. ते एक नवीन ब्लॉक लिहिते आणि पॉइंटर्स अपडेट करते, ज्याला copy-on-write असे म्हणतात. Snapshot म्हणजे "या डेटासेटचे पॉइंटर्स सध्या ज्या ब्लॉक्सकडे निर्देश करत आहेत, ते जतन करा" अशी एक नोंद असते, त्यामुळे ते घेणे त्वरित आणि विनामूल्य असते.

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

Snapshot साठीचा USED कॉलम म्हणजे केवळ त्या Snapshot द्वारे व्यापलेली जागा. हे प्रमाण शून्याच्या जवळ सुरू होते आणि जसजसा तुम्ही डेटा बदलता किंवा हटवता तसतसे ते वाढत जाते, कारण जुने ब्लॉक्स आता मुक्त केले जाऊ शकत नाहीत.

फाइल परत मिळवण्यासाठी कोणत्याही restore प्रक्रियेची गरज नसते.

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

.zfs डिरेक्टरी ls -a पासून देखील लपलेली असते, जोपर्यंत तुम्ही sudo zfs set snapdir=visible tank/data चालवत नाही. तुम्हाला गरज पडण्यापूर्वीच Snapshot घ्या, कारण त्याशिवाय एक चुकीची rm -rf कमांड तुम्हाला ext4 रिकव्हरी पाथ वर घेऊन जाते, ज्याची सुरुवात डिस्क अनमाउंट करण्यापासून होते आणि त्यानंतर परिस्थिती अधिक कठीण होत जाते.

Rollback केल्यास Snapshot नंतर लिहिलेली सर्व माहिती नष्ट होते.

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

जेव्हा नवीन Snapshots अस्तित्वात असतात तेव्हा ते Rollback नाकारते आणि -r त्या नवीन Snapshots ना नष्ट करून पुढे जाते. एंटर दाबण्यापूर्वी डेटासेटचे नाव दोनदा तपासा.

Snapshot म्हणजे बॅकअप नाही. ते त्याच पूलमध्ये, त्याच व्हॉल्यूमवर आणि त्याच सर्व्हरवर असते. व्हॉल्यूम निकामी झाल्यास किंवा zpool destroy झाल्यास डेटासोबत Snapshots देखील नष्ट होतात. Snapshots तुम्हाला तुमच्या स्वतःच्या rm चुकांपासून आणि चुकीच्या अपग्रेडपासून वाचवतात, जे अनेक वास्तविक घटनांमध्ये उपयुक्त ठरते, परंतु पूलला स्वतःला काही झाल्यास ते कशापासूनही संरक्षण देऊ शकत नाहीत. याचे सविस्तर स्पष्टीकरण येथे दिले आहे: VPS snapshot बॅकअप का नसतो.

पाठवणे आणि प्राप्त करणे: एका कमांडमध्ये रेप्लिकेशन

zfs send स्नॅपशॉटला स्टँडर्ड आउटपुटवर बाइट स्ट्रीममध्ये रूपांतरित करते आणि zfs receive त्या स्ट्रीमला पुन्हा डेटासेटमध्ये रूपांतरित करते. पहिली कॉपी ही पूर्ण '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"

त्यानंतर, फक्त दोन स्नॅपशॉटमधील बदललेले भाग पाठवा.

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"

प्राप्त करणाऱ्या बाजूकडे तुम्ही ज्या स्नॅपशॉटवरून डेटा पाठवत आहात, तो असणे आवश्यक आहे. जेव्हा तो नसतो, तेव्हा cannot receive incremental stream: most recent snapshot of backup/data does not match incremental source मुळे 'receive' प्रक्रिया थांबते, कारण ZFS कडे फरक लागू करण्यासाठी कोणताही आधार (base) नसतो. दोन्ही बाजूंनी सामायिक असलेल्या स्नॅपशॉटवरून डेटा पाठवा किंवा पुन्हा पूर्ण 'send' ने सुरुवात करा.

रिमोट root वापरण्याऐवजी टार्गेटवर अधिकार प्रदान करा: sudo zfs allow -u backupuser create,mount,receive backup/data.

ही एक वास्तविक ऑफ-साइट बॅकअप पद्धत आहे, परंतु एक अट आहे. दूरच्या बाजूला ZFS पूल असणे आवश्यक आहे, कारण ऑब्जेक्ट स्टोरेज स्ट्रीम प्राप्त करू शकत नाही. जेव्हा तुमचे टार्गेट S3-सुसंगत स्टोरेज किंवा सामान्य Linux होस्ट असते, तेव्हा त्याशी संवाद साधू शकणाऱ्या टूलचा वापर करा आणि restic backups from a VPS मध्ये तो मार्ग स्पष्ट केला आहे.

ZFS इतकी RAM का वापरते? ARC बद्दल माहिती

ARC (adaptive replacement cache) हा ZFS चा रीड कॅशे आहे. तो सामान्य Linux page cache ऐवजी कर्नल मेमरीमध्ये राहतो, म्हणून free -h त्याला buff/cache अंतर्गत दाखवत नाही. तो वापरली जाणारी मेमरी म्हणून दिसतो. एखादा ZFS सर्व्हर पूर्ण भरलेला वाटत असेल, तर त्याचा अर्थ सहसा असा असतो की त्याचा कॅशे 'वॉर्म' (warm) आहे आणि "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
  }
]

हे आकडे सामान्य इन्स्टन्स साईजसाठी लागू होणारे प्रमाणित डीफॉल्ट नियम आहेत, चालू असलेल्या सर्व्हरची प्रत्यक्ष मोजमापे नाहीत. 4 GB च्या इन्स्टन्सवर 2.3 चा नियम 3 GiB चा ARC अनुमती देतो. त्याच सर्व्हरवर 2.2 आवृत्ती 2 GiB वर थांबते. 2 GB च्या इन्स्टन्सवर 2.3 च्या नियमानुसार अजूनही 1.25 GiB ची अनुमती मिळते. उरलेली मेमरी तुमच्या ॲप्लिकेशनला मिळते.

तक्त्यावर विश्वास ठेवण्याऐवजी तुमच्या स्वतःच्या सर्व्हरवरील प्रत्यक्ष आकडे तपासा:

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

तिसरा कॉलम बाईट्समध्ये आहे. c_max ही सध्या लागू असलेली कमाल मर्यादा आहे आणि size मध्ये सध्या ARC ने व्यापलेली मेमरी आहे.

ARC मेमरी परत करतो. जेव्हा कर्नल मेमरीवर ताण असल्याचे संकेत देते, तेव्हा ARC आकुंचन पावतो. समस्या वेळेची असते, कारण हे आकुंचन त्या ताणामुळेच घडते. त्यामुळे, एखादी प्रक्रिया एकाच वेळी शेकडो MiB मेमरीची मागणी करत असेल, तर ARC मेमरी मोकळी करण्याच्या प्रक्रियेत असतानाच ती प्रक्रिया OOM (out of memory) killer द्वारे बंद केली जाऊ शकते. डेटाबेस आणि वेब सर्व्हर चालवणाऱ्या 2 GB च्या सर्व्हरवर ही घटना दुर्मिळ नाही. OpenZFS मॅन्युअलमध्ये मॅन्युअल बदलांबद्दल असेच म्हटले आहे: मर्यादा कमी केल्याने "मेमरीचा ताण निर्माण झाल्याशिवाय ARC आपोआप आकुंचन पावणार नाही".

लहान VPS वर ARC ची मर्यादा कशी निश्चित करावी

प्रथम वर्कलोडसाठी लागणारी मेमरी ठरवा. डेटाबेस आणि ॲप्लिकेशनला किती मेमरी लागेल याची बेरीज करा, ऑपरेटिंग सिस्टमसाठी काही जागा राखून ठेवा आणि उरलेली मेमरी ARC ला द्या. Postgres आणि एक वेब ॲप्लिकेशन चालवणाऱ्या 4 GB च्या इन्स्टन्सवर, 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 टेबल मेमरीमध्ये राहते आणि सामान्य नियमानुसार दर 1 TB युनिक डेटासाठी 1 ते 3 GB RAM लागते. तसेच, swap ला zvol (पूलमधून तयार केलेले ब्लॉक डिव्हाइस) वर ठेवू नका, कारण मेमरी मोकळी करण्याचा प्रयत्न करणाऱ्या फाइलसिस्टमद्वारे स्वॅपिंग केल्यास मशीन डेडलॉक होऊ शकते. स्वॅपिंगसाठी साधे पार्टिशन किंवा पूलच्या बाहेरील स्वॅप फाइल वापरा.

जेव्हा ext4 किंवा XFS आणि restic हा अधिक चांगला पर्याय असतो

जेव्हा सर्व्हरवर अतिरिक्त मेमरी आणि दुसरे व्हॉल्यूम उपलब्ध असते, तेव्हाच ZFS चा वापर सार्थ ठरतो. याव्यतिरिक्त, साधे फाइलसिस्टम आणि एक सक्षम बॅकअप टूल वापरणे अधिक फायदेशीर ठरते. खालील परिस्थितीत ext4 किंवा XFS निवडा:

• इन्स्टन्समध्ये 2 GB किंवा 4 GB RAM असेल आणि सर्व वर्कलोडसाठी ती पूर्णपणे आवश्यक असेल.
• एकच व्हर्च्युअल डिस्क असेल आणि दुसरी प्रत (copy) नसेल, तर ZFS तुम्हाला त्रुटी शोधून देईल पण दुरुस्त करू शकणार नाही.
• तुमचे बॅकअप टार्गेट ऑब्जेक्ट स्टोरेज किंवा साधे Linux होस्ट असेल, जिथे zfs send स्ट्रीम स्वीकारण्याची क्षमता नसेल.
• तुम्ही DKMS सह Debian वापरत असाल आणि कर्नल अपग्रेडनंतर मॉड्यूल बिल्ड न होण्याचा धोका पत्करायचा नसेल.
• तुम्हाला रूट फाइलसिस्टमवर ZFS हवे असेल, परंतु प्रोव्हायडरच्या इमेजमध्ये फक्त ext4 उपलब्ध असेल.

जेव्हा तुमच्याकडे स्वतंत्र डेटा व्हॉल्यूम, पुरेशी RAM (8 GB किंवा त्यापेक्षा जास्त सोयीस्कर असते) आणि केवळ स्नॅपशॉट्स सक्षम करण्याऐवजी त्यांचा आणि zfs send चा वापर करण्याची योजना असेल, तेव्हाच ZFS ठेवा. इतर सर्व परिस्थितींसाठी, ext4 सह restic वापरून सर्व्हरच्या नियंत्रणाबाहेरील स्टोरेजवर एनक्रिप्टेड आणि डीडुप्लिकेटेड बॅकअप घेणे अधिक सोयीचे ठरते, ज्यासाठी मेमरीचा अतिरिक्त वापर होत नाही.

अपयशाचे प्रकार आणि दिसणारे संदेश

रीबूटनंतर पूल उपलब्ध नसणे. zpool status कमांड no pools available आउटपुट देते. इम्पोर्ट सर्व्हिस /etc/zfs/zpool.cache फाईल वाचते, त्यामुळे त्या फाईलमध्ये नसलेला पूल बूट वेळी कधीही इम्पोर्ट होत नाही. sudo zpool import कमांड काय इम्पोर्ट करता येईल याची यादी देते, sudo zpool import tank तो पुन्हा सक्रिय करते आणि sudo zpool set cachefile=/etc/zfs/zpool.cache tank तो कायमस्वरूपी सेट करते. दुसऱ्या सिस्टमवरून व्यवस्थित एक्सपोर्ट न केलेला पूल cannot import 'tank': pool may be in use from other system असा एरर देतो, आणि इतर कोणत्याही होस्टकडे तो नाही याची खात्री झाल्यावर sudo zpool import -f tank वापरून तो ओव्हरराइड करता येतो.

modprobe: FATAL: Module zfs not found in directory /lib/modules/6.12.0-... कर्नल अपग्रेडनंतर Debian वर दिसतो. नवीन कर्नलसाठी DKMS बिल्ड झालेला नसतो, याचे मुख्य कारण म्हणजे संबंधित headers इन्स्टॉल नसणे. dkms status कमांड कोणत्या कर्नलसाठी काय बिल्ड झाले आहे ते दाखवते. sudo apt install -y linux-headers-$(uname -r) आणि त्यानंतर sudo dkms autoinstall वापरून तो पुन्हा बिल्ड करा आणि sudo zpool import tank ने पूल पुन्हा सक्रिय करा.

पूल पूर्ण भरलेला आहे पण तुम्ही फाईल्स डिलीट केल्या आहेत. जोपर्यंत स्नॅपशॉटमध्ये डेटाचा संदर्भ असतो तोपर्यंत डिलीट केलेला डेटा डिस्कवरच राहतो, त्यामुळे du आणि df च्या आकडेवारीत तफावत दिसते. zfs list -o space -r tank वापरून वापराचे विभाजन USEDDS आणि USEDSNAP मध्ये करा; जर USEDSNAP जास्त असेल तर तेच याचे उत्तर आहे. जुने स्नॅपशॉट sudo zfs destroy tank/data@2026-06-01 ने नष्ट करा, म्हणजे जागा मोकळी होईल.

zpool status मध्ये CKSUM ची संख्या वाढत आहे. ZFS च्या खालील स्तरावरून चुकीचा डेटा मिळत आहे. मिरर सेटअपमध्ये ही संख्या एक इशारा आहे आणि ब्लॉक दुरुस्त केला गेला आहे. सिंगल-डिस्क पूलमध्ये फाईल गमावली जाते, zpool status -v तिचे नाव सांगते, आणि तुम्हाला ती फाईल अशा बॅकअपमधून रिस्टोर करावी लागेल जो या पूलमध्ये नाही.

सर्व्हर धीमा आहे आणि स्वॅपिंग करत आहे. वर सांगितल्याप्रमाणे ARC ची मर्यादा निश्चित करा, त्यानंतर arc_summary चालवा आणि हिट रेशो तपासा. जर ARC वर्किंग सेट साठवण्यासाठी खूप लहान असेल, तर प्रत्येक रीड डिस्कवर जातो. अशा वेळी पेज कॅशे वापरणारी साधी फाईलसिस्टम अधिक चांगली कामगिरी करेल.

FAQ

VPS वर ZFS साठी किती RAM आवश्यक असते?

ZFS 2 GB च्या इन्स्टन्सवर चालू शकते. खरा प्रश्न हा आहे की तुमच्या ॲप्लिकेशनसाठी किती मेमरी शिल्लक राहते. कोणत्याही ट्युनिंगशिवाय, OpenZFS 2.3 मध्ये ARC ची मर्यादा (RAM वजा 1 GiB) किंवा (RAM च्या 5/8 पट) यापैकी जी मोठी असेल ती ठरते. त्यामुळे 4 GB च्या सर्व्हरवर 3 GiB मेमरी कॅशेसाठी वापरली जाऊ शकते. zfs_arc_max ला तुमच्या वर्कलोडनुसार उपलब्ध असलेल्या मेमरीच्या मर्यादेत सेट करा आणि त्यानंतर /proc/spl/kstat/zfs/arcstats मधील c_max ओळ वाचून त्याची खात्री करा.

ZFS स्नॅपशॉट म्हणजे बॅकअप आहे का?

नाही. स्नॅपशॉट हा डेटा असलेल्या त्याच पूलमध्ये असतो. तो एखादा खराब rm किंवा अपयशी ठरलेल्या अपग्रेडमधून वाचू शकतो, परंतु पूल किंवा इन्स्टन्स नष्ट झाल्यास तोही नष्ट होतो. त्याला बॅकअपमध्ये रूपांतरित करण्यासाठी zfs send वापरून तो दुसऱ्या मशीनवर पाठवा किंवा अशा स्टोरेजवर बॅकअप घेणारे टूल वापरा ज्यावर या सर्व्हरचे नियंत्रण नाही.

ZFS हे FreeBSD आणि Linux वर सारखेच काम करते का?

डिसेंबर 2020 मधील OpenZFS 2.0 पासून दोन्हीकडे कोडबेस, कमांड्स आणि ऑन-डिस्क फॉरमॅट समान आहेत, त्यामुळे पूल एका सिस्टमवरून दुसऱ्या सिस्टमवर हलवता येतात. फरक फक्त पॅकेजिंगचा आहे. FreeBSD मध्ये ZFS हे बेस सिस्टमचा भाग असते. Linux वर प्रत्येक डिस्ट्रिब्युशन स्वतःचा निर्णय घेते: Ubuntu कर्नल पॅकेजमध्येच मॉड्यूल समाविष्ट करते, तर Debian ते तुमच्या मशीनवर DKMS द्वारे बिल्ड करते. त्यामुळे कर्नल अपग्रेडनंतर जोपर्यंत रीबिल्ड यशस्वी होत नाही, तोपर्यंत तुम्हाला मॉड्यूल उपलब्ध नसेल.

एकाच डिस्क असलेल्या VPS वर ZFS करप्शन दुरुस्त करू शकते का?

ZFS करप्शन शोधून फाइलचे नाव सांगू शकते, पण ते दुरुस्त करू शकत नाही, कारण दुरुस्तीसाठी ब्लॉकची दुसरी प्रत आवश्यक असते. डेटासेटवर zfs set copies=2 सेट केल्यास तुम्हाला दुप्पट जागेत दुसरी प्रत मिळते, जी खराब ब्लॉक हाताळू शकते, परंतु पूर्ण व्हॉल्यूम गहाळ झाल्यास ती मदत करत नाही. दोन व्हॉल्यूम्समध्ये मिरर तयार करणे हाच खरा उपाय आहे जो डेटा दुरुस्त करू शकतो.

कॉम्प्रेशनमुळे सर्व्हरचा वेग कमी होतो का?

lz4 मुळे सहसा वेग वाढतो. कॉम्प्रेश्ड ब्लॉक्सचा अर्थ असा की कमी बाइट्स लिहावे आणि वाचावे लागतात. डिस्कवर होणाऱ्या बचतीच्या तुलनेत प्रति ब्लॉक लागणारा CPU खर्च नगण्य असतो. पूलच्या रूटवर compression=lz4 सेट करा जेणेकरून प्रत्येक डेटासेटला तो लागू होईल, आणि एकदा प्रत्यक्ष डेटा लिहिला गेल्यावर zfs get compressratio tank तपासा.