ניהול זיכרון ב-ZFS: אופטימיזציה לשרתי VPS עם RAM מוגבל

מה ZFS מעניק לכם, ומה הוא דורש

ZFS ב-FreeBSD וב-Linux מבוסס כעת על בסיס קוד מאוחד, OpenZFS, ולכן התכונות זהות בשתי המערכות. שרת המריץ ZFS מקבל נתונים עם checksum, snapshots שאינם צורכים משאבים עד לשינוי הנתונים, שכפול (replication) באמצעות zfs send, ודחיסה שניתן להפעיל באמצעות הגדרת מאפיין בודד. המחיר הוא זיכרון: ה-ARC (או Adaptive Replacement Cache) תופס כברירת מחדל נתח גדול מה-RAM, ובשרת VPS (שרת וירטואלי פרטי) עם 2 GB או 4 GB של זיכרון, זה בדיוק הזיכרון שהיישום שלכם היה זקוק לו.

מדריך זה בוחן את ZFS מנקודת מבט של VPS מושכר עם דיסק וירטואלי אחד או שניים, ולא מנקודת מבט של שרת אחסון עם ארבעים מפרצי כוננים. התכונות ששורדות את המעבר הזה הן אלו שראויות להשקעת הזמן שלכם. את החלקים שאינם שורדים את המעבר כדאי להכיר לפני שאתם בונים pool.

OpenZFS ב-FreeBSD וב-Linux: בסיס קוד אחד, שתי שיטות הפצה

מערכת FreeBSD כוללת את ZFS כחלק ממערכת הבסיס מאז גרסה 7.0 בשנת 2008, בתחילה כתכונה ניסיונית. מאז השקת OpenZFS 2.0 בדצמבר 2020, FreeBSD ו-Linux נבנות מאותו עץ מקור, ולכן zfs ו-zpool מתנהגות באופן זהה בשתי המערכות, ו-pool שנוצר באחת ניתן לייבוא בשנייה.

הסיבה לכך ש-ZFS היא חבילה ב-Linux אך חלק ממערכת הבסיס ב-FreeBSD היא רישוי. OpenZFS מופצת תחת רישיון CDDL (רישיון פיתוח והפצה משותף). ליבת Linux מופצת תחת רישיון GPL (רישיון ציבורי כללי) גרסה 2. פרויקט הליבה מתייחס לשני הרישיונות כבלתי תואמים, ולכן קוד ZFS אינו ממוזג לתוך ה-mainline של Linux, וכל הפצה מחליטה כיצד לספק אותו. ל-FreeBSD אין קונפליקט כזה, ולכן ZFS פשוט זמינה שם. זהו כל הסיפור המעשי: הבדל אחד בשיטת האריזה, ואין צורך לנקוט עמדה בנושא.

SSD Nodes אינה מציעה תמונות (images) של FreeBSD, לכן בשרת המושכר כאן, החלק של Linux במדריך זה הוא הרלוונטי. אם אתם מריצים FreeBSD במקום אחר, שרת FreeBSD מקבל את ZFS ללא צורך בבניית מודול וללא צורך בהתמודדות עם שדרוגי ליבה.

התקנת ZFS ויצירת pool

ב-Ubuntu המודול כלול בחבילות ה-kernel, לכן יש להתקין רק את כלי הניהול.

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

הפקודה zfs version מדפיסה שתי שורות: גרסת ה-userland וגרסת מודול ה-kernel. שורה אחת בלבד מעידה על כך שהמודול לא נטען. החבילה נמצאת ברכיב universe, שמופעל כברירת מחדל בתמונות Ubuntu server; אם apt לא מוצא אותה, יש להריץ תחילה את sudo add-apt-repository universe.

ב-Debian החבילות נמצאות ברכיב contrib והמודול נבנה על המכונה שלכם באמצעות DKMS (ראשי תיבות של dynamic kernel module support). הוסיפו את contrib לשורת ה-Components: בקובץ /etc/apt/sources.list.d/debian.sources, הריצו את sudo apt update, ולאחר מכן:

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

תהליך ההתקנה מקמפל את המודול ומדפיס Building initial module for 6.12.0-..., פעולה שנמשכת מספר דקות. זכרו את המשמעות: כל שדרוג kernel יבצע בנייה מחדש, ובנייה שנכשלת תשאיר את ה-pool שלכם במצב לא מיובא (unimported) עד לתיקון.

ב-FreeBSD אין צורך בהתקנה. יש להפעיל את השירות ולהתחיל אותו.

sysrc zfs_enable=YES
service zfs start

כעת, ה-pool. בדקו תחילה את נתיבי ההתקן הקבועים, כיוון ש-/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 מקבע את גודל הבלוק הקטן ביותר של ה-pool על 4 KiB, מה שמתאים לכונני SSD מודרניים ולא ניתן לשינוי לאחר היצירה.

רוב התמונות המוצעות להשכרה עולות ממחיצת root מסוג ext4, לכן ZFS במקרה זה משמש כ-pool נתונים על כונן שני ולא כמערכת קבצים ראשית. ודאו שההתקן הוא אכן מה שחשבתם לפני שאתם בונים עליו, כיוון ש-אימות כונן ה-NVMe שקיבלתם לוקח דקה אחת, בעוד בנייה מחדש עלולה לקחת אחר צהריים שלם.

בדיקות תקינות (Checksums) מתקנות נתונים רק כאשר ב-pool קיימת יתירות

כל בלוק ש-ZFS כותב נושא עמו checksum, וכל פעולת קריאה מאמתת אותו. זיהוי שגיאות עובד תמיד. תיקון דורש עותק שני.

ב-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

שם הקובץ הפגום יופיע. מערכת קבצים מסוג ext4 הייתה מחזירה את הבתים השגויים ללא התראה, כך שזהו כבר יתרון משמעותי. ZFS עדיין לא יכול לתקן את השגיאה, כיוון שאין ב-pool עותק נוסף שממנו ניתן לשחזר את המידע.

במערך mirror, אותה קריאה תתבצע מהצד התקין, הבלוק הפגום ייכתב מחדש, והאירוע יופיע בעמודה CKSUM של הפקודה zpool status. זהו תהליך של תיקון עצמי (self-healing), והוא מחייב שני התקנים.

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

בשרת VPS, האחסון של המארח לרוב כבר כולל יתירות, לעיתים קרובות באמצעות RAID 10 ברמת ה-hypervisor. זה מגן עליכם מפני כשל של כונן פיזי. עם זאת, המערכת לא תתריע כאשר בלוק חוזר עם נתונים שגויים, כיוון שלמערך אין דרך לדעת איזה עותק הוא הנכון. ZFS יודע זאת, כיוון שהוא משווה את הנתונים מול checksum שהוא עצמו יצר.

אם יש לכם דיסק וירטואלי אחד ואתם מעוניינים ביכולת תיקון מסוימת, המאפיין sudo zfs set copies=2 tank/important שומר שני עותקים של כל בלוק באותו dataset על גבי אותו דיסק. פעולה זו מכפילה את נפח האחסון שה-dataset צורך, היא מאפשרת התאוששות מבלוק פגום, אך היא אינה מועילה כאשר הכרך כולו נעלם.

פעולת scrub קוראת את כל המידע ב-pool ומאמתת אותו.

sudo zpool scrub tank
zpool status tank

ב-pool תקין תופיע שורה כמו scan: scrub repaired 0B in 00:04:11 with 0 errors בסיום התהליך. הגדירו זאת בלוח זמנים; תדירות חודשית מספיקה עבור pool קטן.

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

Datasets הם יחידת המדיניות

Dataset הוא מערכת קבצים בתוך ה-pool, ויצירתו היא פעולה זולה, לכן מומלץ ליצור אחד לכל משימה. מאפיינים עוברים בירושה מה-pool כלפי מטה, מה שאומר שניתן להגדיר ברירת מחדל פעם אחת ולדרוס אותה רק היכן שנדרש.

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

דחיסה היא מאפיין שאנשים נמנעים ממנו מתוך זהירות, וזו טעות. lz4 צורך כמות קטנה של CPU ומפחית את כמות הבייטים שצריכים להגיע לדיסק, לכן בנתונים הניתנים לדחיסה הוא בדרך כלל מאיץ פעולות קריאה וכתיבה. zstd דוחס בצורה חזקה יותר תמורת יותר CPU, מה שמתאים ללוגים וארכיונים שקוראים לעיתים רחוקות. בדקו מה אתם מקבלים בפועל בעזרת zfs get compressratio tank, וזכרו שהיחס מתייחס רק לנתונים שנכתבו לאחר הגדרת המאפיין.

recordsize הוא גודל הבלוק הגדול ביותר ש-dataset כותב, 128K כברירת מחדל. מסד נתונים שכותב דפי 8 KiB לתוך רשומות של 128 KiB הופך כתיבה קטנה אחת לקריאה של כל הרשומה, שינוי, וכתיבה חזרה. הגדירו recordsize=16K ב-dataset של מסד הנתונים לפני טעינת הנתונים, כיוון שהמאפיין חל רק על בלוקים שנכתבים לאחר מכן.

quota הוא הדרך שלכם למנוע מ-dataset בודד למלא את ה-pool. מאגר ZFS שקרוב ל-100% תפוס הופך לאיטי וקשה לניקוי, לכן השאירו מרווח נשימה באופן מכוון.

צילומי מצב (Snapshots) אינם עולים דבר עד שנתונים משתנים

ZFS לעולם אינו דורס בלוק פעיל. הוא כותב בלוק חדש ומעדכן את המצביעים, וזהו העיקרון של Copy-on-Write. צילום מצב הוא רישום המורה ל־ZFS "לשמור את הבלוקים שאליהם הצביע מערך הנתונים ברגע זה", לכן יצירתו היא מיידית ואינה דורשת משאבים.

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

עמודת ה-USED עבור צילום מצב מייצגת את הנפח שתפוס אך ורק על ידי אותו צילום. הנפח מתחיל קרוב לאפס וגדל ככל שמשנים או מוחקים נתונים, כיוון שלא ניתן עוד לשחרר את הבלוקים הישנים.

שחזור קובץ אינו דורש תהליך שחזור מורכב.

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, שמתחיל בניתוק הכונן (unmount) ומסתבך משם.

פעולת Rollback מוחקת את כל מה שנכתב מאז צילום המצב.

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

הפעולה תיחסם אם קיימים צילומי מצב חדשים יותר, ושימוש ב--r ישמיד את צילומי המצב החדשים הללו כדי להמשיך. קראו את שם מערך הנתונים פעמיים לפני לחיצה על Enter.

צילום מצב אינו גיבוי. הוא נמצא באותו ה-pool, על אותו ה-volume, ובאותו השרת. כשל ב-volume או zpool destroy יגרמו לאובדן צילומי המצב יחד עם הנתונים. צילומי מצב מגנים עליכם מפני rm שלכם ומפני שדרוג כושל, מה שמכסה מקרים רבים במציאות, אך הם אינם מגנים מפני אירועים שפוגעים ב-pool עצמו. הטיעון המלא מפורט כאן: מדוע צילום מצב של VPS אינו גיבוי.

שליחה וקבלה: שכפול בפקודה אחת

zfs send הופך snapshot לזרם בתים (byte stream) בפלט הסטנדרטי, ו-zfs receive הופך את הזרם הזה בחזרה ל-dataset. ההעתקה הראשונה היא שליחה מלאה (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"

הצד המקבל חייב להחזיק ב-snapshot שממנו אתם שולחים. כאשר הוא אינו מחזיק בו, תהליך ה-receive נעצר עם cannot receive incremental stream: most recent snapshot of backup/data does not match incremental source, כיוון של-ZFS אין בסיס שעליו ניתן להחיל את ההפרשים. שלחו מ-snapshot שקיים בשני הצדדים, או התחילו מחדש עם שליחה מלאה.

העניקו הרשאות בצד היעד במקום להשתמש ב-root מרוחק: sudo zfs allow -u backupuser create,mount,receive backup/data.

זהו גיבוי off-site אמיתי בתנאי אחד. הצד המרוחק חייב להיות ZFS pool, כיוון ש-object storage אינו יכול לקבל זרם נתונים. כאשר היעד שלכם הוא אחסון תואם S3 או מארח Linux רגיל, השתמשו בכלי שתומך בכך, והמדריך גיבויי restic מ-VPS מכסה את הנתיב הזה.

מדוע ZFS צורך כל כך הרבה זיכרון RAM? ה־ARC

ה־ARC (ראשי תיבות של adaptive replacement cache) הוא ה־cache לקריאה של ZFS. הוא שוכן בזיכרון הליבה (kernel memory) ולא ב־page cache הרגיל של Linux, ולכן free -h לא מדווח עליו תחת buff/cache. הוא מופיע כזיכרון בשימוש. שרת ZFS שנראה כמעט מלא הוא בדרך כלל שרת עם cache "חם", וזה מסביר את רוב הדיווחים על כך ש־"ZFS אכל לי את ה־RAM".

מגבלת ברירת המחדל היא נדיבה במכוון. OpenZFS 2.3 מגדיר את הגודל המקסימלי של ה־ARC כגדול מבין השניים: סך ה־RAM פחות 1 GiB, או 5/8 מנפח ה־RAM. גרסאות OpenZFS 2.2 ומטה השתמשו בחצי מנפח ה־RAM ב־Linux, בעוד ש־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
  }
]

הנתונים הללו הם כלל ברירת המחדל המתועד עבור גדלי מופעים (instances) נפוצים, ולא מדידות משרת פעיל. במופע של 4 GB, הכלל של גרסה 2.3 מאפשר ARC בגודל של 3 GiB. אותו שרת בגרסה 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

העמודה השלישית מציינת בתים (bytes). c_max הוא התקרה התקפה כרגע, ו-size הוא הנפח שה־ARC תופס בפועל.

ה־ARC אכן מחזיר זיכרון. הליבה מאותתת על לחץ זיכרון וה־ARC מתכווץ. הבעיה היא עיתוי, כיוון שהכיווץ מונע על ידי אותו לחץ; לכן, תהליך שמבקש כמה מאות MiB בבת אחת עלול להיתקל ב־OOM (ראשי תיבות של out of memory) killer בזמן שה־ARC עדיין בתהליך שחרור. בשרת של 2 GB שמריץ מסד נתונים ושרת אינטרנט, זה אינו אירוע נדיר. המדריך של OpenZFS מציין את אותו הדבר לגבי שינויים ידניים: הנמכת המגבלה "לא תגרום ל־ARC להתכווץ ללא לחץ זיכרון שישרה את הכיווץ".

כיצד להגביל את ה-ARC בשרת VPS קטן

ראשית, החליטו מהו נפח הזיכרון הנדרש לעומס העבודה. סכמו את צריכת הזיכרון של מסד הנתונים ושל היישום, השאירו מרווח ביטחון למערכת ההפעלה, והקצו את היתרה ל-ARC. בשרת עם 4 GB זיכרון המריץ Postgres ויישום אינטרנט אחד, הקצאה של 512 MiB עד 1 GiB עבור ה-ARC היא נקודת התחלה סבירה.

הגדירו את הערך בזמן אמת, בבתים. דוגמה זו מגדירה 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) ממופה, מה שיגרום לכך שהקובץ שכתבתם לא ייקרא. לאחר האתחול, אשרו את השינוי באמצעות השורה c_max מתוך arcstats.

קיימות שתי הסתייגויות המופיעות במדריך הרשמי. לא ניתן להחזיר את הערך ל-0 בזמן שהמערכת פועלת, לכן ביטול ההגדרה מחייב עריכה של הקובץ וביצוע אתחול. כמו כן, הפחתת המספר לא תכווץ מיידית ARC שכבר תפס נפח גדול.

ב-FreeBSD, הגבלה זו מתבצעת באמצעות sysctl תחת vfs.zfs.arc. הריצו את sysctl vfs.zfs.arc כדי לראות את הערכים הנוכחיים ואת השם המדויק שבו משתמשת הגרסה שלכם, ולאחר מכן כתבו את הערך המקסימלי לתוך /boot/loader.conf.

שני כללי זיכרון נוספים עבור שרת קטן: השאירו את ה-deduplication כבוי, כיוון שטבלת ה-dedup מאוחסנת בזיכרון, והכלל המקובל הוא 1 עד 3 GB של RAM לכל TB של נתונים ייחודיים. בנוסף, אל תגדירו swap על גבי zvol (התקן בלוק שנוצר מתוך ה-pool), כיוון שביצוע swap דרך מערכת הקבצים שמנסה לפנות זיכרון עלול לגרום ל-deadlock במכונה. שמרו את ה-swap על מחיצה רגילה או על קובץ swap מחוץ ל-pool.

מתי ext4 או XFS בשילוב עם restic הם הפתרון העדיף

ZFS מצדיק את קיומו בשרת עם זיכרון פנוי וכונן נוסף. מעבר לכך, מערכת קבצים פשוטה בשילוב כלי גיבוי ייעודי היא הבחירה הנכונה. בחרו ב-ext4 או ב-XFS כאשר:

• לשרת יש 2 GB או 4 GB של RAM ועומס העבודה דורש את מלוא הזיכרון.
• קיים כונן וירטואלי יחיד ללא עותק נוסף, כך ש-ZFS מספק זיהוי שגיאות ללא יכולת תיקון.
• יעד הגיבוי שלכם הוא object storage או שרת Linux רגיל, שאינם מסוגלים לקבל stream מסוג zfs send.
• אתם מריצים Debian עם DKMS ואינכם יכולים להרשות לעצמכם שדרוג kernel שישאיר את המודול ללא הידור.
• אתם זקוקים ל-ZFS על מערכת הקבצים הראשית (root), אך תמונות המערכת של ספק הענן מציעות רק ext4.

השתמשו ב-ZFS רק כאשר יש לכם כונן נתונים נפרד, זיכרון RAM פנוי (8 GB ומעלה הם תצורה נוחה), ותוכנית עבודה המנצלת snapshots ו-zfs send באופן פעיל, ולא רק מפעילה אותם. לכל שאר המקרים, ext4 בשילוב restic המבצע גיבויים מוצפנים ומבוצע בהם deduplication ליעד אחסון שהשרת אינו מנהל ישירות, מספק מענה דומה ללא צריכת הזיכרון הגבוהה.

מצבי כשל והודעות שגיאה נפוצות

המאגר (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 מבטיח שהשינוי יישמר לאחר אתחול. מאגר שלא עבר ייצוא (export) תקין ממערכת אחרת ידווח על 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 יחזיר את המאגר לפעולה.

המאגר מלא למרות שמחקת קבצים. נתונים שנמחקו נשארים על הדיסק כל עוד snapshot כלשהו מפנה אליהם, ולכן du ו-df יציגו נתונים סותרים. zfs list -o space -r tank מפרק את השימוש ל-USEDDS ו-USEDSNAP, וערך גבוה ב-USEDSNAP הוא הגורם לבעיה. מחק את ה-snapshots הישנים באמצעות sudo zfs destroy tank/data@2026-06-01 והשטח יתפנה.

ערכי CKSUM עולים ב-zpool status. רכיב כלשהו מתחת ל-ZFS החזיר נתונים פגומים. במערך mirror, הערך מהווה אזהרה והבלוק תוקן. במאגר המבוסס על דיסק בודד, הקובץ אבד; zpool status -v יציג את שמו, ועליך לשחזר את הקובץ הספציפי מגיבוי שאינו נמצא במאגר זה.

השרת איטי ומבצע swapping. הגבל את ה-ARC כפי שהוסבר לעיל, ולאחר מכן הרץ את arc_summary ובדוק את יחס הפגיעות (hit ratio). אם ה-ARC קטן מכדי להכיל את סט הנתונים הפעיל, כל פעולת קריאה תופנה לדיסק; בנקודה זו, מערכת קבצים רגילה המשתמשת ב-page cache תהיה יעילה יותר.

FAQ

כמה זיכרון RAM דורש ZFS בשרת VPS?

ZFS פועל על מופע עם 2 GB זיכרון. השאלה האמיתית היא מה נותר עבור היישום שלכם. ללא כוונון, OpenZFS 2.3 מאפשר ל-ARC לגדול לערך הגבוה מבין (RAM פחות 1 GiB) או 5/8 מה-RAM, כך ששרת עם 4 GB יכול להקצות 3 GiB למטמון. הגדירו את zfs_arc_max למספר שעומס העבודה שלכם יכול להרשות לעצמו, ואז אשרו זאת על ידי קריאת השורה c_max מתוך /proc/spl/kstat/zfs/arcstats.

האם Snapshot של ZFS נחשב לגיבוי?

לא. Snapshot חי באותו ה-pool שבו נמצא המידע. הוא שורד rm פגום ושדרוג שנכשל, אך הוא אובד יחד עם ה-pool או המופע כולו. הפכו אותו לגיבוי על ידי שליחתו למכונה אחרת באמצעות zfs send, או על ידי הרצת כלי גיבוי הכותב לאחסון ששרת זה אינו מנהל.

האם ZFS עובד באותו אופן ב-FreeBSD וב-Linux?

מדובר באותו בסיס קוד מאז OpenZFS 2.0 בדצמבר 2020, אותן פקודות, אותו פורמט על הדיסק, וניתן להעביר pools ביניהם. ההבדל הוא באריזה. FreeBSD מספקת את ZFS כחלק ממערכת הבסיס. ב-Linux כל הפצה מחליטה בעצמה: Ubuntu בונה את המודול בתוך חבילות ה-kernel שלה, בעוד Debian בונה אותו על המכונה שלכם באמצעות DKMS, כך ששדרוג kernel עלול להשאיר אתכם ללא מודול עד להשלמת הבנייה מחדש.

האם ZFS יכול לתקן שחיתות נתונים ב-VPS עם דיסק אחד?

הוא מזהה את השחיתות ומציין את שם הקובץ, אך אינו יכול לתקן אותה, כיוון שתיקון דורש עותק שני של הבלוק. zfs set copies=2 על dataset מספק לכם עותק שני כזה במחיר של כפול שטח אחסון, מה שמאפשר טיפול בבלוק פגום אך לא באובדן כרך (volume). מראה (mirror) על פני שני כרכים הוא הפתרון שמבצע תיקון בפועל.

האם דחיסה מאטה את השרת?

lz4 בדרך כלל הופך אותו למהיר יותר. בלוקים דחוסים משמעותם פחות בתים לכתיבה ופחות בתים לקריאה, ועלות ה-CPU לכל בלוק זניחה לעומת החיסכון בדיסק. הגדירו את compression=lz4 בשורש ה-pool כך שכל dataset יירש זאת, ולאחר מכן בדקו את zfs get compressratio tank לאחר שנכתב מידע אמיתי.