Linux kernel 7.1-এ server-এর জন্য নতুন কী

Linux kernel 7.1-এ নতুন কী

Linux kernel 7.1 14 June 2026-এ প্রকাশিত হয়, 7.0-এর নয় সপ্তাহ পরে। VPS (virtual private server) ব্যবহারকারীর জন্য গুরুত্বপূর্ণ পরিবর্তনগুলো চারটি ক্ষেত্রে রয়েছে: storage ও filesystem, networking, memory management এবং process ও container control। Release-এর বাকি অংশের বেশিরভাগই desktop ও graphics-সংক্রান্ত কাজ, যা headless server সাধারণত লোড করে না।

তবে এর আগে আপনাকে আরেকটি বিষয় জানতে হবে। আপনার server-এ 7.1 চলার সম্ভাবনা প্রায় নেই, এবং দীর্ঘ সময় তা চলবেও না। kernel.org 7.1-কে longterm release হিসেবে তালিকাভুক্ত করেনি। 11 August 2026 অনুযায়ী longterm line হলো 6.18, 6.12, 6.6, 6.1, 5.15 এবং 5.10। mainstream server distribution-গুলো এই line-গুলোর কোনো একটির ওপর ভিত্তি করে তৈরি হয়, অথবা নিজেদের রক্ষণাবেক্ষণ করা কোনো line ব্যবহার করে। "kernel-এ নতুন" এবং "আপনার server-এ নতুন"—এই দুইয়ের মধ্যে কয়েক বছরের ব্যবধান থাকতে পারে। তাই এই guide-এ উভয় দিকই ব্যাখ্যা করা হয়েছে।

আপনার 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-এ পরবর্তী kernel থেকে backport করা হাজারো fix থাকে। তাই এটি Linus 2024 সালের March-এ 6.8 হিসেবে tag করা code নয়। এ কারণেই “আমার kernel পুরোনো” কথাটি শুনতে যতটা অর্থবহ মনে হয়, বাস্তবে ততটা নয়। Feature-গুলো পুরোনো। তবে security fix সাধারণত পুরোনো নয়।

systemd-detect-virt জানায় আপনি kernel পরিবর্তন করতে পারবেন কি না। সম্পূর্ণ virtual machine-এ, যেখানে আপনি নিজের kernel image boot করেন এবং upgrade সত্যিকারের upgrade, সেখানে এটি kvm দেখায়। Container virtualisation-এ, যেখানে host kernel ভাগ করা হয়, সেখানে এটি lxc অথবা openvz দেখায়। Container plan-এ uname -r provider-এর kernel দেখায়। Kernel package install করলেও boot করার মতো কোনো পরিবর্তন হয় না। Provider host-কে নতুন kernel-এ reboot না করা পর্যন্ত এই release-এর কোনো feature আপনার জন্য available হবে না। 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টি platform এবং এর একটিও 7.1 boot করে না। সবচেয়ে নতুনটি হলো Ubuntu 26.04 LTS (7.0), যা upstream release হিসেবে 1টি release পিছিয়ে আছে। এখনও support-এ থাকা সবচেয়ে পুরোনোটি 26টি release পিছিয়ে আছে। Ubuntu 24.04-এর default GA kernel 13টি release পিছনে রয়েছে। Debian 13 এবং RHEL 10 6.12 longterm line-এ 9টি release পিছনে রয়েছে। Release গোনা একটি আনুমানিক পরিমাপ, কারণ এতে distribution-গুলোর backport করা সবকিছু ধরা পড়ে না। তবে এটি ব্যবধানের সামগ্রিক চিত্র দেখায়। এই platform-গুলোর কোনটি চালাবেন তা বিবেচনা করলে, server-এ LTS এবং interim release-এর পার্থক্য-ই এই সংখ্যাগুলোর অন্তর্নিহিত সিদ্ধান্ত।

7.1-এ storage ও filesystem

7.1-এ block layer-এ সীমাবদ্ধ না থেকে filesystem-এর ভেতরেই T10 PI (protection information) তৈরি ও যাচাই করার সুবিধা যোগ হয়েছে। এর সঙ্গে নমনীয় T10 alignment support-ও এসেছে। T10 PI হলো প্রতিটি block-এর সঙ্গে যুক্ত অতিরিক্ত byte। এতে একটি checksum এবং data কোন block-এর অন্তর্ভুক্ত তা শনাক্ত করার একটি tag থাকে। ফলে misdirected write বা torn write শনাক্ত হয় এবং সেটিকে সঠিক data হিসেবে ফেরত দেওয়া হয় না। VPS tenant-এর ক্ষেত্রে সীমাবদ্ধতা হলো hardware। Device-কে integrity metadata প্রকাশ করতে হয়, কিন্তু virtual disk সাধারণত তা প্রকাশ করে না।

ls /sys/block/vda/integrity/

বেশিরভাগ VPS disk-এ এটি No such file or directory ফেরত দেয়। কারণ device integrity support নিবন্ধন করলেই block layer integrity directory তৈরি করে। এখানে ওই error-ই স্বাভাবিক ফলাফল; এটি কোনো ত্রুটি নয়। Storage feature নিয়ে আরও পড়ার আগে আপনার disk আসলে কী ধরনের তা জানতে VPS disk সত্যিই NVMe কি না পরীক্ষা করা জরুরি। আর VPS-এ NVMe ও SATA SSD-এর পার্থক্য ব্যাখ্যা করে কেন এই উত্তর আপনার সংখ্যাগুলো পরিবর্তন করে।

Btrfs-এ memory pressure-এর সময় copy-on-write amplification কমানোর জন্য সংশোধন এসেছে। Tracked range-এর প্রথম extent পরিষ্কার করার কাজও দ্রুত হয়েছে। সংশ্লিষ্ট merge-এ উল্লেখ করা sample workload-এ throughput 10% বেড়েছে। এর shutdown operation-কে আর experimental হিসেবে চিহ্নিত করা হয় না। XFS-এ iomap-এর মাধ্যমে zero range flushing ও lookup উন্নত হয়েছে। Real-time group geometry-তে একটি write pointer-ও যোগ হয়েছে, যা zoned device-এর জন্য ভিত্তি তৈরি করে। এই release-এ NTFS সম্পূর্ণভাবে পুনর্লিখিত হয়েছে। এতে পূর্ণ write support এবং iomap conversion রয়েছে। Server-এ Windows machine-এর disk image mount করতে হলে এটি গুরুত্বপূর্ণ।

আরও কিছু ছোট storage পরিবর্তন জানা দরকার: ublk, অর্থাৎ user-space block driver, zero-copy I/O পেয়েছে; io_uring-এ SCSI passthrough command যোগ হয়েছে; SED-OPAL self-encrypting drive support-এ STACK_RESET command এবং extended single user mode যোগ হয়েছে; direct-access device-এর জন্য নতুন fs-dax character driver এসেছে; এবং VFS inode->i_ino-কে unsigned long থেকে u64 পর্যন্ত বিস্তৃত করেছে, ফলে 32-bit build-এ inode number-এর সীমা দূর হয়েছে। Network filesystem-এর ক্ষেত্রে in-kernel NFS server এখন sign_fh mount option-এর মাধ্যমে তার file handle sign করতে পারে। CIFS client-এ O_TMPFILE support যোগ হয়েছে।

Networking: queue leasing এবং এটি container-কে যা দেয়

Networking-এর প্রধান পরিবর্তন হলো hardware queue leasing। একটি virtual netdev এখন physical netdev-এর একটি real queue-এর সঙ্গে bound থাকা queue lease করতে এবং সেটির proxy হিসেবে কাজ করতে পারে। এর উদ্দেশ্য container। এতদিন AF_XDP (address family express data path, এমন socket type যা network stack-এর মধ্য দিয়ে copy না করে raw packet সরাসরি user space-এ দেয়) ব্যবহার করতে চাওয়া container-কে প্রায় পুরো device-ই দিতে হতো। Leased queue ব্যবহার করলে এটি একটি hardware queue পায়, native speed-এ AF_XDP এবং memory provider চালায়, আর host NIC-এর বাকি অংশ ধরে রাখে। এটি io_uring-এর zero-copy path-এ AF_XDP support-এর পাশাপাশি যুক্ত হয়েছে।

সাধারণ ব্যবহারের ক্ষেত্রে sockfs-এর socket এখন user.* extended attribute গ্রহণ করে। Path-based AF_UNIX socket তার নিচের filesystem থেকে xattr support উত্তরাধিকারসূত্রে পেত, কিন্তু শুধু sockfs-এ থাকা socket-এর কোনো xattr ছিল না। এখন একটি process socket-এ label দিতে পারে, এবং একটি eBPF program সেই label অনুযায়ী filter করতে পারে।

দুটি অপসারণ করা হয়েছে। কোনো ব্যবহারকারী না পাওয়ায় UDP-Lite বাদ দেওয়া হয়েছে। IPv6 আর loadable module হিসেবে build করা যাবে না: IPv6 চাইলে এটি kernel-এ compiled in থাকতে হবে। দ্বিতীয় পরিবর্তনটি কোনো distribution kernel-এ চোখে পড়বে না, কারণ সাধারণ server distribution-গুলো IPv6 আগে থেকেই kernel-এ build করে।

মেমরি ব্যবস্থাপনা: swap table সম্পূর্ণ হয়েছে

swap পুনর্গঠন তৃতীয় পর্যায়ে পৌঁছেছে। এই পর্যায়ে static swap map সরানো হয়েছে। এখন swap count সরাসরি swap table-এ থাকে। প্রকাশিত হিসাব অনুযায়ী, static swap metadata-এর প্রায় 30% সাশ্রয় হয়। kernel আপনার swap device-এর আকারের অনুপাতে এই মেমরি ধরে রাখে, কিছু swap করা হোক বা না হোক। ছোট swap file-এর ক্ষেত্রে পরিমাণটি মোট হিসেবে কম। আপনি যত বেশি swap configure করবেন, এটি তত বাড়বে।

MGLRU (multi-generational least recently used, নতুন page reclaim algorithm) এখন একবারে একটি page পরীক্ষা না করে batch আকারে page-এর young flag পরীক্ষা করতে পারে। এই পরিবর্তনের সঙ্গে প্রকাশিত পরিমাপে Arm64 32-core server-এ 60%-এর বেশি উন্নতি দেখা গেছে। প্রতি-page খরচ যেখানে বেশি, সেখানে batching সবচেয়ে বেশি সুবিধা দেয়। এ কারণেই এই সংখ্যা একটি বড় Arm machine-এ পাওয়া হয়েছে। আপনি যদি x86-এর বদলে একটি Arm VPS ব্যবহার করেন, তাহলে 7.1-এর মধ্যে এটিই আপনার নিজস্ব measurement-এ সবচেয়ে বেশি ধরা পড়ার সম্ভাবনা রয়েছে। তবে দুই বা চারটি core-এ সেই মাত্রার উন্নতি নাও দেখা যেতে পারে।

এখানে আরও কিছু পরিবর্তন আছে: dying memory cgroup থেকে transfer বন্ধ হয়েছে, khugepaged এখন কম CPU ব্যবহার করে scan চালায়, এবং maple tree-এর বড় node handling নিয়ে বড় refactor হয়েছে। এগুলোর কোনোটি configure করতে হয় না। system time সামান্য কমে গেলে আপনি এগুলোর প্রভাব বুঝতে পারবেন।

Scheduler: sched_ext সাব-scheduler এবং ডিফল্টভাবে সক্রিয় FRED

sched_ext হলো একটি extensible scheduler class, যার মাধ্যমে BPF program হিসেবে CPU scheduler লিখে runtime-এ load করা যায়। এটি 6.12-এ যুক্ত হয়েছিল। 7.1-এ sub-scheduler-এর জন্য core structure যুক্ত হয়েছে। এর ফলে ভবিষ্যতে কোনো control group নিজস্ব scheduler-এর অধীনে চলতে পারবে। বাক্যটি সতর্কভাবে পড়ুন। 7.1-এ implementation এখনও সম্পূর্ণ হয়নি। বিশেষ করে enqueue path এখনও অনুপস্থিত। তাই এটি পরবর্তী release-এর ভিত্তি তৈরি করছে, আজই সক্রিয় করে ব্যবহার করার মতো feature নয়।

যে hardware এটি সমর্থন করে, সেখানে Intel FRED (flexible return and event delivery) এখন ডিফল্টভাবে enabled। FRED পুরোনো x86 event delivery path-এর বদলে আরও সরল একটি path ব্যবহার করে। এটি 6.9 থেকে kernel-এ ছিল, তবে fred=on boot argument-এর আড়ালে। এখন এটিকে ডিফল্টভাবে on করা হয়েছে। এর অর্থ হলো shipping hardware-এ যথেষ্ট testing করা হয়েছে বলে ধরা হচ্ছে। এখন পর্যন্ত প্রকাশিত measurement-এ I/O-heavy workload-এ 4% থেকে 7% উন্নতি দেখা গেছে। এই ফল client silicon-এ Phoronix-এর testing থেকে এসেছে। তাই নিজের workload মেপে না নেওয়া পর্যন্ত server-এর জন্য একই উন্নতি ধরে budget করবেন না।

Proxy execution remote lock owner-কে boost করার জন্য donor migration support পেয়েছে। EEVDF negative lag-সংক্রান্ত fixes পেয়েছে। High-resolution timer core-ও উল্লেখযোগ্যভাবে rewrite করা হয়েছে। এগুলো latency quality উন্নত করে, তবে কোনো configuration file থেকে এগুলো নিয়ন্ত্রণ করা যায় না।

clone3()-এ নতুন process ও container নিয়ন্ত্রণ

clone3()-এ তিনটি flag যোগ করা হয়েছে। প্রতিটি flag এমন একটি সীমাবদ্ধতা দূর করে, যেটি supervisor-গুলো বহু বছর ধরে হাতে পরিচালনা করে আসছিল। CLONE_AUTOREAP child-কে exit করার সময় নিজেই reap করতে দেয়। ফলে এমন parent-এর জন্য child zombie হয়ে অপেক্ষা করে না, যে হয়তো কখনো wait() call করবে না। CLONE_NNP child তৈরির সময়ই তার জন্য no_new_privs সেট করে। এতে clone এবং child নিজে flag সেট করার মধ্যবর্তী সময়ের ঝুঁকি দূর হয়। CLONE_PIDFD_AUTOKILL child-এর lifetime-কে parent-এর কাছে ফেরত দেওয়া pidfd-এর সঙ্গে যুক্ত করে। pidfd বন্ধ করলে child-কে kill করা হয়। তাই supervisor বন্ধ হয়ে গেলেও orphan process চলতে থাকে না।

Mount namespace-এও একই ধরনের সুবিধা যোগ হয়েছে। CLONE_EMPTY_MNTNS for clone3() এবং UNSHARE_EMPTY_MNTNS for unshare() কোনো mount ছাড়াই একটি mount namespace তৈরি করে। সাধারণত parent-এর mount-গুলোর সম্পূর্ণ copy তৈরি হয়, যেগুলো runtime-কে পরে unmount করতে হয়। FSMOUNT_NAMESPACE fsmount()-কে সরাসরি একটি নতুন namespace-এ filesystem স্থাপন করতে দেয়। Container runtime-গুলো এক দশক ধরে এটি হাতে তৈরি করে আসছে। এখন এক call-এ কাজটি করা যায়। ফলে runtime-কে আর host-এর mount-এ পূর্ণ একটি namespace থেকে শুরু করতে হয় না।

Virtualisation-এর ক্ষেত্রে guest_memfd এখন userfaultfd সমর্থন করে। ফলে hypervisor user space থেকে guest page fault পরিচালনা করতে পারে। Arm-এ Protected KVM anonymous memory সমর্থন পেয়েছে। তবে merge-এর বর্ণনাতেই বলা হয়েছে যে এটি production-এর জন্য এখনো প্রস্তুত নয়।

কখন kernel 7.1 আপনার সার্ভারে পৌঁছাবে

Fedora-তে এটি ইতিমধ্যেই আছে। Fedora 44 update repository 2026 সালের July ও August মাসে 7.1 series-এ চলে যায়, কারণ একটি release-এর মধ্যে Fedora তার kernel-কে নতুন stable line-এ rebase করে। একই কারণে Arch এবং openSUSE Tumbleweed-এও এটি আছে। এগুলো পরীক্ষার জন্য ব্যবহার করুন, service চালানোর জন্য নয়।

অন্য সবাইকে অপেক্ষা করতে হয়, এবং এই অপেক্ষা পরিকল্পিত। Debian 13 6.12 নিয়ে released হয়েছে এবং release-এর পুরো সময় 6.12-তেই থাকে; এতে fix backport করা হয়। RHEL 10 6.12.0 নিয়ে released হয়েছে এবং একই পদ্ধতি অনুসরণ করে। Ubuntu 26.04 LTS April 2026-এ 7.0 নিয়ে released হয়েছে। Ubuntu 24.04 LTS-এ hardware enablement stack আছে। এটি পরবর্তী Ubuntu release থেকে নতুন kernel LTS-এ নিয়ে আসে। 24.04.4 point release অনুযায়ী সেই stack 6.17-এ আছে এবং 27 August 2026-এ প্রকাশিতব্য 24.04.5-এর সঙ্গে 7.0-এ যাওয়ার কথা।

এখানেই অনেকে ভুল বোঝেন। HWE stack সর্বশেষ interim release-এ থাকা kernel-এ চলে যায়। ফলে এটি upstream-এর কোনো একটি line সম্পূর্ণভাবে এড়িয়ে যেতে পারে। 7.0 একটি Ubuntu LTS-এ আছে। 7.1 কোনো LTS-এর base নাও হতে পারে, কারণ এর পরের interim release আরও পরের একটি line বহন করবে। 7.1 থেকে আপনার LTS-এ যা পৌঁছায়, তা হলো fix; এগুলো আপনি যে line ব্যবহার করছেন তাতে backport করা হয়। Feature-গুলো মূলত আগের line-এই থেকে যায়।

আপনি যদি stable server-এ নতুন 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

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-এ পুরোনো version দেখা গেলেও dpkg -l-এ নতুনটি তালিকাভুক্ত থাকলে package installed হয়েছে, কিন্তু bootloader-এর default পরিবর্তিত হয়নি: GRUB menu entry পরীক্ষা করুন। /var/run/reboot-required বিদ্যমান থাকলে বোঝায় কোনো package kernel upgrade করেছে, কিন্তু এরপর আর reboot হয়নি। Patched server এখনও vulnerable code চালানোর সবচেয়ে সাধারণ কারণ এটি।

production VPS-এ 7.1 অনুসরণ করা উচিত কি

না। এর কারণ শুধু সতর্কতা অবলম্বন করা নয়। একটি distribution kernel হলো support contract। Canonical, Red Hat, SUSE এবং Debian তাদের frozen line-এ security fix backport করে এবং সেই kernel-এর সঙ্গে সরবরাহ করা userspace-এর বিরুদ্ধে সেগুলো পরীক্ষা করে। তৃতীয় পক্ষের archive থেকে নেওয়া mainline kernel বা নিজে build করা kernel আপনাকে নতুন feature দেয়, কিন্তু এই কাজটি আপনার ওপর ছেড়ে দেয়; কারণ আপনার build-এ কেউ fix backport করছে না। ফলে kernel রক্ষণাবেক্ষণের দায়িত্ব আপনার।

ব্যতিক্রম আছে, তবে সেগুলো সীমিত: পুরোনো kernel যে hardware চালাতে পারে না, অথবা নিজের workload-এ পরিমাপ করা এমন কোনো performance পরিবর্তন, যার পরিণতির দায়িত্ব নেওয়ার মতো যথেষ্ট প্রয়োজন আপনার আছে। VPS-এ প্রথম ব্যতিক্রমটি প্রায় কখনো প্রযোজ্য নয়, কারণ আপনি যে hardware দেখেন তা virtual। অন্য সব ক্ষেত্রে distribution kernel আপ-to-date রাখুন এবং এটি reboot করতে বললে reboot করুন। distribution upgrade যদি আপনার তালিকায় আগে থেকেই থাকে, তাহলে Ubuntu 24.04 থেকে 26.04-এ আপগ্রেড করলে এক ধাপেই 6.8 থেকে 7.0-এ যেতে পারবেন; এটি যেকোনো একক kernel package-এর দেওয়া পরিবর্তনের চেয়ে বড় upgrade।

FAQ

কোন Linux kernel-এ আমার VPS চলছে, তা কীভাবে পরীক্ষা করব?

uname -r চালান। এটি 6.8.0-79-generic-এর মতো কিছু দেখাবে। প্রথম dash-এর আগের সংখ্যাটি হলো আপনার distribution যে upstream line-এর ওপর ভিত্তি করে তৈরি, আর এর পরের পুরো অংশটি distribution-এর নিজস্ব build number, যেখানে backported fix থাকে। এরপর systemd-detect-virt চালান। এটি lxc অথবা openvz দেখালে আপনি container virtualisation-এ আছেন। আপনি host-এর kernel ভাগ করে ব্যবহার করছেন এবং এটি পরিবর্তন করতে পারবেন না। এটি kvm দেখালে আপনি নিজের kernel image boot করছেন এবং upgrade আপনাকেই করতে হবে।

Linux 7.1 কি longterm support kernel?

না। 11 August 2026 অনুযায়ী kernel.org-এ তালিকাভুক্ত longterm line হলো 6.18, 6.12, 6.6, 6.1, 5.15 এবং 5.10। 7.1 এই তালিকায় নেই। এটি একটি সাধারণ stable release। পরবর্তী mainline release প্রকাশের অল্প সময় পর এর stable line বাদ দেওয়া হয়। বহু বছর ধরে fix পাওয়া এবং সামনে আরও বহু বছর fix পাওয়া kernel চাইলে, আপনার distribution-এর kernel-ই ইতিমধ্যে সেই ধরনের।

Ubuntu বা Debian কখন kernel 7.1 প্রকাশ করবে?

সম্ভবত কখনোই default হিসেবে নয়। Debian 13 পুরো release lifecycle-এ 6.12-তেই থাকবে, আর RHEL 10 থাকবে 6.12.0-এ। Ubuntu 26.04 LTS 7.0 নিয়ে প্রকাশিত হয়েছে। 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-এর fix পুরোনো line-এ backport হয়ে আপনার কাছে পৌঁছাবে। Feature সাধারণত পৌঁছাবে না।

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 batch আকারে page young flag পরীক্ষা করতে পারে। বহু-core Arm server-এ এর সর্বোচ্চ প্রকাশিত উন্নতি দেখা গেছে। আর clone3()-এ CLONE_AUTOREAP, CLONE_NNP এবং CLONE_PIDFD_AUTOKILL যোগ হয়েছে, যা child process supervise করা আরও নিরাপদ করে। Filesystem-level T10 protection information-ও যোগ হয়েছে। তবে virtual disk সাধারণত এর প্রয়োজনীয় integrity metadata প্রকাশ করে না।

Kernel upgrade করলে কি আমার VPS নষ্ট হতে পারে?

সাধারণ ব্যর্থতাগুলো boot-এর সময় ঘটে। একটি সম্পূর্ণ /boot installation-এর সময় update-initramfs-কে No space left on device দিয়ে ব্যর্থ করায় এবং package-কে half-configured অবস্থায় রেখে দেয়। পুরোনো kernel sudo apt autoremove --purge দিয়ে সরিয়ে তারপর packageটি reinstall করুন। পুরোনো kernel-এর বিরুদ্ধে তৈরি out-of-tree module আর load হবে না। তাই DKMS দ্বারা পরিচালিত সবকিছুকে rebuild করতে হবে। Rebuild ব্যর্থ হলে runtime-এ module অনুপস্থিত না হওয়া পর্যন্ত তা নীরবে থেকে যেতে পারে। এছাড়া reboot-এর পরেও uname -r পুরোনো version দেখালে, অথচ dpkg -l নতুন image তালিকাভুক্ত করলে installation-এ কিছু নষ্ট হয়নি। Bootloader-এর default পরিবর্তিত হয়নি।