After 3 afternoons of work during my recovery period and a couple of hours today, I got the first VFS operation to work! :)
So.. if you compile the latest development code from the Mercurial repository, you can now use 'df' on ZFS filesystems in Linux (but I don't recommend you try it on filesystems you don't want to corrupt) :p
It was a lot of work since I had to make zfs_mount() work, which depends on a lot of other code (I even had to import the range locks code).
The VFS is quite complex -- I still don't have a firm grasp of the whole VFS and vnode allocation/deallocation/reference counting, so my code is very messy, and there are still a lot of bugs :p
I also got a little disappointed because FUSE doesn't support remounting, so you won't be able to change any mount property on mounted filesystems (like for example, 'zfs set readonly=on pool') - you'll have to unmount and then mount it again..
Next step is to fix bugs/clean-up code and then implement readdir and stat (in order to use 'ls').
Subscribe to:
Post Comments (Atom)
22 comments:
come on man, work harder, BSD has already finished the ZFS port. If you don't have enough time to work on this project then leave it to some other who has the time
I accept code contributions
I can't believe that anonymous comment was serious... it's so rude.
People are welcome to move to FreeBSD (no the port is not yet finished) but if anyone thinks he/she can do a better job than Ricardo show the code or shut up.
Rude is such a nice word for this guy.There are always guys who think developing is a couple of minutes work and do not appreciate someone is working really hard in order to provide them software to use.
Keep up the hard work wiseman.
As a long time filesystem developer myself, I think what Ricardo is doing currently is one of the most significant works in the history of Linux filesystem development.
I can easily imagine that in 10 years from now most people will use and love zfs-fuse on Linux, since all other Linux filesystems became so backward by now that I doubt any could catch up anytime soon (perhaps reiser4 but that's also still quite far from the full capabilities of zfs).
Just ignore that first reply. It's very good that you 1) share your progress 2) share the code 3) give a whole team of people a headstart when ZFS becomes a proven filesystem
Take your time, it's YOUR time.
Parabéns pelo progresso, Ricardo. Não ligues àquele paspalho do primeiro comentário. Estás a fazer um excelente trabalho, mesmo sem ter em conta que estás a trabalhar sozinho. Se eu tivesse mad C skillz tentava dar-te uma mãozinha...
Um abraço de um geek português.
One quick question. For the long term, it appears a FUSE based filesystem will have significant limitations compared to a kernelspace filesystem driver for Linux. Is the expectation that FUSE will deliver adequate performance and evolve to provide missing features, or is a kernelspace implementation still desireable? Is anyone working on one?
Apologies if this is a FAQ. I couldn't find a list of previously discussed questions.
Thank you to everyone for your support and kind words. It means a lot to me :)
As for anonymous' question:
Yes, FUSE has and will always have some limitations:
Performance will never be as good as a kernel-level implementation.
Range locks are only available from FUSE 2.6 onwards (still in release candidate status).
Right now, remounting an already mounted filesystem is not supported on any FUSE version.
You will probably never be able to use files on ZFS (or ZVols) as swap, due to memory allocation interactions.
And probably some other things I'm forgetting :p
So a kernel-level implementation is still desired, but it cannot be done as long as ZFS is licenced with the CDDL, which is incompatible with the GPL.
Maybe we can convince Sun to dual-licence ZFS? ;)
well and even if sun does not do that someone has to bite the bullet and reverse engineer it in a gpl-compatible fashion. :)
anyway it's great to see you making progress with zfs-fuse. keep it up! :>
I think it should be possible to use the mechanisms the GPL has to deal with incompatible licenses (yes there are options!!) : an exception clause can be added for SCCL, just like has been done for binary drivers.
If the code is properly abstracted into a loadable module, then the licensing issues are moot. All in all, the GPL only applies for redistribution, not for *running* the code.
That said... I'll use the BSD version when available :-P .
I'm also using FUSE in my ntfs-3g project, but I have worked on the NTFS kernel driver in the past as well. Here are my answers to Ricardo's FUSE vs kernel comments (btw, I think it's not a user vs kernel space question because FUSE based filesystems are in fact a hybrid, kernel-user filesystems which mix apparently gives the best technical approach over pure user or kernel space filesystems):
- Performance is complex issue. For example the unoptimized ntfs-3g driver is already faster in certain cases than most of the in-kernel filesystems. E.g. only reiserfs is faster in random file/dir creation but may not be anymore when ntfs-3g is optimized. See e.g.'bonnie++ -s0' tests, or my numbers at http://sourceforge.net/mailarchive/forum.php?forum_id=2697&thread_id=23836054
- Range locking is already implemented in FUSE 2.6.0.
- Safe swap file usage on FUSE based filesystem is also implemented for about a month and workes fine with ntfs-3g with FUSE 2.6.0.
- Remount doesn't seem to be unsolvable. Did you discuss this with Miklos?
Sorry, but none the argument in favour of the kernel was valid or a strong one.
Personally I'm seeing mostly benefits of the FUSE based hybrid drivers in areas, like performance, featureness and reliability.
So, I would also like to encourage you and thank for your work!
This is an awsome attemp to get the zfs working for all of the rest of linux users. Can I ask, if you don't mind, what kind of schedule do you have for this? And how do you accept help on the coding of this fuse, how can we send it to you, the changes?
Hi, sorry for not answering sooner, I've been very busy lately.
Regarding szaka's comments:
I'd already seen that thread with those benchmarks before :) Those are very interesting numbers, I'm actually hoping zfs-fuse will be able to compete with existing kernel filesystems performance-wise.
I agree with everything else you said, except the swap issue - it can't be done (with that approach) in ZFS.
The problem is that the bmap solution doesn't work with ZFS because everything (including swap) is copy-on-write and checksummed. So the kernel can't write directly to the block device, it has to go through the zfs-fuse process, which can lead to memory allocation-related deadlocks..
Regarding anonymous' questions:
I don't have a fixed schedule, I just work whenever I have free time, which unfortunately is almost never these days :(
I accept help in coding, of course. I'd prefer if people send me patches by email (rcorreia at wizy dot org). I'll do my best to review them and integrate them.
Of course, if you have any questions regarding the zfs-fuse code, feel free to ask me :)
You should probably join forces with the BSD guy and do the userland implementation on FreeBSD first ;).
how long do we have to wait? a few years? decades? I agree with the above comment, joining forces will not only accelerate the development of ZFS for Linux, but will also give you more time for yourself
Who are you to ask how long you have to wait? This is a guy doing this in his free time. Would you have him sacrifice his education and/or family life for your filesystem? If you want it that bad, download SXCR and be happy.
Furthermore, will integrating with BSD be of any use? AFAIK the FreeBSD port is kernel-land. BSD and Solaris kernels are, relatively, more compatible with each other than with Linux. Thus it makes sense that it was brought up quicker on BSD.
From what I know, and I do subscribe to zfs-discuss@opensolaris.org, this is the only project to bring this to Linux. As the almighty anonymous has already said: "put up or shut up". wizeman has sources available: download them and send him patches.
I agree there's no right to demand a time schedule. joining the BSD effort is good because: 1) it permits testing and faster development while being able to *use* ZFS on the development machine, 2) the kernel and userland implementations share at least some code and cleanups on one side help the other, 3) It's always good to have someone else nearby to validate your work.
Of course it was just a suggestion, although slowly the project is advancing and that's what matters.
How is project going? Any code updates or progress done? Ready before christmas?
So this has died, hasn't it?
at this speed of development we shall have ZFS on Linux in about...hmmmm, 7? 12? years
It's far from dead... You can see the progress on http://www.wizy.org/mercurial/
What's interesting is that most of ZFS' new features would be easy to port into the FUSE version once the Linux layer is finished.
Post a Comment