ניהול זיכרון ב-ZFS על שרת VPS: מדריך מעשי

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

ZFS ב-FreeBSD וב-Linux מבוססת כעת על בסיס קוד אחד, OpenZFS, ולכן התכונות זהות בשתי המערכות. שרת המריץ ZFS מקבל נתונים עם checksum, snapshots שאינם צורכים משאבים עד לשינוי הנתונים, שכפול (replication) באמצעות zfs send, ודחיסה שניתן להפעיל באמצעות הגדרת מאפיין בודד. המחיר הוא זיכרון: ה-ARC (‏adaptive replacement cache) תופס כברירת מחדל חלק גדול מה-RAM, ובשרת VPS (‏virtual private server) עם 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 (Common Development and Distribution License). ליבת ה-Linux מופצת תחת רישיון GPL (General Public License) גרסה 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 (תמיכה דינמית במודולי kernel). הוסיפו את 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 שלכם במצב לא מיובא עד לתיקון התקלה.

ב-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 כאן משמש כ-data 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, האחסון של המארח (host) הוא בדרך כלל בעל יתירות, לרוב באמצעות RAID 10 ברמת ה-hypervisor. הגנה זו מסייעת במקרה של כשל בדיסק פיזי, אך היא אינה מתריעה כאשר בלוק חוזר עם נתונים שגויים, כיוון שלמערך אין דרך לדעת איזה עותק הוא הנכון. ZFS יודע זאת, כיוון שהוא משווה את הנתונים מול ה-checksum שהוא עצמו יצר.

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

פעולת 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 כלפי מטה, מה שאומר שניתן להגדיר ברירת מחדל פעם אחת ולבצע דריסה (override) רק היכן שזה נדרש. ב-FreeBSD כך נהוג להריץ jails, כאשר לכל jail יש Dataset משלו. כך ניתן לבצע snapshot ולבצע שחזור (rollback) ל-jail בודד באופן עצמאי, וזהו חלק מ-מה שמבדיל בין 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) היא מאפיין שאנשים נמנעים ממנו מתוך זהירות, וזו גישה שגויה. lz4 דורש כמות קטנה של CPU ומפחית את מספר הבתים שצריכים להגיע לדיסק, לכן בנתונים הניתנים לדחיסה הוא בדרך כלל מאיץ פעולות קריאה וכתיבה. zstd דוחס בצורה אגרסיבית יותר על חשבון צריכת CPU גבוהה יותר, מה שמתאים ללוגים ולארכיונים שקוראים לעיתים רחוקות. בדקו מה אתם מקבלים בפועל באמצעות zfs get compressratio tank, וזכרו שיחס הדחיסה מחושב רק עבור נתונים שנכתבו לאחר הגדרת המאפיין.

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

quota הוא הדרך שלכם למנוע מ-Dataset בודד למלא את ה-pool. ZFS pool שמתקרב ל-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, ובאותו שרת. כשל בנפח האחסון או 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 שממנו אתם שולחים. כאשר הוא אינו מחזיק בו, תהליך הקבלה נעצר עם 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) הוא מטמון הקריאה של ZFS. הוא שוכן בזיכרון ה-kernel ולא ב-page cache הרגיל של Linux, ולכן free -h לא מדווח עליו תחת buff/cache. הוא מופיע כזיכרון בשימוש. שרת ZFS שנראה כמעט מלא הוא לרוב שרת עם מטמון "חם", וזהו המקור לרוב הדיווחים על כך ש-"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
  }
]

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

ודאו שההגדרה נשמרת לאחר אתחול.

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 רגיל, שאינם מסוגלים לקלוט זרם zfs send.
• אתם מריצים Debian עם DKMS ואינכם יכולים להרשות לעצמכם שדרוג ליבה שמותיר את המודול ללא הידור.
• אתם זקוקים ל-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 לגדול לגודל המקסימלי מבין השניים: הזיכרון פחות 1 GiB או 5/8 מהזיכרון הכולל. לכן, שרת עם 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 תעניק לכם עותק שני כזה במחיר של כפל שטח אחסון, מה שיאפשר התמודדות עם בלוק פגום אך לא עם אובדן נפח אחסון. פתרון ה-mirror על פני שני כוננים הוא הדרך היחידה לתיקון עצמי של המידע.

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

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