121–130 of 571 posts
Until I have a viable alternative that gives me snapshotting (so I can make consistent backups), that advice is worthless to me.
Linus seems out of touch on this one IMHO.
Earlier quoted context omitted.
That's his reasoning for not merging ZFS code, not for generally avoiding ZFS.
Here are his reasons for generally avoiding ZFS from what I consider most important to least. - The kernel team may break it at any time, and won't care if they do. - It doesn't seem to be well-maintained. - Performance is not that great compared to the alternatives. - Using it opens you up to the threat of lawsuits from Oracle. Given history, this is a real threat. (This is one that should be high for Linus but not…
Earlier quoted context omitted.
Bcachefs is probably the only thing that will get there. The codebase is clean and we'll mantained, built from solid technology (bcache) and will include most of the ZFS niceties. I just wish more companies would sponsor de project and stop wasting money on BTRFS
>stop wasting money on BTRFS You're saying they should stop supporting a project that was considered stable by the time the other started being developed. Why do that? What makes Bcachefs a better choice?
After that, none of the features like compression, snapshots, COW or checksums meant anything to me. I'm much happier with ext4 and xfs on lvm.
Earlier quoted context omitted.
"Don't use ZFS. It's that simple. It was always more of a buzzword than anything else, I feel, and the licensing issues just make it a non-starter for me." When he says that, I think on the $500 million Sun spent on advertising java.
Sun isn't going to sue anyone into oblivion any time soon, but Oracle sure will
i wouldn't use ZFS either. my guess is 90% of ZFS users have never run failure scenarios and grappled with potential failure modes of ZFS, nor even know that you really need ECC RAM to run ZFS without fear of existential data corruption due to bit flips. furthermore, the allure of ZFS means people aren't testing their disaster plans until it's too late, bc ZFS is "resilient". lastly, data recovery is expensive as all…
https://arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=...
Here's his reasoning: "honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle that is signed by their main legal counsel or preferably by Larry Ellison himself that says that yes, it's ok to do so and treat the end result as GPL'd. 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…
> And I'm not at all interested in some "ZFS shim layer" thing either If there is no "approved" method for creating Linux drivers under licenses other than the GPL, that seems like a major problem that Linux should be working to address. Expecting all Linux drivers to be GPL-licensed is unrealistic and just leads to crappy user experiences. nVidia is never going to release full-featured GPL'd drivers, and even corpor…
A shim layer is a poor legal bet. It assumes that a judge who might not have much technical knowledge will agree that by putting this little technical trickery between the two incompatible works then somehow that turn it from being a single combined work into two cleanly separated works. It could work, but it could also very easily be seen as meaningless obfuscation.
> Why are all drivers expected to use the GPL
Because a driver is tightly depended on the kernel. It is this relationship that distinguish two works from a single work. A easy way to see this is how a music video work. If a create a file with a video part and a audio part, and distribute it, legally this will be seen as me distributing a single work. I also need to have additional copyright permission in order to create such derivative work, rights that goes beyond just distributing the different parts. If I would argue in court that I just am distributing two different works then the relationship between the video and the music would be put into question.
A userspace software is generally seen as independent work. One reason is that such software can run on multiple platforms, but the primary reason is that people simply don't see them as an extension of the kernel.
Earlier quoted context omitted.
On the surface, btrfs is pretty close to zfs. Once you actually use them, you discover all the ways that btrfs is a pain and zfs is a (minor) joy: - snapshot management - online scrub - data integrity - disk management I lost data from perfectly healthy-appearing btrfs systems twice. I've never lost data on maintained zfs systems, and I now trust a lot more data to zfs than I ever have to btrfs.
At least disk management is far easier with btrfs. You can restripe at will while zfs has severe limitations around resizing, adding and removing devices. Granted, at enterprise scale this hardly matters because you can just send-receive to rebuild pools if you have enough spares, but for consumer-grade deployments it's a non-negligible annoyance.
Maybe SV is different...
Earlier quoted context omitted.
But why are all drivers expected to be "part of the project"? We don't treat userspace Linux software that way. We don't consider Windows drivers part of Windows.
It's pretty simple, once they expose such an API they'd have to support it forever, hindering options for refactoring (that happens all the time). With all the drivers in the tree, they can simply update every driver at the same time to whatever new in-kernel API they're rolling out or removing. And being that the majority of drivers would arguably have to be GPL anyway, and thus open-source, the advantages of keepin…
Yes, which Linus has also poo-pooed:
"People who think that userspace filesystems are realistic for anything but toys are just misguided."
Earlier quoted context omitted.
Last time I used ZFS write performance was terrible compared to an ordinary RAID5. IIRC Writes in a raidz are always limited to a single disk’s performance. The only way to get better write speed is to combine multiple raidzs - which means you need a boatload if disks.
We had a bunch of Thumpers (SunFire X4200) with 48 disks at work, running ZFS on Solaris. It was dog slow and awful, tuning performance was complicated and took ages. One had to use just the right disks in just the right order in RaidZs with striping over them. Swap in a hotspare: things slow to a crawl (i.e. not even Gbit/s). After EoL a colleague installed Linux with dmraid, LVM and xfs on the same hardware: much f…