Linked by Thom Holwerda on Mon 6th Aug 2007 21:50 UTC, submitted by anonymous
BSD and Darwin derivatives The sixth major DragonFly BSD release, version 1.10, was announced today by project creator Matthew Dillon. Billed as "more stable than the 1.8 release", it includes improved virtual kernel support, a new disk management infrastructure, improvements to wireless networking, and support for the new syslink protocol. As to what all that means, KernelTrap has just posted an interview with Dillon. Going beyond today's 1.10 release, the interview explores DragonFly's new clustering high-availability filesystem which sounds superior to ZFS, the project's goals for the 2.0 release expected in six months, and a comparison of the BSD license versus the GPL.
Thread beginning with comment 261278
To read all comments associated with this story, please click here.
we shall see
by poundsmack on Mon 6th Aug 2007 22:16 UTC
poundsmack
Member since:
2005-07-13

"the interview explores DragonFly's new clustering high-availability filesystem which sounds superior to ZFS"

sounds is one thing. as far as an actual implimentation well i guess we will have to wait and see. I wish them luck.

RE: we shall see
by yorthen on Tue 7th Aug 2007 08:50 in reply to "we shall see"
yorthen Member since:
2005-07-06

The DF filesystem and ZFS does not even have to same goals, so to claim that one sees to be superior to the other is quite weird in my opinion. ZFS was considered but was rejected (though with userland FS support coming it might be ported over anyway) since it was not suitable for clustered storage on multiple machines potentially connected over slow links.

Reply Parent Bookmark Score: 3

RE: we shall see
by butters on Tue 7th Aug 2007 16:12 in reply to "we shall see"
butters Member since:
2005-07-08

There are two main differences between DF's clustering filesystem and ZFS. First, it's intended to (eventually) manage storage devices that are distributed amongst several cluster nodes. Also, it uses live snapshots for redundancy as well as for backup, eliminating the need for an integrated storage layer.

I was surprised to learn that the Matt is developing the clustering filesystem via the userspace VFS API instead of putting it in the kernel. Perhaps there are plans to port it to the kernel once the userspace implementation reaches a certain milestone.

My theory on filesystem design calls for a heap-like storage layer that provides a logical extent abstraction to client filesystems. Filesystem consistency can be guaranteed with proper design, while physical storage is subject to unavoidable corruption and failure. So it makes more sense (to me) to implement redundancy at the storage level rather than at the filesystem level.

But Matt hails from the world of commercial database development, so he has a good handle on these sorts of things.

Edited 2007-08-07 16:14

Reply Parent Bookmark Score: 3

RE[2]: we shall see
by yorthen on Wed 8th Aug 2007 09:58 in reply to "RE: we shall see"
yorthen Member since:
2005-07-06

"I was surprised to learn that the Matt is developing the clustering filesystem via the userspace VFS API instead of putting it in the kernel. Perhaps there are plans to port it to the kernel once the userspace implementation reaches a certain milestone."

The same reason he developed the virtual kernel (running kernel in userland), it's so much easier to develop. You don't have to reboot your computer to see if it worked, and if it doesn't you wont crash the whole system. I suspect that, like you said, when the code reaches a certain maturity level it will be put in kernelspace, you simply can't get enough performance in userland.

Reply Parent Bookmark Score: 1