{"id":122128,"date":"2025-02-28T02:22:05","date_gmt":"2025-02-28T00:22:05","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-yadre-linux-6-15-namereny-udalit-fajlovuyu-sistemu-systemv"},"modified":"2025-02-28T02:22:05","modified_gmt":"2025-02-28T00:22:05","slug":"v-yadre-linux-6-15-namereny-udalit-fajlovuyu-sistemu-systemv","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/v-yadre-linux-6-15-namereny-udalit-fajlovuyu-sistemu-systemv","title":{"rendered":"In the Linux 6.15 kernel, they intend to remove the SystemV file system.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Developer Jan Kara from SUSE has proposed a patch that removes the code supporting Xenix, SystemV\/386, and Coherent file systems from the Linux kernel. This code has been marked as orphaned since 2023, and no one has come forward to maintain it since then. Maintainer Christian Brauner, responsible for file systems in the kernel, agreed to the proposal and accepted the patch into the vfs-6.15 branch. A few hours ago, the content of vfs-6.15 was moved to the linux-next branch, where preparations for the upcoming 6.15 kernel are underway. <\/p>\n
The history began in 2002 when the Linux kernel was freed from the global lock (BKL \u2014 Big Kernel Lock) in favor of more granular locks. At that time, the SystemV file system transitioned to rwlock, but this led to issues that prevented the processor from entering sleep mode during the entire function call that read inode metadata. The problem was only noticed in 2023 as a result of stress testing with the SyzBot tool. This incident shows that the SystemV file system is not used by anyone and can be removed. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"