Live data from Hacker News

Show HN: ZFS Implementation in Python

github.com

71–80 of 97 posts

Re: Show HN: ZFS Implementation in Python

#71
post #55

Earlier quoted context omitted.

If you manage to do it would be awesome, otherwise thanks a lot anyway for the effort :) I’m just curious to understand why it happens because it’s exactly the opposite of what I would expect. The only explanation that comes to my mind is excessive gc as someone else already mentioned, but it would be interesting to see the original code.

I started doing it but yes, it's too much effort to get two full benchmarks, I'm sorry :). But I think it went down to the inefficiency of String.split(): https://stackoverflow.com/questions/37007189/string-split-te... and generally the Java's String built-in methods not being GC-friendly: https://stackoverflow.com/questions/20336459/garbage-friendl... . I'm guessing that when such parts can be coded in a non-VM envi…

[deleted]

Re: Show HN: ZFS Implementation in Python

#72

i love userspace implementations of filesystems. note that the issues are entirely different from those with a kernel implementation since you aren't having to think about page cache et all.

There is an userspace implementations of filesystems ZboxFS: https://github.com/zboxfs/zbox.

Re: Show HN: ZFS Implementation in Python

#73
post #53

Earlier quoted context omitted.

Fuse

If you're going to run the file system in user space, there's no reason not to just use normal ZFS. The problem with ZFS licensing is only in combining CDDL+GPL in one unit. If you're working across the kernel/userspace boundary, there's already no problem. ZoL even already ships a fuse version that works fine.

> ZoL even already ships a fuse version that works fine.

This is not true. A FUSE implementation is wanted though: https://github.com/zfsonlinux/zfs/issues/8

Re: Show HN: ZFS Implementation in Python

#74
post #41

Earlier quoted context omitted.

Faster that CPython doesn't mean it is fast.

I was trying to speed up a log processing service running on PyPy by rewriting it in Java. I was surprised that the result was about twice slower (I know Java quite well and I didn't see obvious optimizations; most of the time was spent in GC). So it can be quite fast even in more absolute terms (VM languages), at least for some types of code.

I would have expected it: https://stackoverflow.com/questions/9371238/why-is-reading-l...

Re: Show HN: ZFS Implementation in Python

#75

Earlier quoted context omitted.

If you're going to run the file system in user space, there's no reason not to just use normal ZFS. The problem with ZFS licensing is only in combining CDDL+GPL in one unit. If you're working across the kernel/userspace boundary, there's already no problem. ZoL even already ships a fuse version that works fine.

> ZoL even already ships a fuse version that works fine. This is not true. A FUSE implementation is wanted though: https://github.com/zfsonlinux/zfs/issues/8

Oops; I didn't realize the existing fuse version wasn't built from ZoL. Thanks for pointing that out.

Re: Show HN: ZFS Implementation in Python

#76

Earlier quoted context omitted.

It's clear to me that the solution is to integrate python into the kernel.

I assume you mean this as a joke, but I would point out that at least one of the BSD family has gone and baked lua into their kernel. Granted, lua is rather meant for that kind of thing and python isn't, but it is entertaining to point out an interpreted language that has been stuck into a unix kernel:)

there was lua in linux too, with lunatik https://github.com/lunatik-ng/lunatik-ng

Re: Show HN: ZFS Implementation in Python

#77
post #68

Earlier quoted context omitted.

One of my favorite short stories, and nobody else has ever read it. So glad to see someone else reference it.

Link?

The original title is "Pierre Menard, Author of the Quixote": http://www.coldbacon.com/writing/borges-quixote.html

Re: Show HN: ZFS Implementation in Python

#78
post #55

Earlier quoted context omitted.

I started doing it but yes, it's too much effort to get two full benchmarks, I'm sorry :). But I think it went down to the inefficiency of String.split(): https://stackoverflow.com/questions/37007189/string-split-te... and generally the Java's String built-in methods not being GC-friendly: https://stackoverflow.com/questions/20336459/garbage-friendl... . I'm guessing that when such parts can be coded in a non-VM envi…

CPython and PyPy are both VMs, similarly to the JVM.

I meant the inside of a VM (its implementation), which is coded in C/RPython. Java's VM is coded in C++, but I don't think C++ is used for any regular library functions, while C is used heavily for Python's stdlib.

Re: Show HN: ZFS Implementation in Python

#79
post #55

Earlier quoted context omitted.

If you manage to do it would be awesome, otherwise thanks a lot anyway for the effort :) I’m just curious to understand why it happens because it’s exactly the opposite of what I would expect. The only explanation that comes to my mind is excessive gc as someone else already mentioned, but it would be interesting to see the original code.

I started doing it but yes, it's too much effort to get two full benchmarks, I'm sorry :). But I think it went down to the inefficiency of String.split(): https://stackoverflow.com/questions/37007189/string-split-te... and generally the Java's String built-in methods not being GC-friendly: https://stackoverflow.com/questions/20336459/garbage-friendl... . I'm guessing that when such parts can be coded in a non-VM envi…

Yes, Java has nothing like C# Span to avoid these kind of problems, but I thought that also python would be affected in a similar way... Anyway, thanks for sharing.

Re: Show HN: ZFS Implementation in Python

#80
post #52

Earlier quoted context omitted.

Filesystem with a GIL, what could possibly go wrong? /s

A lot less will go wrong than a filesystem without a GIL. GIL is for safety and correctness, not speed.

Uh, no?

Python's global interpreter lock was added for single threaded speed and c library integrations, which often can't be used multithreaded

There was some talk about removing it recentlish to improve pythons multithreaded performance and Guido said something along the lines of

> "I'll remove it as long as single threaded performance doesn't suffer"

Which nobody succeeded in

Post reply on HN