内容简介:Last Monday in the "Moderated Discussions" forum at realworldtech.com, Linus Torvalds—founding developer and current supreme maintainer of the Linux kernel—Given the massive weight automatically given Torvalds' words due to his status as founding developer
Last Monday in the "Moderated Discussions" forum at realworldtech.com, Linus Torvalds—founding developer and current supreme maintainer of the Linux kernel— answered a user's question about a year-old kernel maintenance controversy that heavily impacted the ZFS on Linux project. After answering the user's actual question, Torvalds went on to make inaccurate and damaging claims about the ZFS filesystem itself.
Given the massive weight automatically given Torvalds' words due to his status as founding developer and chief maintainer of the Linux kernel, we feel it's a good idea to explain both the controversial kernel change itself, and Torvalds' comments about both the change in question and the ZFS filesystem.
The original January 2019 controversy, explained
In January 2019, kernel developer Greg Kroah-Hartman decided to disable exporting certain kernel symbols to non-GPL loadable kernel modules.
For those whose heads are spinning, kernel symbol exports expose internal information about the kernel state to loadable kernel modules . The particular symbol being discussed here, _kernel_fpu_
, tracks the state of the processor's Floating Point Unit. Without access to that symbol, external kernel modules that access the FPU directly—as ZFS does—must implement state preservation code of their own. State preservation, whether in-kernel or native to kernel modules, makes sure that the original state of the FPU is restored before control is released to other kernel code that may be dependent on the values they last saw in the FPU's registers.
The technical impact of refusing to continue exporting the _kernel_fpu_
symbol is not to prevent modules from accessing the FPU directly—it only prevents them from using the kernel's own state-management facilities to preserve and restore state. Removing access to that symbol therefore requires module developers to reinvent their own state-preservation code individually. This increases the likelihood of catastrophic error within the kernel itself, since improperly restored state could cause a later kernel operation to crash.
Kroah-Hartman's decision to stop exporting the symbol to non-GPL kernel modules appeared to be driven largely by spite, as borne out by his own comment regarding the change: "my tolerance for ZFS is pretty non-existent." Normally, ZFS—on any platform, including the BSDs—uses SSE/AVX SIMD vector optimization to speed up certain operations. Without access to the _kernel_fpu_
symbol, ZFS developers were initially forced to disable the SIMD optimizations entirely, with fairly significant real-world performance degradation.
Although Kroah-Hartman's change initially spawned a lot of drama and uncertainty, the long-term impact on the Linux ZFS community was fairly minimal. The breaking change only affected bleeding-edge kernels that few ZFS users were using in production, and in July 2019 new, in-module state management code was committed to the ZFS on Linux source tree.
“We don’t break users”
Torvalds' position in last Monday's forum post starts out reasonable and well-informed—after all, he's Linus Torvalds, discussing the Linux kernel. He notes that the famous kernel mantra "we don't break users" is "literally about user-space applications"—and so it does not apply to Kroah-Hartman's decision to stop exporting kernel symbols to non-GPL kernel modules. By definition, if you're looking for a kernel symbol, you aren't a user-space application. The line being drawn here is a very bright and functional one: Torvalds is saying that if you want to run in kernel space, you need to keep up with kernel development.
From there, Torvalds branches out into license concerns, another topic on which he's accurate and reasonable. "Honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle," he writes. "Other people think it can be OK to merge ZFS code into the kernel and that the module interface makes it OK, and that's their decision. But considering Oracle's litigious nature, and the questions over licensing, there's no way I can feel safe in ever doing so."
He goes on to discuss the legally flimsy nature of the kernel module "shim" that the ZFS on Linux project (along with other non-GPL and non-weak-permissive projects, such as Nvidia's proprietary graphics drivers) use. There's some question as to whether they constitute a reasonable defense now— since nobody has challenged any project for using an AGPL shim for 20 years and running—but in purely logical terms, there isn't much question that the shims don't accomplish much. The real function of an AGPL kernel module shim isn't to sanction touching the kernel with non-GPL code, it's to protect the proprietary code on the far side of the shim from being forcibly published in the event of a GPL enforcement lawsuit victory.
So far, so good, but then Torvalds dips into his own impressions of ZFS itself, both as a project and a filesystem. This is where things go badly off the rails, as Torvalds states, "Don't use ZFS. It's that simple. It was always more of a buzzword than anything else, I feel... [the] benchmarks I've seen do not make ZFS look all that great. And as far as I can tell, it has no real maintenance behind it any more..."
“It was always more of a buzzword than anything else”
Further Reading
Bitrot and atomic COWs: Inside “next-gen” filesystemsto the status of "just buzzwords."
There's only one other widely available filesystem that even takes a respectable stab at providing most of those features, and that's btrfs—which was not available for the first several years of ZFS' general availability. In fact, btrfs still isn't really stable enough for production use, unless you nerf all the features that make it interesting in the first place.
ZFS' per-block checksumming and automatic data repair has prevented data loss in my own real-world use many times, including this particularly egregious case of a SATA controller gone rabid. A standard RAID1 mirror would have cheerfully returned that 119GB of bad data with no warning whatsoever, but ZFS' live checksumming and error detection mitigated the whole thing to the point of never having to so much as touch a backup.
Meanwhile, atomic snapshots make it possible to keep a full block-for-block identical copy of storage at a point in time with negligible performance overhead and minimal storage overhead—and replication of those snapshots is typically hundreds or thousands of times faster (and more reliable) than non-filesystem-integrated solutions like rsync.
It's possible to not have a personal need for ZFS. But to write it off as "more of a buzzword than anything else" seems to expose massive ignorance on the subject.
以上所述就是小编给大家介绍的《Linus Torvalds’ ZFS statements aren’t right—here’s the straight dope》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
离散数学及其应用(原书第6版·本科教学版)
[美] Kenneth H. Rosen / 袁崇义、屈婉玲、张桂芸 / 机械工业出版社 / 2011-11 / 49.00元
《离散数学及其应用》一书是介绍离散数学理论和方法的经典教材,已经成为采用率最高的离散数学教材,仅在美国就被600多所高校用作教材,并获得了极大的成功。第6版在前5版的基础上做了大量的改进,使其成为更有效的教学工具。 本书基于该书第6版进行改编,保留了国内离散数学课程涉及的基本内容,更加适合作为国内高校计算机及相关专业本科生的离散数学课程教材。本书的具体改编情况如下: · 补充了关于范式......一起来看看 《离散数学及其应用(原书第6版·本科教学版)》 这本书的介绍吧!
CSS 压缩/解压工具
在线压缩/解压 CSS 代码
JSON 在线解析
在线 JSON 格式化工具