Adopt ZFSOnLinux SPL

[ryao]

Many of the issues porting DTrace and ZFS appear to be the same. Duplication of effort could be avoided if dtrace4linux adopted the ZFSOnLinux SPL.

I am opening this issue as a suggestion and to solicit feedback on the concept. Collaboration between the two projects would probably enable us to tackle openzfs/zfs#645 by creating a ZFS DTrace provider.

[dtrace4linux]

Sounds like an interesting idea. Remind me in a couple of weeks. Tx
On 7 Aug 2013 13:22, "Richard Yao" notifications@github.com wrote:

Many of the issues porting DTrace and ZFS appear to be the same.
Duplication of effort could be avoided if dtrace4linux adopted the
ZFSOnLinux SPL.

I am opening this issue as a suggestion and to solicit feedback on the
concept. Collaboration between the two projects would probably enable us to
tackle openzfs/zfs#645 https://github.com/zfsonlinux/zfs/issues/645by creating a ZFS Dtrace provider.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/65
.

[rca]

I thought of this while writing a blog post. Using the SPL would make porting easier and isolates kernel-level hacks to a single reusable library.

👍

[dtrace4linux]

The SPL would have been good a while back but am not sure I understand why
its worth it now. DTrace itself is relatively tiny - its like a black box
which attaches itself to the kernel. To make source level probes to the
kernel is easy - just do them, after dropping in a relevant dtrace.h header
to define the macros.

I obviously now need to look at the SPL - so send me the link to it so I
can take a look.

Yes - it would be good for zfs + dtrace to coexist.

thanks

PS I havent touched dtrace in a while - am waiting for the next ubuntu
release to address the linux 3.10+ compile issues - they should be minor to
address. Maybe I will look at doing a sample kernel code modification
provider to demo the proof of concept for others to mimic.

On 9 October 2013 21:27, Roberto Aguilar notifications@github.com wrote:

I thought of this while writing a blog post. Using the SPL would make
porting easier and isolates kernel-level hacks to a single reusable library.

[image: 👍]

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/65#issuecomment-26005551
.

[cjdelisle]

https://github.com/zfsonlinux/spl

Just to say my small piece, I think it would be really cool if SPL can help
dtrace progress faster. I think you'll find it offers little things like
hrtime() which are possible to implement but annoying, esp. when the kernel
guys are not making any effort to avoid breaking internal things.

Thanks,
Caleb

On 10/09/2013 04:59 PM, dtrace4linux wrote:

The SPL would have been good a while back but am not sure I understand why
its worth it now. DTrace itself is relatively tiny - its like a black box
which attaches itself to the kernel. To make source level probes to the
kernel is easy - just do them, after dropping in a relevant dtrace.h header
to define the macros.

I obviously now need to look at the SPL - so send me the link to it so I
can take a look.

Yes - it would be good for zfs + dtrace to coexist.

thanks

PS I havent touched dtrace in a while - am waiting for the next ubuntu
release to address the linux 3.10+ compile issues - they should be minor to
address. Maybe I will look at doing a sample kernel code modification
provider to demo the proof of concept for others to mimic.

On 9 October 2013 21:27, Roberto Aguilar notifications@github.com wrote:

I thought of this while writing a blog post. Using the SPL would make
porting easier and isolates kernel-level hacks to a single reusable library.

[image: 👍]

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/65#issuecomment-26005551
.

—
Reply to this email directly or view it on GitHub #65 (comment).

[dtrace4linux]

I dont understand. All these things exist in linux dtrace. Or are they
broken?
On 9 Oct 2013 22:04, "Caleb James DeLisle" notifications@github.com wrote:

https://github.com/zfsonlinux/spl

Just to say my small piece, I think it would be really cool if SPL can help
dtrace progress faster. I think you'll find it offers little things like
hrtime() which are possible to implement but annoying, esp. when the kernel
guys are not making any effort to avoid breaking internal things.

Thanks,
Caleb

On 10/09/2013 04:59 PM, dtrace4linux wrote:

The SPL would have been good a while back but am not sure I understand
why
its worth it now. DTrace itself is relatively tiny - its like a black box
which attaches itself to the kernel. To make source level probes to the
kernel is easy - just do them, after dropping in a relevant dtrace.h
header
to define the macros.

I obviously now need to look at the SPL - so send me the link to it so I
can take a look.

Yes - it would be good for zfs + dtrace to coexist.

thanks

PS I havent touched dtrace in a while - am waiting for the next ubuntu
release to address the linux 3.10+ compile issues - they should be minor
to
address. Maybe I will look at doing a sample kernel code modification
provider to demo the proof of concept for others to mimic.

On 9 October 2013 21:27, Roberto Aguilar notifications@github.com
wrote:

I thought of this while writing a blog post. Using the SPL would make
porting easier and isolates kernel-level hacks to a single reusable
library.

[image: 👍]

—
Reply to this email directly or view it on GitHub<
https://github.com/dtrace4linux/linux/issues/65#issuecomment-26005551>
.

—
Reply to this email directly or view it on GitHub <
https://github.com/dtrace4linux/linux/issues/65#issuecomment-26008209>.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/65#issuecomment-26008579
.

[rca]

Imagine being able to grab the latest version of dtrace and have it just work with no modification. This is what the SPL aims to provide. For example, the SPL has addressed Linux 3.10 compatibility for you. Compile against it and you get that for free.

Hope this helps!

[dtrace4linux]

Am still missing something. It normally takes less than an hour to have
linux on a new kernel. The delay fir me is holding out a while else theres
an explosion of vms I keep.

How old a kernel does spl work with?

Isnt there a delay...whether its mine or spl in supporting the newer
kernels?

Does spl support inter cpu/ipi calls without using the kernel mechanism?
On 9 Oct 2013 22:22, "Roberto Aguilar" notifications@github.com wrote:

Imagine being able to grab the latest version of dtrace and have it just
work with no modification. This is what the SPL aims to provide. For
example, the SPL has addressed Linux 3.10 compatibilityhttps://github.com/zfsonlinux/spl/pull/257for you. Compile against it and you get that for free.

Hope this helps!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/65#issuecomment-26009969
.

[dtrace4linux]

I just grabbed spl-0.62 to see what it is - all makes sense.

But another question for the audience:

If dtrace uses spl, you wont be able to use dtrace on spl - dtrace is
totally self contained and should work with spl/zfs fine.

I dont understand the request or question being posed. If the goal is to
enhance spl and merge the features of dtrace's kernel emulation with spl -
that makes sense.

Happy to explore more.

On 9 October 2013 22:33, Paul Fox paul.d.fox@gmail.com wrote:

Am still missing something. It normally takes less than an hour to have
linux on a new kernel. The delay fir me is holding out a while else theres
an explosion of vms I keep.

How old a kernel does spl work with?

Isnt there a delay...whether its mine or spl in supporting the newer
kernels?

Does spl support inter cpu/ipi calls without using the kernel mechanism?
On 9 Oct 2013 22:22, "Roberto Aguilar" notifications@github.com wrote:

Imagine being able to grab the latest version of dtrace and have it just
work with no modification. This is what the SPL aims to provide. For
example, the SPL has addressed Linux 3.10 compatibilityhttps://github.com/zfsonlinux/spl/pull/257for you. Compile against it and you get that for free.

Hope this helps!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/65#issuecomment-26009969
.

[rca]

Using dtrace on SPL sounds cool. At this point you are over my head, I'm no kernel hacker. :)

[dtrace4linux]

hi Roberto,

the point is that, as of today (plus or minus my upcoming linux 3.10
changes), you can run zfs and dtrace at the same time (in theory), and use
dtrace to probe/monitor or debug zfs.

Its possible that dtrace doesnt work on some kernels or configs - and am
happy to see that. (Eg I had to do extra work on Amazon EC2 due to the
nature of their VMs).

I will likely install zfs on one of my vm's to validate it works.What
people are hoping for (as I read it) is that if dtrace adopts spl, it will
help zfs. My assertion is that this isnt directly true. What may help zfs
is the ability to install static probes. I suspect this requires a little
more work than to just adopt spl since it requires the kernel to have the
probe section in the linker output area (not a major issue, but requires a
little work), and for dtrace to then read that (or leverage /proc/kallsyms
and the user level helper that dtrace4linux has to find the probes).

On 9 October 2013 22:55, Roberto Aguilar notifications@github.com wrote:

Using dtrace on SPL sounds cool. At this point you are over my head, I'm
no kernel hacker. :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/65#issuecomment-26012371
.

[ryao]

I do not think the ability to use DTrace on the SPL is a function anyone is using. Right now, the dtrace4linux code is not really in a state where it can be packaged by various Linux distributions due to the unique way that it is loaded into the kernel. Hooking into the spl should be able to alleviate that, which is probably a larger benefit.

On Oct 9, 2013, at 5:55 PM, Roberto Aguilar notifications@github.com wrote:

Using dtrace on SPL sounds cool. At this point you are over my head, I'm no kernel hacker. :)

—
Reply to this email directly or view it on GitHub.

[ryao]

We have probes for the DTrace ZFS provider in ZFSOnLinux, but they are not wired to anything right now. The same goes for the soon to be added SDT probes in openzfs/zfs#1775.

On Oct 9, 2013, at 6:03 PM, dtrace4linux notifications@github.com wrote:

hi Roberto,

the point is that, as of today (plus or minus my upcoming linux 3.10
changes), you can run zfs and dtrace at the same time (in theory), and use
dtrace to probe/monitor or debug zfs.

Its possible that dtrace doesnt work on some kernels or configs - and am
happy to see that. (Eg I had to do extra work on Amazon EC2 due to the
nature of their VMs).

I will likely install zfs on one of my vm's to validate it works.What
people are hoping for (as I read it) is that if dtrace adopts spl, it will
help zfs. My assertion is that this isnt directly true. What may help zfs
is the ability to install static probes. I suspect this requires a little
more work than to just adopt spl since it requires the kernel to have the
probe section in the linker output area (not a major issue, but requires a
little work), and for dtrace to then read that (or leverage /proc/kallsyms
and the user level helper that dtrace4linux has to find the probes).

On 9 October 2013 22:55, Roberto Aguilar notifications@github.com wrote:

Using dtrace on SPL sounds cool. At this point you are over my head, I'm
no kernel hacker. :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/65#issuecomment-26012371
.

—
Reply to this email directly or view it on GitHub.

[cjdelisle]

I personally was hoping that some of the great momentum in the ZoL project could rub off on dtrace4linux. If some of the redundancy between dtrace4linux and SPL could be eliminated then that would of course be awesome since the LLNL guys are dedicated to maintaining SPL and given the number of people using ZoL it will probably be guaranteed to have better support in terms of kernel versions and architectures. Also possibly some of the kernel functions which dtrace needs but ZFS doesn't could be moved into SPL where they would get more attention if they had unit tests.
I had this idea before but I didn't want to bring it up because I am not in a position to donate any code to the project.