מה חדש ב־Linux kernel 7.1 לשרתים

מה חדש ב־Linux kernel 7.1

Linux kernel 7.1 שוחרר ב־14 ביוני 2026, תשעה שבועות לאחר 7.0. עבור משתמשים ב־VPS (virtual private server), השינויים החשובים נמצאים בארבעה תחומים: אחסון ומערכות קבצים, רשתות, ניהול זיכרון, ובקרת תהליכים ומכולות. שאר השינויים בגרסה עוסקים בעיקר בסביבת שולחן העבודה ובגרפיקה, ששרת ללא ממשק גרפי אינו טוען.

תחילה נדרשת תשובה נוספת. כמעט בטוח ש־7.1 אינו פועל בשרת שלכם, והוא לא יופעל בו במשך זמן רב. kernel.org אינו מציין את 7.1 כגרסת longterm. נכון ל־11 באוגוסט 2026, קווי ה־longterm הם 6.18, 6.12, 6.6, 6.1, 5.15 ו־5.10, וכל הפצת שרת נפוצה מתבססת על אחד מהם או על קו שהיא מתחזקת בעצמה. יש פער של שנים בין "מה חדש ב־kernel" לבין "מה חדש בשרת שלכם", ולכן המדריך הזה מכסה את שני ההיבטים.

איזה kernel פועל כעת ב־VPS שלך

uname -r
uname -srm
systemd-detect-virt

uname -r מציג את גרסת ה־kernel שפועלת. ב־Ubuntu 24.04 היא נראית כך: 6.8.0-79-generic. החלק שלפני המקף הראשון הוא קו הפיתוח של upstream. כל מה שאחריו הוא מספר ה־build של ההפצה שלך, והוא אינו עוקב כלל אחר upstream. ה־6.8.0-79 של Canonical כולל אלפי תיקונים שהועברו לאחור מ־kernelים מאוחרים יותר, ולכן הוא אינו הקוד ש־Linus סימן כ־6.8 במרץ 2024. לכן האמירה "ה־kernel שלי ישן" מספקת פחות מידע מכפי שנדמה. התכונות ישנות. תיקוני האבטחה בדרך כלל אינם ישנים.

systemd-detect-virt מציין אם בכלל ניתן לשנות את ה־kernel. הוא מציג kvm במכונה וירטואלית מלאה, שבה אתחול מתבצע מתמונת ה־kernel שלך ושדרוג הוא אכן שדרוג. הוא מציג lxc או openvz בווירטואליזציה מבוססת מכולות, שבה ה־kernel של ה־host משותף. בתוכנית מבוססת מכולות, uname -r מציג את ה־kernel של הספק. התקנת חבילת kernel אינה משנה דבר שניתן לאתחל ממנו, ושום תכונה בגרסה זו לא תהיה זמינה לך עד שהספק יאתחל את ה־host עם kernel חדש יותר. הרץ את הבדיקה הזו לפני תכנון כל פעולה הקשורה ל־kernel.

[
  {
    "distro": "Ubuntu 26.04 LTS (7.0)",
    "releases_behind_7_1": 1,
    "notes": "GA kernel, shipped with the April 2026 release"
  },
  {
    "distro": "Ubuntu 24.04 LTS, HWE (6.17)",
    "releases_behind_7_1": 4,
    "notes": "6.17 came with 24.04.4; 7.0 is rolling out ahead of 24.04.5 on 27 August 2026"
  },
  {
    "distro": "Debian 13 trixie (6.12)",
    "releases_behind_7_1": 9,
    "notes": "upstream longterm line, kernel.org projected EOL December 2028"
  },
  {
    "distro": "RHEL 10 and its rebuilds (6.12)",
    "releases_behind_7_1": 9,
    "notes": "Red Hat backports fixes into its own frozen 6.12 stream"
  },
  {
    "distro": "Ubuntu 24.04 LTS, GA (6.8)",
    "releases_behind_7_1": 13,
    "notes": "the default unless you install the HWE stack"
  },
  {
    "distro": "Ubuntu 22.04 LTS, GA (5.15)",
    "releases_behind_7_1": 26,
    "notes": "upstream longterm line, kernel.org projected EOL December 2026"
  }
]

מדובר ב־6 פלטפורמות, ואף אחת מהן אינה מאתחלת עם 7.1. החדשה ביותר היא Ubuntu 26.04 LTS (7.0), שנמצאת 1 גרסאות upstream מאחור. הוותיקה ביותר שעדיין נתמכת נמצאת 26 גרסאות מאחור. ברירת המחדל של kernel ה־GA ב־Ubuntu 24.04 נמצאת 13 גרסאות מאחור, ואילו Debian 13 ו־RHEL 10 נמצאות 9 גרסאות מאחור, על קו ה־6.12 longterm. ספירת גרסאות היא מדד גס, משום שהיא מתעלמת מכל מה שההפצות מעבירות לאחור, אך היא ממחישה את מבנה הפער. אם אתה שוקל באיזו מהן להשתמש, הפשרה בין LTS לגרסת interim בשרת היא ההחלטה שעומדת בבסיס המספרים האלה.

אחסון ומערכות קבצים ב־7.1

7.1 מוסיפה את היכולת ליצור ולאמת T10 PI (מידע הגנה) בתוך מערכת הקבצים, ולא רק בשכבת הבלוקים, וכן תמיכה גמישה ביישור T10. T10 PI הוא מספר בתים נוסף המצורף לכל בלוק. הוא כולל checksum ותג שמזהה לאיזה בלוק שייכים הנתונים, כך שכתיבה שהופנתה לבלוק שגוי או כתיבה חלקית מזוהה במקום להימסר כנתונים תקינים. עבור לקוח VPS, המגבלה היא החומרה. על ההתקן לחשוף מטא־נתונים של שלמות, ודיסק וירטואלי בדרך כלל אינו חושף אותם.

ls /sys/block/vda/integrity/

ברוב דיסקי ה־VPS מתקבלת התוצאה No such file or directory, משום ששכבת הבלוקים יוצרת את הספרייה integrity רק כאשר ההתקן רושם תמיכה בשלמות. זו התשובה הצפויה במקרה הזה, ולא תקלה. אם ברצונכם לדעת מהו סוג הדיסק שלכם לפני שתמשיכו לקרוא על יכולות אחסון, התחילו ב־בדיקה אם דיסק ה־VPS הוא למעשה NVMe, וההבדל בין NVMe לבין SSD מסוג SATA ב־VPS מסביר מדוע התוצאה משנה את המספרים שלכם.

Btrfs מקבלת תיקונים לצמצום הגברת copy-on-write תחת לחץ זיכרון, וכן שינוי שמאיץ את ניקוי ה־extent הראשון בטווח שנמצא במעקב. במיזוג מצוין שיפור של 10% בתפוקה בעומס העבודה שנבדק. פעולת הכיבוי שלה כבר אינה מסומנת כניסיונית. XFS משפרת את ריקון ה־zero range ואת החיפוש באמצעות iomap, ומוסיפה מצביע כתיבה לגאומטריה של קבוצות real-time, כהכנה להתקנים מחולקים לאזורים. NTFS היא כתיבה מחדש מלאה במהדורה זו, עם תמיכה מלאה בכתיבה והסבה ל־iomap. הדבר חשוב אם תעלו אי־פעם בשרת שלכם image של דיסק ממחשב Windows.

כמה פריטי אחסון קטנים יותר שכדאי להכיר: ublk, מנהל התקן הבלוקים במרחב המשתמש, קיבל קלט/פלט ללא העתקה; io_uring קיבל פקודות passthrough ל־SCSI; התמיכה בכוננים מוצפנים עצמאית מסוג SED-OPAL קיבלה את הפקודה STACK_RESET ואת מצב המשתמש היחיד המורחב; נוסף מנהל התקן תווים חדש מסוג fs-dax להתקני גישה ישירה; ו־VFS הרחיב את inode->i_ino מ־unsigned long ל־u64, ובכך הסיר את תקרת מספרי ה־inode בבניות של 32 סיביות. בצד של מערכות קבצים ברשת, שרת NFS בתוך הליבה יכול כעת לחתום על file handles באמצעות אפשרות ה־mount sign_fh, ולקוח CIFS למד את O_TMPFILE.

רשתות: השכרת תורים ומה היא מעניקה למכולה

השינוי המרכזי ברשתות הוא השכרת תורי חומרה. התקן רשת וירטואלי יכול כעת לשכור תור שמקושר לתור אמיתי בהתקן רשת פיזי, ולפעול כ־proxy עבורו. המטרה היא לתמוך במכולות. עד כה, מכולה שרצתה להשתמש ב־AF_XDP (משפחת הכתובות express data path, סוג socket שמעביר מנות גולמיות למרחב המשתמש בלי להעתיק אותן דרך מחסנית הרשת) נדרשה לקבל כמעט את ההתקן כולו. באמצעות תור מושכר היא מקבלת תור חומרה אחד, מפעילה AF_XDP וספקי זיכרון במהירות טבעית, והמארח שומר את שאר ה־NIC. התמיכה הזו מצטרפת לתמיכה ב־AF_XDP בנתיב ה־zero-copy של io_uring.

בצד הרגיל, sockets ב־sockfs מקבלים כעת תכונות מורחבות user.*. socket מסוג AF_UNIX שמבוסס על נתיב כבר ירש תמיכה ב־xattr ממערכת הקבצים שמתחתיו, אך socket שחי רק ב־sockfs לא כלל תמיכה כזו. כעת תהליך יכול לסמן socket, ותוכנית eBPF יכולה לסנן לפיו.

שתי יכולות הוסרו. UDP-Lite הוסר לאחר שלא נמצאו לו משתמשים. אי אפשר עוד לבנות את IPv6 כמודול שניתן לטעינה: אם דרושה תמיכה ב־IPv6, היא נבנית בתוך הליבה. ההסרה השנייה אינה מורגשת באף ליבת הפצה, משום שהפצות השרת הנפוצות כבר בונות את IPv6 בתוך הליבה.

ניהול זיכרון: טבלת ה־swap הושלמה

העבודה על ה־swap מגיעה לשלב השלישי שלה, ובשלב זה ממפת ה־swap הסטטית הוסרה. מספר ה־swap מאוחסן כעת ישירות בטבלת ה־swap. החיסכון המדווח הוא כ־30% מהמטא־נתונים הסטטיים של ה־swap. זהו זיכרון שה־kernel מחזיק ביחס לגודל התקן ה־swap, בין אם מתבצעת החלפה ובין אם לא. במונחים מוחלטים, מדובר בכמות קטנה בקובץ swap קטן, והיא גדלה בהתאם לגודל ה־swap שהגדרתם.

‏MGLRU ‏(multi-generational least recently used, האלגוריתם החדש יותר לפינוי דפים) יכול כעת לבדוק את דגל ה־young בדפים באצוות, במקום דף אחד בכל פעם. הנתון שפורסם עם השינוי מצביע על שיפור של יותר מ־60% בשרת Arm64 בעל 32 ליבות. עיבוד באצוות משתלם במיוחד כאשר העלות לכל דף גבוהה, ולכן הנתון הזה נמדד במכונת Arm גדולה. אם אתם מריצים VPS מבוסס Arm במקום VPS מבוסס x86, זהו השינוי ב־7.1 שסביר ביותר שיופיע במדידות שלכם, אף שלא באותו סדר גודל במכונה בעלת 2 או 4 ליבות.

בנוסף, העברות מתוך cgroups של זיכרון שנמצאים בתהליך סיום הוסרו, ‏khugepaged מבצע סריקות עם פחות צריכת CPU, ועץ ה־maple עבר ארגון מחדש נרחב סביב הטיפול בצמתים הגדולים שלו. אין צורך להגדיר אף אחד מהשינויים האלה. תבחינו בהם כזמן מערכת נמוך מעט יותר.

מתזמנים: מתזמי משנה של sched_ext, ו־FRED מופעל כברירת מחדל

sched_ext, מחלקת מתזנים הניתנת להרחבה ומאפשרת לכתוב מתזמן CPU כתוכנית BPF ולטעון אותו בזמן ריצה, נוספה ב־6.12. ב־7.1 נוספה תשתית הליבה למתזמי משנה, כך שבעתיד קבוצת בקרה תוכל לפעול תחת מתזמן משלה. יש לקרוא את המשפט הזה בתשומת לב. המימוש עדיין אינו גמור ב־7.1, ובפרט נתיב ה־enqueue חסר. לכן מדובר בתשתית למהדורה עתידית, ולא בתכונה שאפשר להפעיל כבר היום.

Intel FRED (flexible return and event delivery) מופעל כעת כברירת מחדל בחומרה שתומכת בו. FRED מחליף את נתיב מסירת האירועים הישן של x86 בנתיב נקי יותר. הוא נמצא בליבה מאז 6.9, אך עד כה הופעל באמצעות ארגומנט האתחול `fred=on`. המעבר להפעלה כברירת מחדל מצביע על כך שחומרה מסחרית נבדקה במידה מספקת. המדידות שפורסמו עד כה, בטווח של 4% עד 7% בעומסי עבודה כבדים ב־I/O, מבוססות על בדיקות Phoronix במעבדי client. לכן אין להניח שיפור כזה בשרת לפני שמודדים את עומס העבודה שלכם.

ב־Proxy execution נוספה העברת התורם לצורך האצת בעלים מרוחק של נעילה, ב־EEVDF תוקנו בעיות הקשורות ל־lag שלילי, וליבת הטיימרים ברזולוציה גבוהה שוכתבה במידה ניכרת. אלה שינויים באיכות זמני ההשהיה, שאינם נחשפים באמצעות קובץ תצורה כלשהו.

בקרות חדשות על תהליכים ועל מכולות ב־clone3()

שלושה דגלים נוספו ל־clone3(), וכל אחד מהם סוגר פער שמנהלי תהליכים נאלצו להתמודד איתו ידנית במשך שנים. CLONE_AUTOREAP גורם לילד לבצע בעצמו את פעולת האיסוף בעת היציאה, ולכן הוא לעולם אינו נשאר zombie שממתין להורה שאולי לא יקרא לעולם ל־wait(). CLONE_NNP מגדיר no_new_privs אצל הילד כבר בזמן יצירתו, וכך סוגר את חלון הזמן שבין השכפול לבין הגדרת הדגל על ידי הילד עצמו. CLONE_PIDFD_AUTOKILL קושר את משך החיים של הילד ל־pidfd שהוחזר להורה: סגירת ה־pidfd הורגת את הילד, ולכן מנהל תהליכים שמת אינו יכול להשאיר תהליכי orphan פעילים.

גם מרחבי mount קיבלו טיפול דומה. CLONE_EMPTY_MNTNS עבור clone3() ו־UNSHARE_EMPTY_MNTNS עבור unshare() יוצרים מרחב mount שאין בו דבר, במקום העתקה מלאה של ה־mounts מההורה, שאותה runtime צריך בדרך כלל להסיר. FSMOUNT_NAMESPACE מאפשר ל־fsmount() להציב מערכת קבצים ישירות בתוך מרחב חדש. runtimes של מכולות מרכיבים זאת ידנית כבר עשור, ולכן ביצוע הפעולה בקריאה אחת מאפשר ל־runtime לא להתחיל ממרחב שמלא ב־mounts של ה־host.

בתחום הווירטואליזציה, guest_memfd תומך כעת ב־userfaultfd, ולכן hypervisor יכול לטפל ב־page faults של guest ממרחב המשתמש. KVM מוגן על Arm קיבל תמיכה בזיכרון אנונימי, אך ב־merge עצמו מצוין שהתכונה עדיין אינה מוכנה לשימוש production.

מתי kernel 7.1 יגיע לשרת שלכם

Fedora כבר כוללת אותו. מאגר העדכונים של Fedora 44 עבר לסדרת 7.1 במהלך יולי ואוגוסט 2026, משום ש־Fedora מעדכנת את בסיס ה־kernel שלה לסדרות יציבות חדשות במהלך מחזור החיים של גרסה. גם Arch ו־openSUSE Tumbleweed כוללות אותו מאותה סיבה. אלה מערכות לבדיקות, לא מערכות להפעלת השירותים שלכם.

כל השאר ממתינים, וההמתנה מתוכננת. Debian 13 הופצה עם 6.12 ונשארת עם 6.12 לאורך כל מחזור החיים של הגרסה, כאשר תיקונים מועברים אליה לאחור. RHEL 10 הופצה עם 6.12.0 ופועלת באותו אופן. Ubuntu 26.04 LTS הופצה עם 7.0 באפריל 2026. Ubuntu 24.04 LTS כוללת hardware enablement stack, שמביא ל־LTS kernel חדש יותר מגרסאות Ubuntu מאוחרות יותר. נכון לגרסת התחזוקה 24.04.4, ה־stack הזה משתמש ב־6.17, והוא מתוכנן לעבור ל־7.0 עם 24.04.5 ב־27 באוגוסט 2026. גרסת תחזוקה אינה גרסה חדשה של Ubuntu, אלא אותה 24.04 עם כל העדכונים שפורסמו מאז, כשהם משולבים במדיית התקנה חדשה. לכן מה 24.04.5 משנה בשרת שכבר מותקנים בו עדכונים הוא שורת ה־kernel של HWE, וכמעט שום דבר מעבר לכך.

כאן אנשים טועים בדרך כלל. HWE stack עובר ל־kernel שכלול בגרסת ה־interim החדשה ביותר, ולכן הוא עשוי לדלג לחלוטין על סדרה של upstream. גרסה 7.0 כלולה ב־Ubuntu LTS. גרסה 7.1 אולי לעולם לא תהיה הבסיס של גרסת LTS, משום שה־interim release שאחריה תכלול סדרה מאוחרת יותר. מה שמגיע ל־LTS מ־7.1 הם התיקונים, שמועברים לאחור אל הסדרה שבה אתם משתמשים. רוב התכונות נשארות מאחור.

אם אתם אכן רוצים kernel חדש יותר בשרת יציב, מספר האפשרויות הנתמכות מצומצם.

# Ubuntu 24.04 LTS: install the hardware enablement stack
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot

# Debian 13, with trixie-backports enabled in your apt sources
apt-cache policy linux-image-amd64
sudo apt install -t trixie-backports linux-image-amd64
sudo reboot

לאחר האתחול, בדקו מה באמת עלה:

uname -r
dpkg -l 'linux-image-*' | grep ^ii
ls /var/run/reboot-required

uname -r אמור להציג כעת את הסדרה החדשה, ו־dpkg -l מציג כל kernel image שעדיין מותקן. אם uname -r מציג את הגרסה הישנה, בעוד dpkg -l מציג את החדשה, החבילה הותקנה אך ברירת המחדל של ה־bootloader לא השתנתה: בדקו את הרשומות בתפריט GRUB. קיומו של /var/run/reboot-required פירושו שחבילה עדכנה את ה־kernel ושמאז לא בוצע אתחול, וזו הסיבה הנפוצה ביותר לכך ששרת שקיבל תיקון עדיין מריץ את הקוד הפגיע.

האם כדאי לרדוף אחרי 7.1 ב־VPS ייצור

לא. הסיבה אינה זהירות לשם זהירות. kernel של הפצת Linux הוא חלק מחוזה התמיכה. Canonical, Red Hat, SUSE ו־Debian משלבות תיקוני אבטחה לאחור בענף היציב שלהן ובודקות אותם מול תוכנות המשתמש שהן מפיצות לצדו. kernel mainline מארכיון של צד שלישי, או kernel שבניתם בעצמכם, מספק את התכונות אך מסיר מכם את עבודת התחזוקה הזו, משום שאף גורם אינו משלב תיקונים לאחור ב־build שלכם. אתם הופכים למתחזקים של kernel.

החריגים קיימים, אך מצומצמים: חומרה שה־kernel הישן אינו יודע להפעיל, או שינוי ביצועים שמדדתם בעומס העבודה שלכם ואתם מעוניינים בו במידה שמצדיקה לקחת עליו אחריות. ב־VPS החריג הראשון כמעט אף פעם אינו רלוונטי, משום שהחומרה שאתם רואים היא וירטואלית. בכל מקרה אחר, השאירו את kernel של ההפצה מעודכן ואתחלו כאשר המערכת מבקשת זאת. אם שדרוג הפצה כבר נמצא ברשימה שלכם, מעבר מ־Ubuntu 24.04 ל־26.04 יעביר אתכם מ־6.8 ל־7.0 בצעד אחד. זהו קפיצה גדולה יותר מכל חבילת kernel יחידה.

FAQ

כיצד לבדוק באיזה ליבת Linux פועל ה־VPS שלי?

הריצו את uname -r. הפקודה מדפיסה פלט הדומה ל־6.8.0-79-generic. המספר שלפני המקף הראשון הוא סדרת המקור שעליה ההפצה מבוססת. כל מה שאחריו הוא מספר ה־build של ההפצה, והוא כולל תיקונים שהועברו לאחור. לאחר מכן הריצו את systemd-detect-virt. אם הפלט הוא lxc או openvz, אתם משתמשים בווירטואליזציה מבוססת מכולות, חולקים את ליבת ה־host, ואינכם יכולים לשנות אותה. אם הפלט הוא kvm, אתם מאתחלים image של ליבה משלכם, ואתם אחראים לשדרוגים שלה.

האם Linux 7.1 היא ליבת תמיכה ארוכת טווח?

לא. נכון ל־11 August 2026, סדרות התמיכה ארוכת הטווח המופיעות באתר kernel.org הן 6.18, 6.12, 6.6, 6.1, 5.15 ו־5.10, ו־7.1 אינה ביניהן. זו גרסה יציבה רגילה, והסדרה היציבה שלה מופסקת זמן קצר לאחר הופעת גרסת ה־mainline הבאה. אם אתם רוצים ליבה עם שנים של תיקונים שכבר נוספו לה ושנים של תיקונים שעדיין יתווספו לה, זו כבר ליבת ההפצה שלכם.

מתי Ubuntu או Debian יפיצו את ליבת 7.1?

כנראה לעולם לא כברירת מחדל. Debian 13 נשארת עם 6.12 לאורך כל מחזור החיים של הגרסה, ו־RHEL 10 נשארת עם 6.12.0. Ubuntu 26.04 LTS הופצה עם 7.0, ו־Ubuntu hardware enablement stack עוברת לליבה שנכללת בגרסת ה־interim החדשה ביותר, ולכן היא עשויה לדלג לחלוטין על סדרת מקור מסוימת. Ubuntu 24.04 LTS מתוכננת להעביר את ליבת ה־HWE שלה ל־7.0 עם גרסת הנקודה 24.04.5, ב־27 August 2026. התיקונים מ־7.1 יגיעו אליכם כ־backports לסדרה ישנה יותר. התכונות בדרך כלל לא יגיעו.

מה ב־Linux 7.1 באמת חשוב בשרת פרטי וירטואלי?

ארבעה פריטים. השכרת תורי חומרה מאפשרת למכולה להשתמש בתור NIC אמיתי אחד עבור AF_XDP במהירות native. השלב השלישי בעיבוד מחדש של ה־swap מסיר את מפת ה־swap הסטטית ומפחית ב־30% את המטא־נתונים שהליבה מחזיקה עבור התקן ה־swap, לפי הדיווחים. MGLRU יכולה לבדוק דגלי young של דפים באצוות, כאשר השיפור הגדול ביותר שפורסם נמדד בשרת Arm עם ליבות רבות. בנוסף, clone3() קיבלה את CLONE_AUTOREAP, את CLONE_NNP ואת CLONE_PIDFD_AUTOKILL, והן הופכות פיקוח על תהליכי child לבטוח יותר. מידע הגנה מסוג T10 ברמת מערכת הקבצים נוסף גם הוא, אך דיסק וירטואלי כמעט לעולם אינו חושף את מטא־נתוני השלמות הדרושים לכך.

האם שדרוג הליבה ישבית את ה־VPS שלי?

הכשלים הנפוצים מתרחשים בזמן האתחול. /boot מלא גורם ל־update-initramfs להיכשל עם No space left on device במהלך ההתקנה ומשאיר את החבילה בתצורה חלקית: נקו ליבות ישנות באמצעות sudo apt autoremove --purge ולאחר מכן התקינו מחדש. מודולים חיצוניים שנבנו מול הליבה הישנה מפסיקים להיטען. לכן כל רכיב המנוהל באמצעות DKMS צריך לעבור build מחדש, וכשל ב־build עלול שלא להתגלות עד שהמודול חסר בזמן הריצה. אם uname -r עדיין מדווח על הגרסה הישנה לאחר אתחול מחדש, בעוד ש־dpkg -l מציג את ה־image החדש, לא אירעה תקלה בהתקנה: ברירת המחדל של ה־bootloader לא השתנתה.