FreeBSD आणि Linux वर ZFS साठी RAM व्यवस्थापन कसे करावे?
ZFS मध्ये ARC मुळे RAM चा मोठा हिस्सा वापरला जातो. कमी RAM असलेल्या VPS वर ZFS वापरताना मेमरीचे योग्य नियोजन कसे करावे आणि कोणत्या सेटिंग्ज बदलाव्यात याची सविस्तर माहिती.
ZFS तुम्हाला काय देते आणि काय घेते
FreeBSD आणि Linux वरील ZFS आता एकच कोडबेस आहे, ज्याला OpenZFS म्हणतात. त्यामुळे दोन्ही सिस्टिम्सवर याची वैशिष्ट्ये समान आहेत. ZFS चालवणाऱ्या सर्व्हरला चेकसम केलेले डेटा, डेटा बदलेपर्यंत विनामूल्य असणारे स्नॅपशॉट्स, zfs send सह रेप्लिकेशन आणि केवळ एका प्रॉपर्टीच्या अंतरावर असणारे कॉम्प्रेशन मिळते. यासाठी लागणारी गोष्ट म्हणजे मेमरी: ARC (adaptive replacement cache) डीफॉल्टनुसार RAM चा मोठा हिस्सा व्यापते. 2 GB किंवा 4 GB च्या VPS (virtual private server) वर ही मेमरी नेमकी तीच असते जी तुमच्या ॲप्लिकेशनला हवी असते.
हे मार्गदर्शक ZFS चे मूल्यमापन एका किंवा दोन व्हर्च्युअल डिस्क असलेल्या भाड्याच्या VPS च्या संदर्भात करते, चाळीस ड्राइव्ह बे असलेल्या स्टोरेज बॉक्सच्या संदर्भात नाही. या बदलामध्ये जी वैशिष्ट्ये टिकून राहतात, तीच तुमच्या वेळेसाठी योग्य आहेत. जी वैशिष्ट्ये टिकत नाहीत, ती पूल (pool) तयार करण्यापूर्वी जाणून घेणे आवश्यक आहे.
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 versionzfs version दोन ओळी प्रिंट करते, ज्यामध्ये userland आवृत्ती आणि कर्नल मॉड्यूल आवृत्ती असते. जर फक्त एकच ओळ दिसत असेल, तर याचा अर्थ मॉड्यूल लोड झालेले नाही. हे पॅकेज universe घटकामध्ये असते, जे Ubuntu सर्व्हर इमेजमध्ये डीफॉल्टनुसार सक्षम असते; जर apt ला ते सापडत नसेल, तर आधी sudo add-apt-repository universe चालवा.
Debian वर ही पॅकेजेस contrib घटकामध्ये असतात आणि मॉड्यूल DKMS (dynamic kernel module support) द्वारे तुमच्या मशीनवर बिल्ड केले जाते. Components: मधील /etc/apt/sources.list.d/debian.sources ओळीमध्ये contrib जोडा, 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आता पूल तयार करा. प्रथम स्थिर डिव्हाइस पाथ (stable device paths) तपासा, कारण /dev/vdb हे डिटेक्शन क्रमानुसार दिले जातात आणि तुम्ही दुसरे व्हॉल्यूम जोडल्यास ते बदलू शकतात.
ls -l /dev/disk/by-id/
sudo zpool create -o ashift=12 tank /dev/disk/by-id/virtio-abc123def456
zpool status tankzpool status ने state: ONLINE प्रिंट केले पाहिजे आणि तुमचे डिव्हाइस tank अंतर्गत दिसले पाहिजे. ashift=12 पूलमधील सर्वात लहान ब्लॉक 4 KiB वर निश्चित करते, जे सध्याच्या SSDs शी जुळते आणि एकदा तयार केल्यानंतर ते बदलता येत नाही.
बहुतेक भाड्याने घेतलेल्या इमेजेस ext4 रूटवरून बूट होतात, त्यामुळे येथे ZFS हे रूट फाइलसिस्टमऐवजी दुसऱ्या व्हॉल्यूमवरील डेटा पूल म्हणून वापरले जाते. त्यावर काम सुरू करण्यापूर्वी डिव्हाइस तेच आहे याची खात्री करा, कारण तुम्हाला मिळालेल्या NVMe डिस्कची खात्री करणे एक मिनिटाचे काम आहे, तर पुन्हा बिल्ड करायला संपूर्ण दुपार लागू शकते.
केवळ रिडंडन्सी (redundancy) असलेल्या पूलमध्येच चेकसम दुरुस्ती करू शकतात
ZFS द्वारे लिहिलेल्या प्रत्येक ब्लॉकसोबत एक चेकसम असतो आणि प्रत्येक वाचनाच्या वेळी त्याची पडताळणी केली जाते. त्रुटी शोधण्याचे काम नेहमीच होते, परंतु दुरुस्तीसाठी दुसरी प्रत (copy) आवश्यक असते.
सिंगल-डिस्क पूलमध्ये, 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/DISK2VPS वर, होस्ट स्टोरेज सहसा आधीच रिडंडंट असते, अनेकदा ते हायपरवायझरच्या खाली 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 सारख्या ओळीने संपतो. हे एका वेळापत्रकानुसार चालवा; लहान पूलसाठी दरमहा एकदा करणे पुरेसे आहे.
systemctl list-unit-files 'zfs-scrub*'
sudo systemctl enable --now zfs-scrub-monthly@tank.timerडेटासेट हे धोरणांचे (policy) एकक आहेत
डेटासेट म्हणजे पूल (pool) मधील एक फाइलसिस्टम असते. डेटासेट तयार करणे सोपे असल्याने, प्रत्येक कामासाठी एक स्वतंत्र डेटासेट तयार करा. गुणधर्म (properties) पूलपासून खाली वारशाने मिळतात, याचा अर्थ तुम्ही एकदा डीफॉल्ट सेट करून जिथे गरज असेल तिथे ते बदलू शकता. FreeBSD वर जेल (jails) सहसा अशाच प्रकारे चालवले जातात; प्रत्येक जेलसाठी एक डेटासेट असतो, जेणेकरून एका जेलचा स्नॅपशॉट घेऊन तो स्वतंत्रपणे रोलबॅक करता येतो. हेच जेल आणि Docker कंटेनर यांच्यातील मुख्य फरक आहे.
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 वापरला जातो, परंतु यामुळे डिस्कवर लिहिली जाणारी बाइट्सची संख्या कमी होते. त्यामुळे, कॉम्प्रेशिबल डेटावर हे वाचन (read) आणि लेखन (write) प्रक्रिया जलद करते. zstd अधिक CPU वापरून डेटा अधिक घट्ट कॉम्प्रैस करते, जे लॉग्स आणि दुर्मिळपणे वाचल्या जाणाऱ्या अर्काइव्हसाठी योग्य आहे. zfs get compressratio tank वापरून तुम्हाला नक्की किती फायदा मिळत आहे ते तपासा. लक्षात ठेवा की, गुणधर्म सेट केल्यानंतर लिहिलेल्या डेटावरच हे प्रमाण (ratio) मोजले जाते.
recordsize हे डेटासेटद्वारे लिहिले जाणारे सर्वात मोठे ब्लॉक आहे, जे डीफॉल्टनुसार 128K असते. जर एखादा डेटाबेस 8 KiB पेजेस 128 KiB रेकॉर्ड्समध्ये लिहित असेल, तर एका लहान लेखनासाठी संपूर्ण रेकॉर्ड वाचणे, त्यात बदल करणे आणि पुन्हा लिहिणे अशा प्रक्रिया कराव्या लागतात. डेटा लोड करण्यापूर्वी डेटाबेस डेटासेटवर recordsize=16K सेट करा, कारण हा गुणधर्म फक्त नवीन लिहिलेल्या ब्लॉक्सना लागू होतो.
quota वापरून तुम्ही एका डेटासेटला संपूर्ण पूल भरण्यापासून रोखू शकता. ZFS पूल 100% भरल्यास तो संथ होतो आणि साफ करणे कठीण जाते, त्यामुळे मुद्दाम काही जागा रिकामी ठेवा.
डेटा बदलेपर्यंत ZFS स्नॅपशॉट्ससाठी कोणतीही जागा लागत नाही
ZFS कधीही लाइव्ह ब्लॉक ओव्हरराईट करत नाही. ते एक नवीन ब्लॉक लिहिते आणि पॉइंटर्स अपडेट करते, ज्याला 'कॉपी-ऑन-राईट' (copy-on-write) म्हणतात. स्नॅपशॉट म्हणजे एक नोंद असते जी सांगते की "या डेटासेटचे पॉइंटर्स सध्या ज्या ब्लॉक्सकडे निर्देश करत आहेत, ते जतन करा", त्यामुळे स्नॅपशॉट घेणे त्वरित आणि विनामूल्य असते.
sudo zfs snapshot tank/data@2026-08-11
zfs list -t snapshot -o name,used,refer -r tank/dataस्नॅपशॉटसाठी 'USED' कॉलममध्ये दिसणारी जागा म्हणजे केवळ त्या स्नॅपशॉटने व्यापलेली जागा. सुरुवातीला ती शून्याच्या जवळ असते आणि जसा तुम्ही डेटा बदलता किंवा हटवता तशी ती वाढत जाते, कारण जुने ब्लॉक्स मुक्त करता येत नाहीत.
फाइल परत मिळवण्यासाठी कोणत्याही 'रिस्टोर' (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 चालवत नाही. गरज पडण्यापूर्वीच स्नॅपशॉट घ्या, कारण स्नॅपशॉट नसल्यास एखादी चुकीची rm -rf कमांड तुम्हाला ext4 रिकव्हरी पाथ वर घेऊन जाते, ज्याची सुरुवात डिस्क अनमाउंट करण्यापासून होते आणि त्यानंतर परिस्थिती अधिक कठीण होत जाते.
रोलबॅक (rollback) केल्यास स्नॅपशॉट घेतल्यापासून लिहिलेला सर्व डेटा नष्ट होतो.
sudo zfs rollback tank/data@2026-08-11जर नवीन स्नॅपशॉट्स अस्तित्वात असतील तर रोलबॅक नाकारला जातो आणि पुढे जाण्यासाठी -r त्या नवीन स्नॅपशॉट्सना नष्ट करते. एंटर दाबण्यापूर्वी डेटासेटचे नाव दोनदा तपासा.
स्नॅपशॉट म्हणजे बॅकअप नाही. तो त्याच पूलमध्ये, त्याच व्हॉल्यूमवर आणि त्याच सर्व्हरवर असतो. व्हॉल्यूम निकामी झाल्यास किंवा zpool destroy झाल्यास डेटासोबत स्नॅपशॉट्सही नष्ट होतात. स्नॅपशॉट्स तुम्हाला तुमच्या स्वतःच्या rm चुकांपासून आणि चुकीच्या अपग्रेडपासून वाचवतात, जे अनेक वास्तविक घटनांमध्ये उपयुक्त ठरते, परंतु पूलला स्वतःला काही झाल्यास स्नॅपशॉट्स कशापासूनही संरक्षण देऊ शकत नाहीत. याबद्दलची सविस्तर माहिती येथे दिली आहे: VPS स्नॅपशॉट बॅकअप का नसतो.
डेटा पाठवणे आणि मिळवणे: एका कमांडमध्ये रेप्लिकेशन
zfs send स्नॅपशॉटला स्टँडर्ड आउटपुटवर बाइट स्ट्रीममध्ये रूपांतरित करते आणि zfs receive त्या स्ट्रीमला पुन्हा डेटासेटमध्ये रूपांतरित करते. पहिली कॉपी ही पूर्ण 'फुल सेंड' असते.
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 एररसह थांबते, कारण ZFS कडे फरक लागू करण्यासाठी कोणताही बेस नसतो. दोन्ही बाजूंना उपलब्ध असलेल्या स्नॅपशॉटवरून डेटा पाठवा किंवा पुन्हा 'फुल सेंड' ने सुरुवात करा.
रिमोट 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 पेज कॅशेऐवजी कर्नल मेमरीमध्ये राहतो, म्हणून 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 चालवा.
The data behind this chart
[
{
"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.3 च्या नियमांतर्गत 2 GB चा इन्स्टन्स अजूनही 1.25 GiB ला अनुमती देतो. उरलेली मेमरी तुमच्या ॲप्लिकेशनला मिळते.
टेबलवर विश्वास ठेवण्याऐवजी तुमच्या स्वतःच्या सर्व्हरवरील प्रत्यक्ष आकडे तपासा:
grep -E '^(size|c_max) ' /proc/spl/kstat/zfs/arcstats
arc_summary | head -n 20तिसरा कॉलम बाइट्समध्ये आहे. c_max ही सध्या लागू असलेली कमाल मर्यादा आहे आणि size मध्ये सध्या ARC ने व्यापलेली मेमरी आहे.
ARC मेमरी परत करते. कर्नल मेमरीवरील ताण (pressure) दर्शवतो आणि ARC आकुंचन पावतो. समस्या वेळेची असते, कारण हे आकुंचन त्या ताणामुळेच घडते. त्यामुळे, एखादी प्रक्रिया एकाच वेळी शेकडो MiB मेमरी मागत असेल, तर ARC मेमरी मोकळी करण्याच्या प्रक्रियेत असतानाच ती OOM (out of memory) किलरचा बळी ठरू शकते. डेटाबेस आणि वेब सर्व्हर चालवणाऱ्या 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 -uinitramfs ची पायरी महत्त्वाची आहे, कारण रूट फाइलसिस्टम माउंट होण्यापूर्वीच मॉड्यूल initramfs मधून लोड होऊ शकते. अशा वेळी तुम्ही तयार केलेली फाइल वाचली जाणार नाही. रीबूट केल्यानंतर, c_max ओळीद्वारे arcstats तपासून खात्री करा.
मॅन्युअलनुसार दोन महत्त्वाच्या गोष्टी लक्षात ठेवा. सिस्टम चालू असताना तुम्ही ही व्हॅल्यू पुन्हा 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 असेल आणि वर्कलोडला पूर्ण मेमरीची गरज असेल.
- एकच व्हर्च्युअल डिस्क असेल आणि दुसरी प्रत नसेल, तर ZFS तुम्हाला त्रुटी शोधून देईल पण दुरुस्त करू शकणार नाही.
- तुमचे बॅकअप लक्ष्य ऑब्जेक्ट स्टोरेज किंवा साधे Linux होस्ट असेल, जिथे
zfs sendस्ट्रीम स्वीकारण्याची क्षमता नसेल. - तुम्ही DKMS सह Debian वापरत असाल आणि कर्नल अपग्रेडनंतर मॉड्यूल बिल्ड न होणे तुम्हाला परवडणारे नसेल.
- तुम्हाला रूट फाइलसिस्टमवर ZFS हवे असेल, परंतु प्रोव्हायडरच्या इमेजेस फक्त ext4 ला सपोर्ट करत असतील.
तुमच्याकडे स्वतंत्र डेटा व्हॉल्यूम असेल, पुरेशी RAM (8 GB किंवा त्याहून अधिक) उपलब्ध असेल आणि तुम्ही फक्त स्नॅपशॉट्स सक्षम करण्याऐवजी त्यांचा आणि zfs send चा प्रभावी वापर करण्याचे नियोजन केले असेल, तरच ZFS वापरा. इतर सर्व परिस्थितींसाठी, ext4 सह restic वापरून एन्क्रिप्टेड आणि डीडुप्लिकेटेड बॅकअप सर्व्हरच्या नियंत्रणाबाहेरील स्टोरेजवर घेणे अधिक सोयीचे ठरते, ज्यासाठी मेमरीचा अतिरिक्त वापरही होत नाही.
अपयशाचे प्रकार आणि दिसणारे संदेश
रीबूटनंतर पूल (pool) उपलब्ध नसणे. 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 वापरून तो ओव्हरराइड करता येतो.
कर्नेल अपग्रेडनंतर Debian वर modprobe: FATAL: Module zfs not found in directory /lib/modules/6.12.0-.... नवीन कर्नेलसाठी 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 ती फाईल शोधून देते आणि तुम्हाला ती या पूलमध्ये नसलेल्या बॅकअपमधून रिस्टोर करावी लागते.
सर्व्हर धीमा आहे आणि स्वॅपिंग (swapping) करत आहे. वर सांगितल्याप्रमाणे 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 सेट केल्यास तुम्हाला ती दुसरी प्रत मिळते, ज्यासाठी दुप्पट जागा लागते. हे खराब ब्लॉक हाताळू शकते, परंतु पूर्ण व्हॉल्यूम गहाळ झाल्यास ते मदत करत नाही. दोन व्हॉल्यूमवर मिरर (mirror) तयार करणे हाच खरा उपाय आहे जो डेटा दुरुस्त करू शकतो.
कॉम्प्रेशनमुळे सर्व्हरचा वेग कमी होतो का?
lz4 मुळे सहसा वेग वाढतो. कॉम्प्रेश्ड ब्लॉक्सचा अर्थ असा की कमी बाइट्स लिहावे आणि वाचावे लागतात. डिस्कवर होणाऱ्या बचतीच्या तुलनेत प्रति ब्लॉक लागणारा CPU खर्च खूपच कमी असतो. पूलच्या रूटवर compression=lz4 सेट करा जेणेकरून प्रत्येक डेटासेटला ते आपोआप लागू होईल, आणि प्रत्यक्ष डेटा लिहिल्यानंतर zfs get compressratio tank तपासा.