With the final major capability for BPF tracing (timed sampling) merging in Linux 4.9-rc1, the Linux kernel now has raw capabilities similar to those provided by DTrace, the advanced tracer from Solaris. As a long time DTrace user and expert, this is an exciting milestone! On Linux, you can now analyze the performance of applications and the kernel using production-safe low-overhead custom tracing, with latency histograms, frequency counts, and more.
Ah, so Linux is finally on par with Solaris from 2006
Of course, it’s not really DTrace and it’s not even a compatible interface, so it’s unclear to me just yet if it’s really just as good, better, or worse.
Hey, you forgot about ZFS !
Seriously, Solaris was good on some things but horrible (on x86 hardware) on others. Give me Linux any day.
About ZFS, very nice capabilities for servers, a bit too demanding on Desktops (well, used to be, new Desktops are really fast and full of memory).
Well, much of the desktop problems with ZFS are self inflicted by not disabling active deduplication on machines with less memory (which could really be the default on installation, but most maintainers don’t seem to really have a good handle on ZFS anyways).
On UltraSparc, Linux is just a huge mess since most distros just cross compile everything, and have very minimal actual testing. I’m mostly using OpenBSD there, since they provide a MUCH more stable and well supported environment on UltraSparc than any Linux distro does.
I have never seen deduplication enabled by default on any system to date (FreeBSD, Linux). Which systems do this?
The non-dedup memory requirements of ZFS have always been way overblown. I think its because original (very rough) estimates of needed memory included dedup, and as other people repeated it around the internet, they dropped the “dedup” part.
FreeBSD with ZFS works comfortably on systems with 1GB of RAM, and with tuning, can work fine on 512MB or even 256MB configurations (Though, that tuning isn’t the default).
Yeah, this. On Solaris 10 and FreeBSD, I’ve never once had an issue.
I’ve heard that this idea that ZFS has crazy memory requirements (and deduplication being always on) comes from older AUR packages of ZFS, which were set up to enable deduplication by default. I had thought that some other packages did the same by default, but I’ve never used it on Linux outside Gentoo, so I can’t say if it really is that way or not.
In any case, I would wager that a vast majority of the people who say ZFS uses a ton of memory have never actually used ZFS to begin with.
Edited 2016-10-27 23:51 UTC
Even FreeBSD is a crashy, unstable mess on sparc64. OpenBSD’s strict no-cross-compiler policy is a godsend for my little Ultra 5.
I loved Solaris when I had to support it.
ZFS & Live Upgrade… ahh, I can sleep.
Well in fairness it does say, similar to those provided by DTrace.
Now Oracle Solaris must follow the lead and be on par with 2006’s Solaris!
I don’t know maybe We just had very bad luck at work… but what a mess were the latest releases of Solaris 11!!! We had dozens of really serious problems horrible bugs on production system.
I’m not a hater I’ve working with Solaris since early 2000s… never had so many problems as today. As I said, maybe it’s just my experience, some people love Solaris 11… to me it’s the worst release ever.
I always recommended Solaris over RHEL for mission critical system… I’m not sure about it anymore… SPARC hardware still is incredible and ultra reliable and way better than even the best x86 servers… but Solaris is a PITA.
DTrace was integrated in Mac OS X 10.5 in 2007.
OS X also had ZFS support around the same time.
Yeah, not sure how many people are running mission critical servers on macs these days. At least since the complete abandonment of the xserves. Anyone know if dtrace still works on OSX ?
It appears so.
Adam Leventhal (One of the three authors of dtrace) has a dtrace-centric blog, and he mentioned using it to investigate some of the new features of the Sierra beta, including APFS
http://dtrace.org/blogs/ahl/
Or you could use Oracle Linux which has had actual dtrace since 2011.
don’t know about hacking but when my ex was cheating on me, a friend of mine referred me to Mr Robert I thought it wasn’t real but he later proved me wrong by helping me to spy on my ex-husband and got me all the necessary evidence I needed. He helped me to hack and spy on his emails, mobile , all his social media and his bank accounts, Robert did all this remotely without touching his devices. You can contact him with [email protected] if you are in the same shoe as I was..
So, they’re ditching systemtap instead of fixing/extending it? I’ve seen people complain about how unstable it was, causing kernel panics in relatively common circumstances, but it seems that it would be better to fix that, rather than tell users that it’s time to ditch the work they’ve put in and start from scratch.
Though, that does seem to be SOP for how Linux is developed – see a feature in Unix/BSD, copy it rather poorly, ditch it, then copy it again to be more similar to the way Unix/BSD did it.
Well, it does seems a bit unfair to Linux developers to put things this way and I am sure there are lots of good tech invented in Linux circle but, being frank, most of the technical background around the basics an OS must have, how it should be layered and how it should operate, was already reasonably established when Linux was created.
Also, as there are many Linux developers all around the world, with many of them shooting for glory, there is a kind of rush to implement new ideas and we see the result of this on how quickly things are created, rewritten and even substituted. You don’t see, usually, this kind of vertiginous experience done on traditional Unix and I agree with you on that, it is more a kind of phenomenon you would meet on Linux side, not necessarily a bad thing, though.
Well, the entire Linux kernel is a copy of Unix. What do you expect? Original tech from Linux? I dont know of any original tech coming from Linux? What does Linux have invented that every OS wants and have copied or ported?
OTOH, everybody wants ZFS and DTrace and Containers and Crossbow and SMF, and…
For instance, take DTrace:
IBM AIX has a copy called ProbeVue
FreeBSD has ported it
Mac OS X has ported it
VMware has a copy called vProbes
QNX has ported it
Linux has copied it badly, and call it Systemtap.
Every major OS have copied or ported ZFS.
BTRFS is a linux copy of ZFS and it failed too.
systemd is a copy of SMF, Lennart talked about Solaris SMF all the time back then.
Dockers is a variant of Containers
Crossbow is copied and called… forgot the name
etc etc. What does Linux have that every OS lust and desire after? Any software?
https://www.usenix.org/legacy/events/lsf07/tech/rodeh.pdf
Both ZFS and Btrfs come out of the ideas of WALF
https://www.google.com/patents/US5819292
Yes NetApp patented the base idea that both ZFS and BTRFS use. ZFS does slab and BTRFS does b-tree implementation of the idea and I cannot remember what odd beast WALF does.
Dtrace and Systemtap is funny. Dtrace is started jan 2005 first prototypes of Systemtap starts as dprobes in jun 2004. So these two are parallel invention it possible Dtrace is copied the other way. Of course the idea of dprobes is based off extending strace into kernel space and strace was sun idea.
vprobes name is based of dprobes so that by vmware is not copy of Dtrace either.
Linux world does have habit of rename something and start over so the old interface can be deprecated.
What is be-compared as the Linux replacement to dtrace is http://www.brendangregg.com/blog/2016-03-05/linux-bpf-superpowers.h…
bpf trace tools. This in it self is interesting. Both systemtap and dtrace are are based around using a special language for tracing converted to native by user-space complier. Where bpf trace tools is recycling the Berkeley packet filter engine byte code to have kernel Berkeley packet filter jit in kernel turn it to native code.
So Linux developers as normal like renaming stuff. Solaris developers love extending stuff and not renaming it.
This kinda shows how it gets muddy. Sun developers helped porting Linux to sparc so they did take a few idea from Linux as well. With the Linux word renaming stuff so often its very easy to mix up who invented what.
Solaris/Sun has had some fine developers. Even that systemtap with dprobes and Dtrace started around the same time Sun got Dtrace production ready first.
I know that Linux has copied lot of Solaris stuff, but I have never seen Solaris copied Linux tech? What ideas of Linux have Solaris taken?
First of all, I too would like if the Linux folks would be less “happy” to start to code, specially on important aspects of the OS. When things are a bit more thought-out there is a bigger chance that most of the post implementation will end up on smaller corrections and incremental improvements instead of rewrites. As I said on an earlier post, there is a culture in Linux folks circle to be trigger-happy. As many already noted, Linux is created with engineering compromises in mind, i.e., to make things work, preferentially as soon as possible, instead of the more traditional computer science approach, i.e., get your “model” perfected first.
Anyway, all this effervescence around Linux created a phenomenal, fast pacing, OS development push around it that made it possible to support a lot of hardware much faster than any *BSD or Solaris on x86 hardware. It also pushed a lot of folks to implement the missing parts of the OS, like graphical interfaces, file management and lots of tools. Many of them end up finding their way to *BSD, Solaris and other Unix systems. It also brought the need to make things more manageable and so DEB and RPM were created and this is very relevant because package management sucked on Unix (understandable, as the focus of them were way stricter and the pressure to have a good system package management was less pressuring) and suddenly we had a “better” system on x86 hardware that were easier to manage and put to work on a large range of scenarios.
Don’t want to be pick but it seems to me that the argument of the original post is that the fundamental idea did not originate on Solaris. If that is true, it does not matter if the BTRFS guy knew it or not.
Also, because of the environment around Linux, many things got implemented in it, if not first, usually before others besides the OS where it started, the biggest known exceptions being Dtrace and ZFS.
See “https://en.wikipedia.org/wiki/Comparison_of_operating_system_kernels… or Google to the difference between Linux, *BSD and Solaris kernels. You will be surprised to find out the Linux may very well be the most complete/flexible OS of all.
Ohad Rodeh of IBM is the original Author of Btrfs and wrote the feature list Btrfs. Chris Mason currently has still not added a single feature to the feature list for Btrfs. Chris Mason is a person paid to implement Btrfs not its master designer. Ohad Rodeh knew of WALF and the link I gave was to Ohad Rodeh first presentation. Chris Mason take over development of Btrfs and due to Btrfs and ZFS being descendent of the WALF of course Chris Mason is comparing to it. Chris Mason is incorrectly credited with Btrfs invention because it was Chris Mason who got Btrfs good enough to merge.
So both Ohad Rodeh and Chris Mason play very important parts in Btrfs history.
https://www.diva-portal.org/smash/get/diva2:822493/FULLTEXT01.pdf
Also there is performance differences.
Systemtap can perform traces that Dtrace cannot by design.
BPF tracing do watch the video here
http://www.brendangregg.com/blog/2016-03-05/linux-bpf-superpowers.h…
He demos a few traces that neither Systemtap or Dtrace can perform.
In fact VProbes mentions the same problem performance. Dtrace design is not that high in the performance department. The reason why systemtap was removing references to Dtrace is Dtrace has a problem.
Brendan Gregg is not really making Dtrace part of Linux. Instead taking inspiration from Dtrace and making something superior to it.
The issue with Brendan Gregg heavy Dtrace background is most people are making the incorrect mistake he is porting Dtrace. Instead he is taking systemtap attempt to make something that performs better and can perform traces Dtrace cannot in fact work very well.
Calling stuff knockoffs as Dtrace developers have means they have not looked at what problems those making so call knockoffs were attempting to fix. The license issue was only 1 of many issues why you don’t want dtrace as is. The big one is performance.
ZFS design also appears to have a problem from performance side.
Please note ZFS is slab, Btrfs is b-tree and bcachefs is b+tree. So even that all 3 file systems are attempting to-do the same thing at the core all 3 are major different.
Linus might complain about Linux performance but that is mistake when you get solaris vs linux on a lot of things.
Jesus. That was one bad student thesis. He concludes that BTRFS is faster than ZFS. But he writes that Hegel saw the opposite, and wonders why (p32):
“The results from the experiment with the single disk setup conducted by Heger (2009) differs drastically from the results found in this thesis. In Heger’s experiment, ZFS outperformed Btrfs in all scenarios except for the sequential write operation where Btrfs had slightly higher throughput.”
Why is that Heger saw ZFS being faster than BTRFS? He did not know. Well, let me tell you why. The reason ZFS was faster is because Heger tested ZFS on Solaris vs BTRFS on Linux. This thesis tests ZFS on Linux vs BTRFS on Linux. And ZFS on Linux is not mature.
Also, thesis tests one disk, and four disks. Well, ZFS is built for scale, large servers. It scales to hundreds of disks. On large Petabyte ZFS installations, ZFS gets very high throughput. BTRFS is not built for such large servers, BTRFS is a desktop filesystem. BTRFS might be faster on a single disk, but when you scale up, ZFS sky rockets. For instance IBM Sequioa supercomputer has a large 55 Petabyte ZFS installation with 1 TB/sec read write throughput. And because BTRFS is broken, the largest BTRFS installation is probably one single disk or two disks. I dont think there are any petabyte BTRFS raids out there. BTRFS might be faster on a single disk, but ZFS is faster on many disks. ZFS scales. BTRFS does not. And BTRFS corrupts your data, ZFS protects your data.
ZFS has multiple layers internally, they are just ordered differently to “the common layering methodology” used in Linux. There’s two major layers (DMU, and DSL). Inside of each are also multiple layers, although they are treated the same from the outside.
The big difference is that Linux has a bazillion layers (physical, md, crypt, lvm, filesystem, to name a few) and umpteen different ways to layer them. ZFS hides all that internally, and just shows you a data management layer (how you arrange the physical disks into vdevs in a pool) and a filesystem layer. Everything else is handled internally.
Yes, it’s a single monolithic codebase; but it is clearly split into layers internally and data is passed between the layers using strictly defined interfaces. Same as the Linux storage stack … just ordered in a very different, and static, way.
Have you read the rest? The Linux developers say the code quality is bad. One of them even compares Solaris kernel code to Linux kernel code, and says that Solaris is very stable and superior. Linux is fast, but might crash any second. He says he is ashamed of the Linux code.
Its not that simple. That is Con Kolivas who said scheduler should not support cgroups that is solaris equal to zones. The range of hardware Linux supports compared to Solaris does bring in more different companies/developers with different coding styles into the source tree.
There is a price for everything.
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project
The reality is the Linux world is more open to change that does cause problems but it also gives advantages. The Linux Kernel Self Protection Project is implementing feature that Solaris does not have to limit the damage drivers and kernel parts can do. So yes Linux source code might be worse to read but runtime protections are already ahead of Solaris.
Edited 2016-11-02 01:12 UTC
And dont get me started on systemd. The Linux devs have not understood anything about Solaris SMF. systemd is a piece of junk, it has it’s own terminal and other stuff too.
If you had read the article, you would find info about SystemTap gaining eBPF backend – https://lkml.org/lkml/2016/6/14/749
Looking back, Solaris 10 was one of that OSs that set a technical reference.