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 সাধারণত load করে না।

তবে এর আগে আপনাকে আরেকটি বিষয় জানতে হবে। আপনার 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-গুলোর কোনো একটির ওপর, অথবা distribution নিজে রক্ষণাবেক্ষণ করা কোনো 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 shared থাকে, এটি lxc বা openvz দেখায়। Container plan-এ uname -r provider-এর kernel দেখায়। Kernel package install করলেও আপনি যে kernel boot করতে পারবেন, তাতে কোনো পরিবর্তন হয় না। Provider নতুন kernel দিয়ে host reboot না করা পর্যন্ত এই release-এর কোনো feature আপনার জন্য available হবে না। Kernel-সংক্রান্ত কাজের পরিকল্পনা করার আগে এই check চালান।

[
  {
    "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 করা সবকিছু ধরা পড়ে না। তবে gap-টির চিত্র বোঝা যায়। এই platform-গুলোর মধ্যে কোনটি চালাবেন তা বিবেচনা করলে, server-এ LTS বনাম interim release ব্যবহারের trade-off-ই এই সংখ্যাগুলোর অন্তর্নিহিত সিদ্ধান্ত।

7.1-এ storage ও filesystem

7.1-এ শুধু block layer-এ নয়, filesystem-এর ভেতরেও T10 PI (protection information) তৈরি ও যাচাই করার সুবিধা যোগ হয়েছে। এর সঙ্গে নমনীয় T10 alignment support-ও রয়েছে। T10 PI হলো প্রতিটি block-এর সঙ্গে যুক্ত অতিরিক্ত byte। এতে একটি checksum এবং data কোন block-এর অন্তর্ভুক্ত তা শনাক্ত করার একটি tag থাকে। ফলে ভুল block-এ নির্দেশিত write বা অসম্পূর্ণ 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-ই স্বাভাবিক ফল, কোনো fault নয়। Storage feature নিয়ে আরও পড়ার আগে আপনার disk আসলে কী ধরনের তা জানতে VPS disk আসলে NVMe কি না পরীক্ষা করা জরুরি। আর VPS-এ NVMe ও SATA SSD-এর পার্থক্য ব্যাখ্যা করে কেন এর ফলে আপনার সংখ্যাগুলো বদলে যায়।

Btrfs-এ memory pressure-এর সময় copy-on-write amplification কমানোর জন্য fix যোগ হয়েছে। Tracked range-এর প্রথম extent clear করার গতি বাড়ানোর জন্যও পরিবর্তন এসেছে। Merge-এ উল্লেখ করা sample workload-এ throughput 10% বেড়েছে বলে জানানো হয়েছে। এর shutdown operation-কে আর experimental হিসেবে চিহ্নিত করা হয় না। XFS-এ iomap-এর মাধ্যমে zero range flushing ও lookup উন্নত হয়েছে। Zoned device-এর ভিত্তি তৈরির জন্য real-time group geometry-তে write pointer যোগ হয়েছে। এই release-এ NTFS সম্পূর্ণভাবে পুনর্লিখিত হয়েছে। এতে full write support এবং iomap conversion রয়েছে। Windows machine থেকে কোনো disk image আপনার server-এ 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 সমর্থন করতে শিখেছে।

নেটওয়ার্কিং: queue leasing এবং container-এর সুবিধা

নেটওয়ার্কিংয়ে প্রধান পরিবর্তন হলো hardware queue leasing। এখন একটি virtual netdev এমন একটি queue lease করতে পারে, যা physical netdev-এর একটি real queue-এর সঙ্গে bound থাকে। এটি সেই queue-এর proxy হিসেবে কাজ করতে পারে। এর উদ্দেশ্য container। আগে AF_XDP (address family express data path; এটি এমন socket type, যা network stack-এর মাধ্যমে raw packet copy না করে সরাসরি user space-এ দেয়) ব্যবহার করতে চাওয়া container-কে প্রায় পুরো device দিতে হতো। এখন leased queue ব্যবহার করে container একটি 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 support ছিল না। এখন একটি process socket-এ label দিতে পারে, এবং একটি eBPF program সেই label অনুযায়ী filter করতে পারে।

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

মেমরি ব্যবস্থাপনা: swap table-এর কাজ শেষ

swap পুনর্গঠন তৃতীয় পর্যায়ে পৌঁছেছে। এই পর্যায়ে static swap map সরিয়ে ফেলা হয়েছে। এখন swap count সরাসরি swap table-এ থাকে। প্রকাশিত হিসাব অনুযায়ী static swap metadata-এর প্রায় 30% মেমরি সাশ্রয় হবে। আপনি কিছু swap ব্যবহার না করলেও kernel আপনার swap device-এর আকারের অনুপাতে এই মেমরি ধরে রাখে। ছোট 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 পরিচালনা নিয়ে বড় refactor হয়েছে। এগুলোর কোনোটি আপনাকে configure করতে হবে না। system time সামান্য কম লাগার মাধ্যমে আপনি এগুলোর প্রভাব বুঝতে পারবেন।

Schedulers: sched_ext সাব-সিডিউলার এবং ডিফল্টভাবে চালু FRED

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

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

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

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

clone3()-এ তিনটি flag যোগ করা হয়েছে। প্রতিটি flag এমন একটি সীমাবদ্ধতা দূর করে, যেটি supervisor-রা বহু বছর ধরে হাতে সমাধান করে আসছিলেন। 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 process চলতে থাকে না।

Mount namespace-এর ক্ষেত্রেও একই ধরনের পরিবর্তন এসেছে। clone3()-এর জন্য CLONE_EMPTY_MNTNS এবং unshare()-এর জন্য UNSHARE_EMPTY_MNTNS এমন একটি 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 নতুন stable line অনুযায়ী kernel rebase করে। একই কারণে Arch এবং openSUSE Tumbleweed-এও এটি আছে। এগুলো পরীক্ষা চালানোর মেশিন, আপনার service চালানোর মেশিন নয়।

অন্য সবাইকে অপেক্ষা করতে হবে, এবং এই অপেক্ষা পরিকল্পিত। Debian 13 6.12 নিয়ে প্রকাশিত হয়েছে এবং release-এর পুরো জীবনকাল 6.12-তেই থাকবে; এর মধ্যে fix backport করা হবে। RHEL 10 6.12.0 নিয়ে প্রকাশিত হয়েছে এবং একই পদ্ধতি অনুসরণ করে। Ubuntu 26.04 LTS 2026 সালের April মাসে 7.0 নিয়ে প্রকাশিত হয়েছে। 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-এ যাওয়ার কথা। Point release Ubuntu-এর নতুন version নয়। এতে শুধু একই 24.04-এর সঙ্গে তখন পর্যন্ত প্রকাশিত সব update নতুন install media-তে যুক্ত থাকে। তাই আপনি ইতিমধ্যে patch করা server-এ 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 থেকে আপনার LTS-এ যা পৌঁছায়, তা হলো fix; এগুলো আপনি যে line ব্যবহার করছেন তাতে backport করা হয়। Feature-গুলো সাধারণত অন্তর্ভুক্ত হয় না।

আপনি যদি 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-এ নতুন version থাকলে 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 প্রত্যেকে তাদের স্থির release line-এ security fix backport করে এবং সেই kernel-এর সঙ্গে সরবরাহ করা userspace-এর বিরুদ্ধে পরীক্ষা করে। Third-party archive-এর mainline kernel বা নিজে build করা kernel আপনাকে নতুন feature দেয়, কিন্তু সেই কাজের দায়িত্ব আপনার ওপর দেয়; কারণ আপনার build-এ কেউ fix backport করছে না। আপনিই kernel-এর maintainer হয়ে যান।

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

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 release করবে?

সম্ভবত default হিসেবে কখনও নয়। Debian 13 release-এর পুরো জীবনচক্রে 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-এর fix আপনার কাছে পুরোনো line-এ backport হিসেবে পৌঁছাবে। Feature সাধারণত পৌঁছাবে না।

Linux 7.1-এর কোন বিষয়গুলো virtual private server-এ বাস্তবে গুরুত্বপূর্ণ?

চারটি বিষয় গুরুত্বপূর্ণ। Hardware queue leasing container-কে native speed-এ AF_XDP ব্যবহারের জন্য একটি বাস্তব NIC queue ব্যবহার করতে দেয়। Swap rework-এর তৃতীয় phase static swap map সরিয়ে দেয় এবং kernel আপনার swap device-এর জন্য যে metadata ধরে রাখে, তা প্রকাশিত হিসাবে 30% কমায়। MGLRU page-এর young flag batch আকারে পরীক্ষা করতে পারে। বহু-core Arm server-এ এর সর্বোচ্চ প্রকাশিত performance gain দেখা গেছে। এছাড়া 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 হলে install-এর সময় update-initramfs, No space left on device-সহ ব্যর্থ হয় এবং package half configured অবস্থায় থেকে যায়। sudo apt autoremove --purge দিয়ে পুরোনো kernel সরান, তারপর package reinstall করুন। পুরোনো kernel-এর বিরুদ্ধে তৈরি out-of-tree module আর load হবে না। তাই DKMS দ্বারা পরিচালিত সবকিছু rebuild করতে হবে। Rebuild ব্যর্থ হলে runtime-এ module অনুপস্থিত না হওয়া পর্যন্ত তা নীরবে থেকে যেতে পারে। Reboot-এর পরেও uname -r পুরোনো version দেখালে, অথচ dpkg -l নতুন image তালিকাভুক্ত করলে install-এ কোনো সমস্যা হয়নি। Bootloader-এর default পরিবর্তিত হয়নি।