SSD Nodes Learn Hosting plans →
Hướng dẫn Matt ConnorBởi Matt Connor · Cập nhật ngày 2026-08-23

Linux kernel 7.1 có gì mới cho server và VPS?

Linux kernel 7.1 phát hành ngày 14 June 2026, nhưng VPS của bạn có thể chưa chạy bản này. Xem thay đổi, cách kiểm tra kernel và lịch distro cập nhật.

Có gì mới trong Linux kernel 7.1

Linux kernel 7.1 được phát hành vào ngày 14 June 2026, 9 tuần sau bản 7.0. Với người thuê VPS (virtual private server), những thay đổi đáng chú ý tập trung vào 4 nhóm: storage và filesystem, networking, memory management, cùng process và container control. Phần còn lại của bản phát hành chủ yếu là các thay đổi cho desktop và graphics, vốn không được headless server tải lên.

Trước tiên, bạn cần biết thêm một điều. Gần như chắc chắn server của bạn chưa chạy 7.1, và sẽ còn lâu mới chạy. kernel.org không liệt kê 7.1 là bản longterm. Tính đến ngày 11 August 2026, các dòng longterm là 6.18, 6.12, 6.6, 6.1, 5.15 và 5.10. Mọi server distribution phổ biến đều xây dựng trên một trong các dòng này hoặc trên một dòng do chính distribution đó duy trì. “Mới trong kernel” và “mới trên server của bạn” có thể cách nhau nhiều năm, vì vậy hướng dẫn này bao quát cả 2 khía cạnh.

VPS của bạn hiện đang chạy kernel nào

uname -r
uname -srm
systemd-detect-virt

uname -r in ra release của kernel đang chạy. Trên Ubuntu 24.04, kết quả có dạng 6.8.0-79-generic. Phần trước dấu gạch ngang đầu tiên là dòng upstream. Mọi thứ phía sau là số build riêng của distribution và hoàn toàn không phản ánh upstream. Kernel 6.8.0-79 của Canonical chứa hàng nghìn bản sửa lỗi được backport từ các kernel mới hơn, nên đó không phải là code mà Linus gắn tag 6.8 vào tháng 3 năm 2024. Vì vậy, câu “kernel của tôi cũ” không cho biết nhiều như vẻ ngoài của nó. Các feature có thể cũ. Nhưng bản sửa lỗi bảo mật thường không cũ.

systemd-detect-virt cho biết bạn có thể thay đổi kernel hay không. Lệnh này in ra kvm trên một virtual machine đầy đủ, nơi bạn boot kernel image của riêng mình và việc upgrade thực sự thay đổi kernel. Lệnh này in ra lxc hoặc openvz trên container virtualisation, nơi kernel của host được dùng chung. Trên gói container, uname -r hiển thị kernel của provider; cài kernel package không thay đổi bất cứ thứ gì bạn có thể boot, và không feature nào trong release này khả dụng cho đến khi provider reboot host lên kernel mới hơn. Hãy chạy kiểm tra này trước khi lên kế hoạch thực hiện bất kỳ thay đổi nào với kernel.

ChartDefault server kernel by platform, and upstream releases behind 7.1, checked 11 August 2026
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"
  }
]

Đó là 6 platform, và không platform nào trong số đó boot kernel 7.1. Bản mới nhất là Ubuntu 26.04 LTS (7.0), vẫn chậm hơn 1 upstream release. Bản cũ nhất vẫn còn được support chậm hơn 26 release. Kernel GA mặc định của Ubuntu 24.04 chậm hơn 13 release, còn Debian 13 và RHEL 10 chậm hơn 9 release trên dòng 6.12 longterm. Đếm số release chỉ là cách đo tương đối, vì cách này bỏ qua mọi thứ mà các distribution backport, nhưng nó cho thấy khoảng cách có dạng như thế nào. Nếu bạn đang cân nhắc chạy bản nào trong số này, sự đánh đổi giữa LTS và interim release trên server mới là quyết định nằm sau các con số này.

Lưu trữ và filesystem trong 7.1

7.1 bổ sung khả năng tạo và xác minh T10 PI (protection information) bên trong filesystem thay vì chỉ ở block layer, cùng với hỗ trợ căn chỉnh T10 linh hoạt. T10 PI là các byte bổ sung gắn với từng block. Chúng chứa checksum và một tag xác định dữ liệu thuộc về block nào, nhờ đó phát hiện thao tác ghi nhầm đích hoặc ghi dang dở thay vì trả dữ liệu lỗi về như dữ liệu hợp lệ. Vấn đề đối với tenant VPS nằm ở phần cứng. Device phải expose metadata về tính toàn vẹn, trong khi virtual disk thường không expose metadata này.

ls /sys/block/vda/integrity/

Trên hầu hết disk VPS, lệnh đó trả về No such file or directory, vì block layer chỉ tạo directory integrity khi device đăng ký hỗ trợ integrity. Lỗi này là kết quả bình thường trong trường hợp này, không phải sự cố. Nếu muốn biết chính xác loại disk trước khi đọc tiếp về các tính năng storage, hãy kiểm tra xem disk VPS có thực sự là NVMe hay không trước. Phần khác biệt giữa NVMe và SATA SSD trên VPS giải thích vì sao kết quả ảnh hưởng đến các con số của bạn.

Btrfs được sửa lỗi để giảm copy-on-write amplification khi thiếu memory, đồng thời bổ sung thay đổi giúp tăng tốc việc xóa extent đầu tiên trong một range được theo dõi. Merge tương ứng ghi nhận throughput tăng 10% trên workload mẫu. Hoạt động shutdown của Btrfs không còn bị đánh dấu là experimental. XFS cải thiện việc flush zero range và lookup thông qua iomap, đồng thời thêm write pointer vào real-time group geometry. Đây là phần nền tảng cho zoned device. NTFS được viết lại hoàn toàn trong bản release này, có đầy đủ hỗ trợ ghi và chuyển đổi sang iomap. Điều này hữu ích nếu bạn cần mount disk image từ một máy Windows trên server.

Một số thay đổi nhỏ về storage cũng đáng biết: ublk, block driver chạy trong user space, được bổ sung zero-copy I/O; io_uring hỗ trợ SCSI passthrough command; hỗ trợ SED-OPAL self-encrypting drive được bổ sung command STACK_RESET và extended single-user mode; có driver ký tự fs-dax mới cho device truy cập trực tiếp; VFS mở rộng inode->i_ino từ unsigned long lên u64, loại bỏ giới hạn số inode trên các bản build 32-bit. Ở phía network filesystem, NFS server trong kernel hiện có thể ký file handle thông qua tùy chọn mount sign_fh, còn CIFS client được bổ sung O_TMPFILE.

Networking: thuê queue và những gì container nhận được

Thay đổi lớn nhất về networking là cơ chế thuê queue phần cứng. Một virtual netdev giờ có thể thuê một queue được gắn với queue thật trên physical netdev và hoạt động như proxy cho queue đó. Mục đích chính là hỗ trợ container. Trước đây, container cần AF_XDP (address family express data path, loại socket chuyển packet thô trực tiếp vào user space mà không sao chép qua network stack) gần như phải được cấp toàn bộ device. Với queue được thuê, container nhận một hardware queue, chạy AF_XDP và memory provider ở tốc độ native, còn host giữ phần còn lại của NIC. Tính năng này được bổ sung cùng với hỗ trợ AF_XDP trong zero-copy path của io_uring.

Ở phía thông thường hơn, socket trong sockfs giờ chấp nhận user.* extended attributes. AF_UNIX socket dựa trên path vốn đã kế thừa hỗ trợ xattr từ filesystem bên dưới, nhưng socket chỉ tồn tại trong sockfs thì không có hỗ trợ này. Giờ một process có thể gắn label cho socket, và một chương trình eBPF có thể filter theo label đó.

Có 2 tính năng bị loại bỏ. UDP-Lite bị xóa vì không có người dùng. IPv6 không còn có thể được build dưới dạng loadable module: nếu muốn dùng IPv6, phải compile IPv6 trực tiếp vào kernel. Thay đổi thứ hai không thể thấy trên kernel của các distribution, vì các distribution phổ biến cho server vốn đã build IPv6 trực tiếp vào kernel.

Quản lý bộ nhớ: swap table đã hoàn tất

Công việc cải tiến swap bước sang giai đoạn thứ ba. Giai đoạn này loại bỏ static swap map. Số lượng swap giờ được lưu trực tiếp trong swap table. Mức tiết kiệm được công bố là khoảng 30% phần static swap metadata. Đây là phần bộ nhớ kernel phải giữ theo kích thước của swap device, dù có dữ liệu được swap hay không. Xét theo dung lượng tuyệt đối, con số này nhỏ trên một swap file nhỏ và tăng theo dung lượng swap bạn cấu hình.

MGLRU (multi-generational least recently used, thuật toán page reclaim mới hơn) giờ có thể kiểm tra young flag trên các page theo batch thay vì từng page một. Số liệu được công bố cho thấy mức cải thiện hơn 60% trên server Arm64 32-core. Batch mang lại hiệu quả lớn nhất ở nơi chi phí xử lý từng page cao nhất. Vì vậy, con số này được đo trên một máy Arm lớn. Nếu bạn chạy VPS Arm thay vì VPS x86, đây là thay đổi trong 7.1 có khả năng thể hiện rõ nhất qua các phép đo của bạn, dù trên máy 2 hoặc 4 core sẽ không đạt mức đó.

Ngoài ra còn có các thay đổi sau: việc chuyển dữ liệu ra khỏi memory cgroup đang bị dừng đã được loại bỏ, khugepaged scan với ít CPU hơn, và maple tree được refactor lớn quanh cơ chế xử lý big node. Bạn không cần cấu hình những thay đổi này. Bạn sẽ nhận thấy chúng dưới dạng system time giảm nhẹ.

Bộ lập lịch: bộ lập lịch con sched_ext và FRED được bật mặc định

sched_ext là lớp bộ lập lịch có thể mở rộng, cho phép bạn viết bộ lập lịch CPU dưới dạng chương trình BPF rồi nạp vào lúc runtime. Tính năng này được đưa vào kernel từ 6.12. Bản 7.1 bổ sung cấu trúc lõi cho bộ lập lịch con, để sau này một control group có thể chạy bằng bộ lập lịch riêng. Hãy đọc kỹ câu này. Phần triển khai chưa hoàn tất trong 7.1, đặc biệt là còn thiếu đường dẫn enqueue. Đây là phần nền tảng cho một bản phát hành sau, không phải tính năng có thể bật ngay hôm nay.

Intel FRED (flexible return and event delivery) hiện được bật mặc định trên phần cứng hỗ trợ tính năng này. FRED thay thế đường dẫn phân phối event x86 cũ bằng một đường dẫn gọn hơn. Tính năng này đã có trong kernel từ 6.9 và trước đây phải bật bằng boot argument fred=on. Việc chuyển sang bật mặc định cho thấy phần cứng đang được phát hành đã được kiểm thử đủ. Các số liệu được công bố đến nay, trong khoảng 4% đến 7% trên workload nặng I/O, đến từ bài kiểm thử của Phoronix trên client silicon. Vì vậy, không nên dự trù mức cải thiện này cho server trước khi đo trên workload của chính bạn.

Proxy execution được bổ sung donor migration để tăng mức ưu tiên cho remote lock owner. EEVDF được sửa các vấn đề liên quan đến negative lag. Phần lõi của high-resolution timer cũng được viết lại đáng kể. Đây là các thay đổi về chất lượng latency mà không có file cấu hình nào cung cấp tùy chọn điều chỉnh.

Các cơ chế kiểm soát process và container mới trong clone3()

Ba flag đã được thêm vào clone3(). Mỗi flag đều khắc phục một thiếu sót mà các supervisor phải xử lý thủ công trong nhiều năm. CLONE_AUTOREAP khiến child tự reap chính nó khi thoát. Vì vậy, child không trở thành zombie và chờ một parent có thể không bao giờ gọi wait(). CLONE_NNP đặt no_new_privs cho child ngay khi tạo. Điều này loại bỏ khoảng thời gian giữa lúc clone và lúc child tự đặt flag cho chính nó. CLONE_PIDFD_AUTOKILL liên kết vòng đời của child với pidfd trả về cho parent: đóng pidfd thì child bị kill. Vì vậy, nếu supervisor bị dừng, nó không thể để lại các process mồ côi tiếp tục chạy.

Mount namespace cũng được xử lý tương tự. CLONE_EMPTY_MNTNS cho clone3() và UNSHARE_EMPTY_MNTNS cho unshare() tạo một mount namespace không chứa gì, thay vì sao chép đầy đủ các mount của parent như cách thông thường, rồi runtime phải unmount từng mount. FSMOUNT_NAMESPACE cho phép fsmount() đưa filesystem trực tiếp vào namespace mới. Container runtime đã phải tự lắp ghép cơ chế này trong một thập kỷ. Khi thực hiện bằng một system call, runtime không còn phải bắt đầu từ một namespace chứa đầy đủ mount của host.

Ở phía virtualisation, guest_memfd hiện hỗ trợ userfaultfd. Vì vậy, hypervisor có thể xử lý page fault của guest từ user space. KVM được bảo vệ trên Arm đã hỗ trợ anonymous memory. Chính phần merge cũng nêu rõ tính năng này chưa sẵn sàng cho môi trường production.

Khi nào kernel 7.1 đến server của bạn

Fedora đã có kernel này. Repository update của Fedora 44 chuyển sang series 7.1 trong tháng 7 và tháng 8 năm 2026, vì Fedora rebase kernel lên các nhánh stable mới trong suốt vòng đời một release. Arch và openSUSE Tumbleweed cũng có kernel này vì lý do tương tự. Đây là những máy để test, không phải máy để chạy service.

Mọi bản phân phối khác đều phải chờ, và việc chờ này là có chủ đích. Debian 13 phát hành cùng 6.12 và giữ nguyên 6.12 trong suốt vòng đời release, đồng thời backport các bản sửa lỗi vào đó. RHEL 10 phát hành cùng 6.12.0 và cũng làm như vậy. Ubuntu 26.04 LTS phát hành cùng 7.0 vào tháng 4 năm 2026. Ubuntu 24.04 LTS có hardware enablement stack, cho phép lấy kernel mới hơn từ các release Ubuntu sau để đưa vào LTS. Stack này đang ở 6.17 kể từ point release 24.04.4 và dự kiến chuyển sang 7.0 cùng 24.04.5 vào ngày 27 tháng 8 năm 2026. Point release không phải là một version mới của Ubuntu. Đó vẫn là 24.04, chỉ khác là toàn bộ update từ trước được tích hợp vào bộ cài mới. Vì vậy, 24.04.5 thay đổi gì trên server mà bạn vẫn đang patch chính là kernel line của HWE và hầu như không có thay đổi nào khác.

Đây là phần nhiều người hiểu sai. HWE stack chuyển sang kernel mà interim release mới nhất đang dùng, nên có thể bỏ qua hoàn toàn một upstream line. 7.0 nằm trong một Ubuntu LTS. 7.1 có thể không bao giờ trở thành base của một LTS, vì interim release tiếp theo sẽ dùng một line mới hơn. Những gì từ 7.1 đến LTS của bạn là các bản sửa lỗi được backport vào line bạn đang dùng. Phần lớn feature vẫn không được đưa vào.

Nếu muốn dùng kernel mới hơn trên một server stable, bạn chỉ có vài cách được hỗ trợ.

# 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

Sau khi reboot, kiểm tra kernel thực sự đã được boot:

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

uname -r lúc này phải hiển thị line mới, còn dpkg -l hiển thị mọi kernel image vẫn đang được cài đặt. Nếu uname -r hiển thị version cũ trong khi dpkg -l liệt kê version mới, package đã được cài nhưng default của bootloader chưa thay đổi: hãy kiểm tra các entry trong menu GRUB. /var/run/reboot-required còn tồn tại nghĩa là một package đã upgrade kernel nhưng máy chưa reboot kể từ đó. Đây là lý do phổ biến nhất khiến một server đã được patch vẫn đang chạy đoạn code dễ bị tấn công.

Có nên chạy theo kernel 7.1 trên VPS production không

Không. Lý do không phải chỉ là thận trọng quá mức. Kernel của distribution đi kèm một cam kết hỗ trợ. Canonical, Red Hat, SUSE và Debian đều backport các bản sửa lỗi bảo mật vào dòng phiên bản cố định của họ, rồi kiểm thử chúng với userspace được phát hành cùng kernel đó. Mainline kernel từ archive bên thứ ba hoặc bản tự build cung cấp các tính năng mới nhưng loại bỏ phần công việc này, vì không ai backport bản sửa lỗi vào bản build của bạn. Bạn sẽ trở thành maintainer của một kernel.

Các trường hợp ngoại lệ là có thật nhưng rất hẹp: phần cứng mà kernel cũ không thể điều khiển, hoặc một thay đổi về hiệu năng đã được đo trên workload của chính bạn và đủ quan trọng để bạn chấp nhận tự chịu các hệ quả. Trên VPS, trường hợp đầu tiên gần như không xảy ra vì phần cứng bạn thấy là phần cứng ảo. Với mọi trường hợp khác, hãy giữ kernel của distribution ở trạng thái mới nhất và reboot khi hệ thống yêu cầu. Nếu đã có kế hoạch nâng cấp distribution, chuyển từ Ubuntu 24.04 lên 26.04 sẽ đưa bạn từ 6.8 lên 7.0 chỉ trong một bước. Đây là mức nhảy lớn hơn bất kỳ một kernel package riêng lẻ nào có thể cung cấp.

FAQ

Làm cách nào để kiểm tra VPS đang chạy Linux kernel nào?

Chạy uname -r. Lệnh này in ra dạng như 6.8.0-79-generic. Số đứng trước dấu gạch ngang đầu tiên là nhánh upstream mà distribution của bạn dựa trên. Phần còn lại là số build riêng của distribution, trong đó có các bản vá được backport. Sau đó chạy systemd-detect-virt. Nếu kết quả là lxc hoặc openvz, bạn đang dùng container virtualization, dùng chung kernel của host và không thể thay đổi kernel đó. Nếu kết quả là kvm, VPS boot kernel image riêng và bạn tự chịu trách nhiệm nâng cấp kernel.

Linux 7.1 có phải là kernel hỗ trợ dài hạn không?

Không. Tính đến ngày 11 tháng 8 năm 2026, các nhánh longterm được liệt kê trên kernel.org là 6.18, 6.12, 6.6, 6.1, 5.15 và 5.10; 7.1 không nằm trong danh sách này. Đây là một bản stable release thông thường. Nhánh stable của nó sẽ bị ngừng duy trì không lâu sau khi bản mainline tiếp theo được phát hành. Nếu bạn cần một kernel đã có nhiều năm bản vá và sẽ tiếp tục nhận bản vá trong nhiều năm nữa, kernel của distribution đã đáp ứng mục tiêu đó.

Ubuntu hoặc Debian sẽ phát hành kernel 7.1 khi nào?

Có lẽ sẽ không bao giờ dùng làm mặc định. Debian 13 giữ kernel 6.12 trong suốt vòng đời của bản release. RHEL 10 giữ kernel 6.12.0. Ubuntu 26.04 LTS phát hành với kernel 7.0. Ubuntu hardware enablement stack chuyển sang kernel mà bản interim release mới nhất đang dùng, nên có thể bỏ qua hoàn toàn một nhánh upstream. Ubuntu 24.04 LTS dự kiến chuyển HWE kernel sang 7.0 trong point release 24.04.5 vào ngày 27 tháng 8 năm 2026. Các bản vá từ 7.1 sẽ đến với bạn dưới dạng backport vào một nhánh cũ hơn. Các tính năng mới thường sẽ không được backport.

Những thay đổi nào trong Linux 7.1 thực sự quan trọng với virtual private server?

Có 4 điểm. Hardware queue leasing cho phép container dùng một real NIC queue cho AF_XDP ở tốc độ native. Giai đoạn thứ 3 của quá trình cải tiến swap loại bỏ static swap map và giảm 30% metadata mà kernel lưu cho swap device, theo số liệu được công bố. MGLRU có thể kiểm tra page young flag theo batch, với mức cải thiện được công bố lớn nhất trên Arm server có nhiều core. Và clone3() đã có thêm CLONE_AUTOREAP, CLONE_NNP và CLONE_PIDFD_AUTOKILL, giúp giám sát child process an toàn hơn. T10 protection information ở cấp filesystem cũng đã được bổ sung, nhưng virtual disk hiếm khi expose integrity metadata cần thiết cho tính năng này.

Nâng cấp kernel có làm VPS của tôi bị hỏng không?

Các lỗi thường xảy ra trong lúc boot. Một /boot đầy khiến update-initramfs fail với No space left on device trong quá trình cài đặt, làm package bị half-configured. Hãy xóa các kernel cũ bằng sudo apt autoremove --purge rồi cài đặt lại. Các module ngoài tree được build cho kernel cũ sẽ không còn load được. Vì vậy, mọi thứ do DKMS quản lý đều phải được build lại. Nếu quá trình build lại fail, lỗi có thể không xuất hiện cho đến khi module bị thiếu lúc runtime. Nếu sau khi reboot, uname -r vẫn báo version cũ trong khi dpkg -l liệt kê image mới, thì quá trình cài đặt không bị lỗi. Bootloader chưa thay đổi kernel mặc định.