ما الجديد في Linux kernel 7.1 للخوادم؟
تعرّف إلى ما يصل فعليًا إلى خادم VPS، وكيف تتحقق من النواة الحالية، ولماذا قد لا يعمل Linux kernel 7.1 لديك قبل سنوات، مع تواريخ الدعم الطويل الأجل.
ما الجديد في Linux kernel 7.1
صدر Linux kernel 7.1 في 14 June 2026، بعد تسعة أسابيع من الإصدار 7.0. بالنسبة إلى مستأجر VPS (خادم خاص افتراضي)، تتركز التغييرات المهمة في أربعة مجالات: التخزين وأنظمة الملفات، والشبكات، وإدارة الذاكرة، والتحكم في العمليات والحاويات. أما بقية الإصدار فتتعلق في معظمها بسطح المكتب والرسومات، وهي مكونات لا يحمّلها الخادم الذي يعمل دون واجهة رسومية.
لكن توجد إجابة ثانية تحتاج إليها أولاً. من شبه المؤكد أن الإصدار 7.1 لا يعمل على خادمك، ولن يعمل عليه لفترة طويلة. لا يدرج kernel.org الإصدار 7.1 ضمن إصدارات الدعم طويل الأمد. في 11 August 2026، كانت سلاسل الدعم طويل الأمد هي 6.18 و6.12 و6.6 و6.1 و5.15 و5.10، وتبني كل توزيعة خوادم رئيسية إصداراتها على إحدى هذه السلاسل أو على سلسلة تصونها بنفسها. يفصل بين «الجديد في النواة» و«الجديد على خادمك» عدة أعوام، لذلك يغطي هذا الدليل كلا الجانبين.
Which kernel is your VPS running right now
uname -r
uname -srm
systemd-detect-virtuname -r prints the running kernel release. On Ubuntu 24.04 it looks like 6.8.0-79-generic. The part before the first dash is the upstream line. Everything after it is your distribution's own build number, and it does not track upstream at all. Canonical's 6.8.0-79 carries thousands of fixes backported from later kernels, so it is not the code Linus tagged as 6.8 in March 2024. This is why "my kernel is old" says less than it sounds like it does. The features are old. The security fixes usually are not.
systemd-detect-virt tells you whether you can change the kernel at all. It prints kvm on a full virtual machine, where you boot your own kernel image and an upgrade is a real upgrade. It prints lxc or openvz on container virtualisation, where the host kernel is shared. On a container plan uname -r shows the provider's kernel, installing a kernel package changes nothing you can boot, and no feature in this release is available to you until the provider reboots the host onto a newer kernel. Run this check before you plan any kernel work.
The data behind this chart
[
{
"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"
}
]That is 6 platforms, and not one of them boots 7.1. The newest is Ubuntu 26.04 LTS (7.0), which is 1 upstream release behind. The oldest still in support is 26 releases behind. Ubuntu 24.04's default GA kernel sits 13 releases back, and Debian 13 and RHEL 10 sit 9 back on the 6.12 longterm line. Counting releases is a rough measure, because it ignores everything the distributions backport, but it shows the shape of the gap. If you are weighing which of these to run, the LTS against interim release trade-off on a server is the decision underneath these numbers.
التخزين وأنظمة الملفات في 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 على إصلاحات لتضخيم النسخ عند الكتابة تحت ضغط الذاكرة، إلى جانب تغيير يسرّع مسح أول extent في نطاق متتبَّع. وقد أُبلغ عن زيادة throughput بنسبة 10% في حمل العمل النموذجي الذي يذكره الدمج. لم تعد عملية إيقاف التشغيل فيه موسومة بأنها تجريبية. يحسّن XFS تفريغ النطاق الصفري وعمليات البحث عبر iomap، ويضيف مؤشراً للكتابة إلى هندسة مجموعات الوقت الفعلي، وهو عمل تمهيدي للأجهزة المقسّمة إلى مناطق. أُعيدت كتابة NTFS بالكامل في هذا الإصدار، مع دعم كامل للكتابة وتحويل إلى iomap، وهذا مهم إذا احتجت يوماً إلى تركيب صورة قرص من جهاز Windows على خادمك.
من عناصر التخزين الأصغر التي تستحق المعرفة: اكتسب ublk، وهو مشغّل الكتل في مساحة المستخدم، عمليات I/O دون نسخ؛ واكتسب io_uring أوامر SCSI passthrough؛ وحصل دعم الأقراص ذاتية التشفير SED-OPAL على الأمر STACK_RESET وعلى وضع المستخدم الواحد الموسّع؛ وأُضيف مشغّل محارف fs-dax جديد للأجهزة ذات الوصول المباشر؛ ووسّعت VFS قيمة inode->i_ino من unsigned long إلى u64، مما يزيل الحد الأقصى لرقم inode في البنيات ذات 32 بت. وعلى جانب أنظمة الملفات الشبكية، يستطيع خادم NFS داخل النواة الآن توقيع file handles الخاصة به عبر خيار التركيب sign_fh، وتعلّم عميل CIFS استخدام O_TMPFILE.
الشبكات: تأجير قوائم الانتظار، وما يتيحه ذلك للحاوية
التغيير الأبرز في الشبكات هو تأجير قوائم انتظار العتاد. يمكن الآن لـ virtual netdev استئجار قائمة انتظار مرتبطة بقائمة انتظار فعلية على physical netdev، والعمل كوكيل لها. الغرض من ذلك هو دعم الحاويات. حتى الآن، كانت الحاوية التي تريد استخدام AF_XDP (اختصاراً لـ address family express data path، وهو نوع المقابس الذي يسلّم الحزم الأولية إلى مساحة المستخدم من دون نسخها عبر مكدس الشبكة) تحتاج إلى ما يقارب الجهاز بأكمله. أما مع قائمة الانتظار المؤجَّرة، فتحصل الحاوية على قائمة انتظار واحدة من العتاد، وتشغّل AF_XDP وموفّرات الذاكرة بالسرعة الأصلية، بينما يحتفظ المضيف بباقي NIC. يأتي ذلك بالتزامن مع دعم AF_XDP في مسار النسخ الصفري ضمن io_uring.
في الجانب الاعتيادي، تقبل المقابس في sockfs الآن السمات الموسّعة user.*. كان مقبس AF_UNIX القائم على مسار يرث دعم xattr من نظام الملفات الموجود تحته، لكن المقبس الموجود في sockfs فقط لم يكن يملك هذا الدعم. يمكن للعملية الآن وضع وسم على مقبس، ويمكن لبرنامج eBPF تطبيق تصفية استناداً إلى ذلك الوسم.
إزالتان. أُزيل UDP-Lite بعد عدم العثور على مستخدمين له. لم يعد بالإمكان بناء IPv6 كوحدة قابلة للتحميل: إذا أردت IPv6، فيجب تضمينه وقت الترجمة. لا يظهر التغيير الثاني في نواة أي توزيعة، لأن توزيعات الخوادم الشائعة تبني IPv6 مضمّناً بالفعل.
إدارة الذاكرة: اكتمل جدول swap
تصل إعادة تصميم swap إلى مرحلتها الثالثة، وتزيل هذه المرحلة خريطة swap الثابتة. أصبح عدد swap موجوداً الآن مباشرةً في جدول swap. يبلغ التوفير المعلن نحو 30% من البيانات الوصفية الثابتة لـswap. وهذه ذاكرة يحتفظ بها kernel بما يتناسب مع حجم جهاز swap لديك، سواء استُخدمت swap أم لا. من حيث القيمة المطلقة، يكون هذا التوفير صغيراً في ملف swap صغير، ويزداد مع حجم swap الذي تهيّئه.
يمكن لـMGLRU (خوارزمية استعادة الصفحات الأحدث، متعددة الأجيال) الآن التحقق من علامة الصفحات الحديثة على دفعات بدلاً من فحص صفحة واحدة في كل مرة. تُظهر الأرقام المنشورة مع هذا التغيير تحسناً يتجاوز 60% على خادم Arm64 ذي 32 نواة. تحقق المعالجة الدفعية أكبر فائدة عندما تكون تكلفة كل صفحة مرتفعة، ولهذا جاءت هذه النسبة من جهاز Arm كبير. إذا كنت تشغّل خادماً افتراضياً Arm بدلاً من خادم x86، فهذا هو التغيير في 7.1 الأكثر احتمالاً لأن يظهر في قياساتك، وإن لم يكن بالمقدار نفسه على جهاز ذي نواتين أو أربع نوى.
يتضمن هذا الإصدار أيضاً إلغاء عمليات النقل من مجموعات cgroup للذاكرة التي تحتضر، وتقليل استهلاك CPU أثناء عمليات الفحص التي يجريها khugepaged، وإعادة هيكلة كبيرة في maple tree لمعالجة العقد الكبيرة. لا تحتاج إلى تهيئة أي من هذه التغييرات. ستلاحظها على شكل انخفاض طفيف في وقت النظام.
المجدولات: المجدولات الفرعية لـsched_ext، وFRED مفعّل افتراضياً
وصلت sched_ext، وهي فئة المجدول القابلة للتوسعة التي تتيح لك كتابة مجدول CPU على هيئة برنامج BPF وتحميله أثناء التشغيل، في الإصدار 6.12. يضيف الإصدار 7.1 البنية الأساسية للمجدولات الفرعية، بحيث يمكن لمجموعة تحكم أن تعمل لاحقاً باستخدام مجدول خاص بها. اقرأ هذه الجملة بعناية. التنفيذ غير مكتمل في الإصدار 7.1، ومسار إدراج المهام في قائمة الانتظار مفقود تحديداً. لذلك تمثل هذه التغييرات أساساً لإصدار لاحق، وليست ميزة يمكنك تفعيلها اليوم.
أصبح Intel FRED (التسليم المرن للعودة والأحداث) مفعّلاً افتراضياً على العتاد الذي يدعمه. يستبدل FRED مسار تسليم الأحداث القديم في x86 بمسار أنظف. وهو موجود في النواة منذ الإصدار 6.9، لكنه كان يتطلب وسيطة الإقلاع fred=on. يعبّر تفعيله افتراضياً عن أن العتاد المتاح تجارياً خضع لاختبارات كافية. أما القياسات المنشورة حتى الآن، والتي تتراوح بين 4% و7% في أحمال العمل الكثيفة بعمليات الإدخال والإخراج، فتستند إلى اختبارات Phoronix على عتاد عميل. لذلك لا تعتمد هذه الأرقام في تخطيط أداء خادم قبل قياس حمل العمل لديك.
حصل التنفيذ بالوكالة على ترحيل للمانح عند تعزيز مالك قفل بعيد، وحصل EEVDF على إصلاحات تتعلق بالتأخر السالب، وأُعيدت كتابة نواة المؤقت عالي الدقة بدرجة كبيرة. هذه تغييرات تحسّن زمن الاستجابة، ولا تكشف عنها أي ملفات إعدادات.
ضوابط جديدة للعمليات والحاويات في clone3()
أُضيفت ثلاث رايات إلى clone3()، وتغلق كل واحدة منها ثغرة كان المشرفون يعالجونها يدوياً لسنوات. تجعل CLONE_AUTOREAP العملية الابنة تعيد جمع نفسها عند الخروج، لذلك لا تتحول أبداً إلى zombie بانتظار أب قد لا يستدعي wait() مطلقاً. تضبط CLONE_NNP قيمة no_new_privs للعملية الابنة وقت إنشائها، ما يغلق الفترة الفاصلة بين استدعاء clone وضبط العملية الابنة للراية بنفسها. تربط CLONE_PIDFD_AUTOKILL عمر العملية الابنة بملف pidfd الذي يُعاد إلى العملية الأب: عند إغلاق pidfd تُقتل العملية الابنة، ولذلك لا يستطيع مشرف يتوقف عن العمل ترك عمليات orphan قيد التشغيل.
حصلت mount namespaces على المعالجة نفسها. ينشئ CLONE_EMPTY_MNTNS لـ clone3() وUNSHARE_EMPTY_MNTNS لـ unshare() mount namespace لا يحتوي على شيء، بدلاً من النسخ الكامل المعتاد لـmounts الخاصة بالعملية الأب، والذي يتعين على runtime بعد ذلك إلغاء تركيبه. يتيح FSMOUNT_NAMESPACE لـ fsmount() وضع filesystem مباشرة داخل namespace جديد. ظلت runtimes الخاصة بالحاويات تنفذ ذلك يدوياً طوال عقد، ولذلك يعني تنفيذ العملية باستدعاء واحد أن runtime لم يعد يبدأ من namespace ممتلئ بـmounts الخاصة بالمضيف.
في جانب virtualisation، يدعم guest_memfd الآن userfaultfd، ولذلك يستطيع hypervisor معالجة page faults الخاصة بالضيف من user space. حصل Protected KVM على Arm على دعم للذاكرة المجهولة، ويصفه الدمج نفسه بأنه غير جاهز للاستخدام في production.
متى يصل kernel 7.1 إلى خادمك
لدى Fedora هذا الإصدار بالفعل. انتقل مستودع تحديثات Fedora 44 إلى سلسلة 7.1 خلال يوليو وأغسطس 2026، لأن Fedora تعيد بناء kernel على سلاسل مستقرة جديدة ضمن دورة الإصدار. ولدى Arch وopenSUSE Tumbleweed هذا الإصدار للسبب نفسه. هذه أجهزة للاختبار، وليست أجهزة لتشغيل خدماتك عليها.
ينتظر كل ما عدا ذلك، وهذا الانتظار مقصود. صدر Debian 13 مع 6.12، ويبقى على 6.12 طوال فترة الإصدار، مع backport للإصلاحات إليه. وصدر RHEL 10 مع 6.12.0 ويتبع النهج نفسه. صدر Ubuntu 26.04 LTS مع 7.0 في أبريل 2026. ويحتوي Ubuntu 24.04 LTS على hardware enablement stack، الذي يجلب kernel أحدث من إصدارات Ubuntu اللاحقة إلى إصدار LTS. ويعمل هذا stack على 6.17 اعتباراً من الإصدار النقطي 24.04.4، ومن المقرر أن ينتقل إلى 7.0 مع 24.04.5 في 27 أغسطس 2026. الإصدار النقطي ليس إصداراً جديداً من Ubuntu، بل هو 24.04 نفسه مع دمج كل التحديثات الصادرة منذ ذلك الحين في وسائط تثبيت جديدة. لذلك فإن ما الذي يغيّره 24.04.5 على خادم تطبّق عليه التحديثات بالفعل هو سلسلة HWE الخاصة بـkernel، مع تغييرات قليلة جداً بخلاف ذلك.
إليك النقطة التي يخطئ فيها الناس. ينتقل HWE stack إلى kernel الذي يحمله أحدث إصدار مرحلي، لذلك قد يتجاوز سلسلة upstream كاملة. يوجد 7.0 في إصدار Ubuntu LTS. وقد لا يكون 7.1 أساساً لأي إصدار LTS، لأن الإصدار المرحلي الذي يليه سيحمل سلسلة أحدث. وما يصل إلى إصدار LTS من 7.1 هو الإصلاحات التي تُجرى لها backport إلى السلسلة التي تستخدمها. أما الميزات فتبقى في الغالب خارجها.
إذا كنت تريد 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 التي ما زالت مثبتة. إذا عرض uname -r الإصدار القديم، بينما يسرد dpkg -l الإصدار الجديد، فقد ثُبّتت الحزمة، لكن الإعداد الافتراضي لمحمل الإقلاع لم يتغير: راجع إدخالات قائمة GRUB. يعني وجود /var/run/reboot-required أن حزمة حدّثت kernel ولم تحدث إعادة تشغيل منذ ذلك الحين. وهذا هو السبب الأكثر شيوعاً لاستمرار خادم مُرقّع في تنفيذ الشفرة المعرّضة للخطر.
هل ينبغي لك ملاحقة الإصدار 7.1 على VPS مخصص للإنتاج
لا، والسبب ليس الحذر لمجرد الحذر. نواة التوزيعة هي جزء من عقد الدعم. تعمل Canonical وRed Hat وSUSE وDebian على إدراج إصلاحات الأمان بأثر رجعي في خط الإصدارات الثابت، وتختبرها مع برامج userspace التي توفرها معه. تمنحك نواة mainline من أرشيف تابع لجهة خارجية أو نواة تبنيها يدوياً الميزات، لكنها تزيل عنك هذا العمل، لأن أحداً لن يدرج الإصلاحات بأثر رجعي في البنية التي أنشأتها. وبذلك تصبح أنت المسؤول عن صيانة النواة.
الاستثناءات موجودة فعلاً، لكنها محدودة: عتاد لا تستطيع النواة الأقدم تشغيله، أو تغيير في الأداء قسته على workload الخاص بك وتحتاج إليه بدرجة تجعلك مستعداً لتحمل تبعاته. على VPS، ينطبق الاستثناء الأول نادراً جداً، لأن العتاد الذي تراه افتراضي. في الحالات الأخرى، أبقِ نواة التوزيعة محدثة وأعد التشغيل عندما تطلب منك ذلك. إذا كانت ترقية التوزيعة مدرجة في خطتك، فإن الانتقال من Ubuntu 24.04 إلى 26.04 ينقلك من 6.8 إلى 7.0 في خطوة واحدة، وهي قفزة أكبر من أي حزمة نواة منفردة يمكن أن توفرها لك.
FAQ
كيف أتحقق من نواة Linux التي يشغّلها VPS الخاص بي؟
شغّل uname -r. يعرض ناتجاً مشابهاً لـ 6.8.0-79-generic. يمثّل الرقم الذي يسبق أول شرطة السلسلة الأساسية التي تبني عليها توزيعتك، بينما تمثّل كل الأرقام التي تليه رقم البناء الخاص بالتوزيعة، ويتضمن إصلاحات مُرحّلة إلى الخلف. ثم شغّل systemd-detect-virt. إذا عرض lxc أو openvz، فأنت تستخدم افتراضية الحاويات، وتشارك نواة المضيف، ولا يمكنك تغييرها. وإذا عرض kvm، فأنت تقلع صورة نواة خاصة بك، وعليك تنفيذ ترقياتها بنفسك.
هل Linux 7.1 نواة ذات دعم طويل الأمد؟
لا. في 11 August 2026، سلاسل الدعم طويل الأمد المدرجة على kernel.org هي 6.18 و6.12 و6.6 و6.1 و5.15 و5.10، ولا تُعدّ 7.1 من بينها. إنها إصدار مستقر عادي، ويُوقَف خطها المستقر بعد وقت قصير من ظهور الإصدار الرئيسي التالي. إذا كنت تريد نواة تتوفر لها إصلاحات لسنوات ماضية وقادمة، فهذا هو حال نواة توزيعتك أصلاً.
متى ستُصدر Ubuntu أو Debian النواة 7.1؟
على الأرجح لن تُصدرها كإصدار افتراضي. ستبقى Debian 13 على 6.12 طوال فترة الإصدار، وستبقى RHEL 10 على 6.12.0. أصدرت Ubuntu 26.04 LTS النواة 7.0، وتنتقل حزمة Ubuntu لتمكين العتاد إلى النواة التي يحملها أحدث إصدار مرحلي، ولذلك قد تتجاوز سلسلة رئيسية كاملة. من المقرر أن تنقل Ubuntu 24.04 LTS نواة HWE إلى 7.0 مع الإصدار النقطي 24.04.5 في 27 August 2026. ستصل إصلاحات 7.1 إليك على شكل backports إلى سلسلة أقدم. أما الميزات فعادةً لن تصل.
ما الذي يهم فعلياً في Linux 7.1 على خادم خاص افتراضي؟
أربعة عناصر. يتيح تأجير قوائم انتظار العتاد لحاوية استخدام قائمة انتظار فعلية واحدة من NIC مع AF_XDP بالسرعة الأصلية. تزيل المرحلة الثالثة من إعادة تصميم swap خريطة swap الثابتة، وتخفض البيانات الوصفية التي تحتفظ بها النواة لجهاز swap بنسبة معلنة تبلغ 30%. ويمكن لـMGLRU فحص أعلام حداثة الصفحات على دفعات، مع أكبر مكسب منشور على خادم Arm متعدد الأنوية. كما حصل clone3() على CLONE_AUTOREAP وCLONE_NNP وCLONE_PIDFD_AUTOKILL، ما يجعل الإشراف على العمليات التابعة أكثر أماناً. ووصلت أيضاً معلومات حماية T10 على مستوى نظام الملفات، لكن القرص الافتراضي نادراً ما يوفّر البيانات الوصفية الخاصة بسلامة البيانات التي تحتاج إليها.
هل سيؤدي تحديث النواة إلى تعطيل VPS الخاص بي؟
تحدث حالات الفشل الشائعة أثناء الإقلاع. يؤدي امتلاء /boot إلى فشل update-initramfs مع No space left on device أثناء التثبيت، ما يترك الحزمة مهيّأة جزئياً: أزل النوى القديمة باستخدام sudo apt autoremove --purge، ثم أعد التثبيت. وتتوقف الوحدات الخارجية عن شجرة النواة التي بُنيت للنواة القديمة عن التحميل، لذلك يجب إعادة بناء أي شيء يديره DKMS، وقد يفشل البناء دون ظهور ذلك حتى تصبح الوحدة مفقودة أثناء التشغيل. وإذا ظل uname -r يعرض الإصدار القديم بعد إعادة التشغيل بينما يعرض dpkg -l الصورة الجديدة، فلم يحدث خلل في التثبيت: لم يتغير الإعداد الافتراضي لمحمل الإقلاع.