Linux kernel 7.1 मध्ये servers साठी काय नवीन?

Linux kernel 7.1 मध्ये नवीन काय आहे

Linux kernel 7.1 चे प्रकाशन 14 June 2026 रोजी झाले. हे 7.0 नंतर नऊ आठवड्यांनी प्रकाशित झाले. VPS (virtual private server) वापरकर्त्यासाठी महत्त्वाचे बदल चार क्षेत्रांत आहेत: storage आणि filesystems, networking, memory management, तसेच process आणि container control. या release मधील उर्वरित काम मुख्यतः desktop आणि graphics संबंधित आहे. headless server ते सहसा load करत नाही.

आधी दुसऱ्या प्रश्नाचे उत्तर देणे आवश्यक आहे. तुमच्या server वर 7.1 चालू असण्याची शक्यता जवळजवळ नाही. ते बराच काळ चालणारही नाही. kernel.org वर 7.1 ला longterm release म्हणून सूचीबद्ध केलेले नाही. 11 August 2026 रोजी longterm lines 6.18, 6.12, 6.6, 6.1, 5.15 आणि 5.10 आहेत. मुख्य server distributions यापैकी एखाद्या line वर किंवा स्वतः maintain करत असलेल्या line वर आधारित असतात. "kernel मध्ये नवीन" आणि "तुमच्या server वर नवीन" यांमध्ये अनेक वर्षांचे अंतर असते. त्यामुळे या मार्गदर्शकात दोन्ही भागांचा समावेश केला आहे.

तुमचा VPS सध्या कोणता kernel चालवत आहे

uname -r
uname -srm
systemd-detect-virt

uname -r चालू kernel release दाखवते. Ubuntu 24.04 वर ते 6.8.0-79-generic असे दिसते. पहिल्या dash पूर्वीचा भाग upstream line असतो. त्यानंतरचा संपूर्ण भाग तुमच्या distribution चा स्वतःचा build number असतो. तो upstream शी थेट जुळत नाही. Canonical चे 6.8.0-79 नंतरच्या kernels मधील हजारो fixes backport करून समाविष्ट करते. त्यामुळे तो March 2024 मध्ये Linus ने 6.8 म्हणून tag केलेला code नाही. म्हणून "माझा kernel जुना आहे" या विधानाचा अर्थ ऐकू येतो त्यापेक्षा कमी असतो. Features जुने असतात. Security fixes सहसा जुने नसतात.

systemd-detect-virt मुळे तुम्ही kernel बदलू शकता की नाही हे समजते. पूर्ण virtual machine वर ते kvm दाखवते. अशा ठिकाणी तुम्ही तुमची स्वतःची kernel image boot करता आणि upgrade हा प्रत्यक्ष upgrade असतो. Container virtualisation वर ते lxc किंवा openvz दाखवते. अशा वेळी host kernel shared असतो. Container plan वर uname -r provider चा kernel दाखवते. Kernel package install केल्याने तुम्ही boot करू शकणाऱ्या kernel मध्ये कोणताही बदल होत नाही. Provider ने host ला newer kernel वर reboot करेपर्यंत या release मधील कोणतेही feature तुम्हाला उपलब्ध होत नाही. 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 platforms आहेत आणि त्यांपैकी एकही 7.1 boot करत नाही. सर्वांत नवीन platform Ubuntu 26.04 LTS (7.0) आहे. ते upstream release च्या तुलनेत 1 releases मागे आहे. अजूनही support मध्ये असलेले सर्वांत जुने platform 26 releases मागे आहे. Ubuntu 24.04 चा default GA kernel 13 releases मागे आहे. Debian 13 आणि RHEL 10 हे 6.12 longterm line वर 9 releases मागे आहेत. Releases मोजणे हे अंदाजे माप आहे, कारण distributions कडून backport केलेल्या सर्व बदलांकडे त्यात दुर्लक्ष होते. तरीही अंतराचे स्वरूप त्यातून स्पष्ट होते. यांपैकी कोणते platform वापरायचे याचा विचार करत असाल, तर server वरील LTS आणि interim release मधील trade-off हा या संख्यांमागील मुख्य निर्णय आहे.

7.1 मधील संचयन आणि फाइलसिस्टम

7.1 मध्ये block layer पुरते मर्यादित न राहता filesystem मध्येच T10 PI (protection information) तयार आणि पडताळण्याची क्षमता जोडली आहे. यासोबत लवचिक T10 alignment support देखील जोडले आहे. T10 PI म्हणजे प्रत्येक block ला जोडलेले अतिरिक्त bytes. त्यात checksum आणि data कोणत्या block शी संबंधित आहे हे ओळखणारा tag असतो. त्यामुळे चुकीच्या block कडे वळवलेले किंवा अपूर्ण write शोधले जाते आणि ते योग्य data म्हणून परत दिले जात नाही. VPS tenant साठी मुख्य अडचण hardware ची आहे. Integrity metadata device ने उपलब्ध करून दिले पाहिजे. Virtual disk हे metadata सहसा उपलब्ध करून देत नाही.

ls /sys/block/vda/integrity/

बहुतेक VPS disks वर यामुळे No such file or directory मिळते. Device integrity support नोंदवते तेव्हाच block layer integrity directory तयार करतो. त्यामुळे येथे दिसणारी error ही सामान्य स्थिती आहे; ती fault नाही. Storage features बद्दल पुढे वाचण्यापूर्वी तुमची disk प्रत्यक्षात NVMe आहे का हे जाणून घ्यायचे असल्यास VPS disk प्रत्यक्षात NVMe आहे का ते तपासणे हा पहिला टप्पा आहे. तसेच VPS वरील NVMe आणि SATA SSD मधील फरक यामुळे तुमच्या आकडेवारीत बदल का होतो हे स्पष्ट होते.

Btrfs मध्ये memory pressure असताना copy-on-write amplification साठी fixes जोडले आहेत. Tracked range मधील पहिला extent clear करण्याची गती वाढवणारा बदलही जोडला आहे. Merge मध्ये नमूद केलेल्या sample workload वर throughput 10% ने वाढल्याचे नोंदवले आहे. त्याची shutdown operation आता experimental म्हणून चिन्हांकित केलेली नाही. XFS मध्ये iomap द्वारे zero range flushing आणि lookup सुधारले आहेत. तसेच real-time group geometry मध्ये write pointer जोडला आहे. हा बदल zoned devices साठीची पायाभूत तयारी आहे. या release मध्ये NTFS चे पूर्ण पुनर्लेखन केले आहे. त्यात पूर्ण write support आणि iomap conversion आहे. त्यामुळे Windows machine वरील disk image तुमच्या server वर mount करायची असल्यास हा बदल महत्त्वाचा ठरतो.

लक्षात ठेवण्यासारख्या इतर संचयनविषयक बाबी: ublk या user-space block driver मध्ये zero-copy I/O जोडले आहे; io_uring मध्ये SCSI passthrough commands जोडले आहेत; SED-OPAL self-encrypting drive support मध्ये STACK_RESET command आणि extended single user mode जोडले आहेत; direct-access devices साठी नवीन fs-dax character driver उपलब्ध आहे; तसेच VFS ने inode->i_ino ची रुंदी unsigned long वरून u64 इतकी वाढवली आहे. त्यामुळे 32-bit builds मधील inode number ceiling दूर होते. Network filesystem च्या बाबतीत, in-kernel NFS server आता sign_fh mount option द्वारे स्वतःचे file handles sign करू शकतो. CIFS client ने O_TMPFILE शिकले आहे.

नेटवर्किंग: queue leasing आणि त्यातून container ला मिळणारे फायदे

नेटवर्किंगमधील प्रमुख बदल म्हणजे hardware queue leasing. आता virtual netdev एखादी queue lease करू शकतो. ही queue physical netdev वरील वास्तविक queue शी बांधलेली असते. virtual netdev त्या queue साठी proxy म्हणून काम करू शकतो. याचा मुख्य उपयोग containers साठी आहे. आतापर्यंत AF_XDP वापरू इच्छिणाऱ्या container ला जवळजवळ संपूर्ण device द्यावे लागत असे. AF_XDP म्हणजे address family express data path. हा असा socket प्रकार आहे जो network stack मधून packets copy करून पुढे न पाठवता raw packets थेट user space ला देतो. Lease केलेल्या queue मुळे container ला एक hardware queue मिळते. तो native speed ने AF_XDP आणि memory providers चालवू शकतो. Host कडे NIC वरील उर्वरित भाग राहतो. ही सुविधा io_uring च्या zero-copy path मधील AF_XDP support च्या जवळ जोडली जाते.

सामान्य वापराच्या बाजूने, sockfs मधील sockets आता user.* extended attributes स्वीकारतात. Path-based AF_UNIX socket ला त्याखालील filesystem कडून xattr support आधीच मिळत असे. मात्र केवळ sockfs मध्ये अस्तित्वात असलेल्या socket ला ही सुविधा नव्हती. आता process socket ला label देऊ शकतो. eBPF program त्या label वर आधारित filtering करू शकतो.

दोन गोष्टी काढून टाकण्यात आल्या आहेत. कोणतेही users न मिळाल्यामुळे UDP-Lite काढून टाकण्यात आले आहे. IPv6 आता loadable module म्हणून build करता येणार नाही. IPv6 हवे असल्यास ते kernel मध्ये compiled in असणे आवश्यक आहे. दुसरा बदल कोणत्याही distribution kernel मध्ये दिसणार नाही, कारण सर्वसाधारण server distributions आधीपासून IPv6 built in ठेवतात.

स्मृती व्यवस्थापन: swap table चे काम पूर्ण

swap मधील पुनर्रचनेचा तिसरा टप्पा पूर्ण झाला आहे. या टप्प्यात static swap map काढून टाकण्यात आला आहे. swap count आता थेट swap table मध्ये ठेवला जातो. static swap metadata च्या सुमारे 30% इतकी memory वाचते, असे अहवालात नमूद केले आहे. swap होत असो वा नसो, kernel ही memory तुमच्या swap device च्या आकाराच्या प्रमाणात राखून ठेवतो. लहान swap file असल्यास ही बचत प्रत्यक्ष प्रमाणात कमी असते. तुम्ही configure केलेला swap वाढल्यास ही बचतही वाढते.

MGLRU (multi-generational least recently used, नवीन page reclaim algorithm) आता pages वरील young flag एकावेळी एका page ऐवजी batches मध्ये तपासू शकते. या बदलासोबत प्रकाशित केलेल्या आकडेवारीनुसार Arm64 32-core server वर 60% पेक्षा जास्त सुधारणा झाली. प्रत्येक page साठी लागणारा खर्च जिथे अधिक असतो, तिथे batching चा सर्वाधिक फायदा होतो. म्हणूनच हा आकडा मोठ्या Arm machine वरून मिळाला. तुम्ही x86 ऐवजी Arm VPS चालवत असाल, तर 7.1 मधील तुमच्या स्वतःच्या मोजमापांत दिसण्याची सर्वाधिक शक्यता असलेला हा बदल आहे. मात्र दोन किंवा चार cores वर तीच पातळीची सुधारणा दिसणार नाही.

यामध्ये dying memory cgroups मधून होणारे transfers काढून टाकण्यात आले आहेत, khugepaged आता कमी CPU वापरून scans करते, आणि maple tree मध्ये त्याच्या big node handling भोवती मोठ्या प्रमाणावर refactor करण्यात आला आहे. यापैकी कोणतीही गोष्ट तुम्ही configure करत नाही. system time किंचित कमी झाल्याचे तुम्हाला जाणवेल.

Schedulers: sched_ext उप-शेड्यूलर्स आणि डीफॉल्टने सक्षम FRED

sched_ext हा विस्तारणीय scheduler class आहे. यामुळे BPF program म्हणून CPU scheduler लिहून तो runtime मध्ये load करता येतो. तो 6.12 मध्ये आला. 7.1 मध्ये sub-schedulers साठी मूलभूत रचना जोडली आहे. त्यामुळे पुढे एखादा control group स्वतःच्या scheduler अंतर्गत चालवता येईल. हे वाक्य काळजीपूर्वक वाचा. 7.1 मध्ये implementation पूर्ण झालेले नाही. विशेषतः enqueue path अद्याप उपलब्ध नाही. त्यामुळे हे आज सक्षम करता येणारे feature नसून पुढील release साठीची पायाभूत कामगिरी आहे.

Intel FRED (flexible return and event delivery) आता ते समर्थित असलेल्या hardware वर डीफॉल्टने enabled आहे. FRED पारंपरिक x86 event delivery path च्या जागी अधिक सुटसुटीत path वापरतो. तो 6.9 पासून kernel मध्ये आहे आणि fred=on boot argument मागे enabled करता येत होता. आता तो डीफॉल्टने enabled करणे म्हणजे बाजारात उपलब्ध hardware वर पुरेशी चाचणी झाली आहे, असा निष्कर्ष आहे. आतापर्यंत प्रकाशित केलेली 4% ते 7% सुधारणा I/O-केंद्रित workloads साठी आहेत. त्या client silicon वरील Phoronix testing मधून मिळाल्या आहेत. त्यामुळे स्वतःच्या workload चे मोजमाप करेपर्यंत server साठी अशी सुधारणा गृहीत धरू नका.

Proxy execution मध्ये remote lock owner ला boost करण्यासाठी donor migration जोडले आहे. EEVDF मध्ये negative lag संदर्भातील दुरुस्त्या केल्या आहेत. High-resolution timer core ची मोठ्या प्रमाणावर पुनर्रचना केली आहे. ही latency गुणवत्तेशी संबंधित बदल आहेत. त्यापैकी कोणताही बदल configuration file मधून उघड करता येत नाही.

clone3() मधील नवीन प्रक्रिया आणि कंटेनर नियंत्रणे

clone3() मध्ये तीन flags जोडले गेले आहेत. प्रत्येक flag मुळे supervisors अनेक वर्षे manually भरून काढत असलेली एक उणीव दूर होते. CLONE_AUTOREAP child ला exit होताना स्वतःच reap होण्यास सांगते. त्यामुळे parent ने wait() कधीही call न केल्यास child zombie म्हणून अडकून राहत नाही. CLONE_NNP child तयार होताच त्यावर no_new_privs सेट करते. त्यामुळे clone झाल्यानंतर child ने स्वतःसाठी हा flag सेट करण्यापूर्वीची तात्पुरती असुरक्षित वेळ संपते. CLONE_PIDFD_AUTOKILL child चे lifetime parent ला परत मिळालेल्या pidfd शी जोडते. pidfd close केल्यावर child kill केले जाते. त्यामुळे supervisor बंद पडल्यास orphan प्रक्रिया चालू राहत नाही.

Mount namespaces साठीही अशीच सुविधा देण्यात आली आहे. CLONE_EMPTY_MNTNS for clone3() आणि UNSHARE_EMPTY_MNTNS for unshare() वापरल्यास कोणतीही सामग्री नसलेले mount namespace तयार होते. नेहमीच्या पद्धतीत parent च्या mounts ची पूर्ण प्रत तयार होते आणि runtime ला ती नंतर unmount करावी लागते. FSMOUNT_NAMESPACE मुळे fsmount() filesystem थेट नवीन namespace मध्ये ठेवू शकते. Container runtimes गेल्या दशकभरापासून हे manually करत आहेत. आता हे एका call मध्ये करता येते. त्यामुळे runtime ची सुरुवात host च्या mounts ने भरलेल्या namespace पासून होत नाही.

Virtualisation च्या बाजूने, guest_memfd आता userfaultfd ला support करते. त्यामुळे hypervisor guest page faults user space मधून हाताळू शकतो. Arm वरील Protected KVM ला anonymous memory support मिळाले आहे. मात्र merge च्या वर्णनातच ते production ready नसल्याचे नमूद केले आहे.

kernel 7.1 तुमच्या सर्व्हरवर कधी येईल

Fedora मध्ये ते आधीच उपलब्ध आहे. Fedora 44 चे update repository जुलै आणि ऑगस्ट 2026 दरम्यान 7.1 मालिकेवर गेले, कारण प्रत्येक release मध्ये Fedora आपला kernel नवीन stable line वर rebase करते. Arch आणि openSUSE Tumbleweed मध्येही ते याच कारणामुळे उपलब्ध आहे. ही यंत्रे चाचणीसाठी आहेत; तुमच्या सेवा चालवण्यासाठी नाहीत.

इतर सर्वजण प्रतीक्षा करतात आणि ही प्रतीक्षा जाणीवपूर्वक केलेली असते. Debian 13 हे 6.12 सह release झाले आणि संपूर्ण release कालावधीत 6.12 वरच राहते; त्यात fixes backport केले जातात. RHEL 10 हे 6.12.0 सह release झाले आणि त्याच पद्धतीने काम करते. Ubuntu 26.04 LTS हे एप्रिल 2026 मध्ये 7.0 सह release झाले. Ubuntu 24.04 LTS मध्ये hardware enablement stack आहे. तो नंतरच्या Ubuntu releases मधील नवीन kernel LTS मध्ये आणतो. 24.04.4 point release नुसार हा stack 6.17 वर आहे आणि 27 August 2026 रोजी नियोजित 24.04.5 सह तो 7.0 वर जाणार आहे. Point release ही Ubuntu ची नवीन आवृत्ती नसते. त्यात फक्त त्याच 24.04 मधील त्या वेळेपर्यंतचे सर्व updates नव्या install media मध्ये समाविष्ट केलेले असतात. त्यामुळे तुम्ही आधीच patch करत असलेल्या सर्व्हरवर 24.04.5 मध्ये काय बदलते हे HWE kernel line आणि इतर अत्यल्प बदलांपुरते मर्यादित आहे.

लोकांकडून नेहमी चूक होणारा मुद्दा असा आहे. HWE stack नवीनतम interim release मध्ये असलेला kernel स्वीकारतो. त्यामुळे एखादी upstream line पूर्णपणे वगळली जाऊ शकते. 7.0 Ubuntu LTS मध्ये आहे. 7.1 एखाद्या LTS चा base कधीच नसेल, कारण त्यानंतरचे interim release त्यापेक्षा नवीन line वापरेल. 7.1 मधील fixes तुमच्या LTS पर्यंत पोहोचतात, पण ते तुमच्या सध्याच्या kernel line मध्ये backport केलेले असतात. Features मात्र बहुतेक वेळा येत नाहीत.

Stable सर्व्हरवर नवीन kernel हवा असल्यास supported मार्ग कमी आहेत.

# 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

रीबूटनंतर प्रत्यक्षात कोणता kernel boot झाला ते तपासा:

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

uname -r मध्ये आता नवीन line दिसली पाहिजे आणि dpkg -l मध्ये अजूनही installed असलेल्या प्रत्येक kernel image ची यादी दिसते. uname -r मध्ये जुनी आवृत्ती दिसत असताना dpkg -l मध्ये नवीन आवृत्तीची नोंद असल्यास, package install झाले आहे; पण bootloader default बदललेला नाही. GRUB menu entries तपासा. /var/run/reboot-required अस्तित्वात असल्यास package ने kernel upgrade केला आहे आणि त्यानंतर रीबूट झालेले नाही. Patched सर्व्हर अजूनही vulnerable code execute करत राहण्याचे हे सर्वात सामान्य कारण आहे.

उत्पादन VPS वर 7.1 च्या मागे जावे का

नाही. याचे कारण केवळ सावधगिरी बाळगणे नाही. Distribution kernel हा support contract असतो. Canonical, Red Hat, SUSE आणि Debian त्यांच्या स्थिर release line मध्ये security fixes backport करतात आणि त्याच्यासोबत उपलब्ध करून दिलेल्या userspace विरुद्ध त्यांची चाचणी घेतात. Third-party archive मधील mainline kernel किंवा स्वतः build केलेला kernel तुम्हाला नवीन features देतो, पण हे काम तुमच्यावर सोपवतो, कारण तुमच्या build मध्ये fixes backport करणारे कोणीही नसते. त्यामुळे kernel maintain करण्याची जबाबदारी तुमची होते.

अपवाद खरे आहेत, पण मर्यादित आहेत: जुना kernel चालवू शकत नसलेले hardware किंवा स्वतःच्या workload वर मोजून पाहिलेला performance बदल, ज्याचे परिणाम स्वीकारण्याइतकी त्याची आवश्यकता तुम्हाला वाटते. VPS मध्ये पहिला अपवाद जवळजवळ लागू होत नाही, कारण तुम्हाला दिसणारे hardware virtual असते. इतर सर्व बाबतीत distribution kernel current ठेवा आणि तो reboot मागेल तेव्हा reboot करा. Distribution upgrade आधीच तुमच्या यादीत असल्यास, Ubuntu 24.04 वरून 26.04 कडे जाणे तुम्हाला एका टप्प्यात 6.8 वरून 7.0 पर्यंत नेते. ही झेप कोणतेही एक kernel package देऊ शकते त्यापेक्षा मोठी आहे.

FAQ

माझा VPS कोणता Linux kernel चालवत आहे, हे कसे तपासू?

uname -r चालवा. त्यातून 6.8.0-79-generic सारखे आउटपुट दिसते. पहिल्या dash पूर्वीची संख्या तुमचे distribution ज्या upstream line वर आधारित build तयार करते ती दर्शवते. त्यानंतरची संपूर्ण संख्या distribution चा स्वतःचा build number असते. त्यात backported fixes समाविष्ट असतात. त्यानंतर systemd-detect-virt चालवा. त्यातून lxc किंवा openvz दिसल्यास, तुम्ही container virtualisation वर आहात. तुम्ही host चा kernel share करता आणि तो बदलू शकत नाही. त्यातून kvm दिसल्यास, तुम्ही तुमची स्वतःची kernel image boot करता आणि तिचे upgrades तुम्हालाच करावे लागतात.

Linux 7.1 हा longterm support kernel आहे का?

नाही. 11 August 2026 रोजी kernel.org वर सूचीबद्ध longterm lines 6.18, 6.12, 6.6, 6.1, 5.15 आणि 5.10 आहेत. 7.1 त्यात नाही. हे एक सामान्य stable release आहे. पुढील mainline release उपलब्ध झाल्यानंतर त्याची stable line लवकरच बंद केली जाते. अनेक वर्षे fixes मिळत राहावेत आणि पुढील अनेक वर्षे fixes उपलब्ध असावेत असे तुम्हाला हवे असल्यास, तुमच्या distribution चा kernel आधीपासून त्यासाठीच असतो.

Ubuntu किंवा Debian kernel 7.1 कधी release करतील?

बहुधा default म्हणून कधीच नाही. Release च्या संपूर्ण कालावधीत Debian 13 6.12 वरच राहते आणि RHEL 10 6.12.0 वरच राहते. Ubuntu 26.04 LTS ने 7.0 release केले. Ubuntu hardware enablement stack नवीनतम interim release मध्ये असलेला kernel स्वीकारतो. त्यामुळे तो एखादी upstream line पूर्णपणे वगळू शकतो. Ubuntu 24.04 LTS चा HWE kernel 27 August 2026 रोजीच्या 24.04.5 point release सह 7.0 वर जाण्याचे नियोजन आहे. 7.1 मधील fixes जुन्या line मध्ये backports म्हणून तुमच्यापर्यंत पोहोचतील. Features सहसा पोहोचणार नाहीत.

Linux 7.1 मधील कोणत्या बदलांचा virtual private server वर प्रत्यक्ष परिणाम होतो?

चार बाबी महत्त्वाच्या आहेत. Hardware queue leasing मुळे container ला native speed ने AF_XDP साठी एक वास्तविक NIC queue वापरता येते. Swap rework च्या तिसऱ्या टप्प्यात static swap map काढून टाकला आहे. त्यामुळे kernel तुमच्या swap device साठी ठेवत असलेला metadata प्रकाशित अहवालानुसार 30% ने कमी होतो. MGLRU page young flags चे batches मध्ये परीक्षण करू शकते. अनेक cores असलेल्या Arm server वर याचा सर्वाधिक प्रकाशित फायदा दिसतो. तसेच clone3() मध्ये CLONE_AUTOREAP, CLONE_NNP आणि CLONE_PIDFD_AUTOKILL समाविष्ट झाले आहेत. त्यामुळे child processes चे supervision अधिक सुरक्षित होते. Filesystem-level T10 protection information देखील समाविष्ट करण्यात आले आहे. मात्र virtual disk आवश्यक integrity metadata क्वचितच उपलब्ध करून देते.

Kernel upgrade केल्याने माझा VPS बंद पडेल का?

सामान्य अपयश boot वेळी होतात. पूर्ण /boot मुळे installation दरम्यान update-initramfs हे No space left on device सह fail होऊ शकते आणि package अर्धवट configured राहू शकते. जुने kernels sudo apt autoremove --purge वापरून काढा आणि त्यानंतर reinstall करा. जुन्या kernel विरुद्ध build केलेले out-of-tree modules load होणे थांबवतात. त्यामुळे DKMS द्वारे व्यवस्थापित कोणतेही घटक पुन्हा build करावे लागतात. Rebuild fail झाल्यास runtime वेळी module missing होईपर्यंत ते दिसून येत नाही. तसेच reboot नंतर uname -r जुन्या version चीच नोंद करत असेल आणि dpkg -l नवीन image दाखवत असेल, तर installation मध्ये काही बिघाड झालेला नाही. Bootloader default बदललेला नाही.