> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Hillel Lubman > > Oracle (together with RedHat) contributes a bulk part of BTRFS > development. Given that ZFS and BTRFS both share many similar goals, > wouldn't it be reasonable for Oracle to license ZFS under wider range > of FOSS licenses
I'm no expert in this subject, but I do feel confident in my knowledge that the license conflict is just one of many obstacles to prevent ZFS from working nicely in Linux. The license issue is not insurmountable, and many reasonable solutions could possibly be created (two that I know of ... Either compile the ZFS code separately from the kernel, and link it in dynamically, which would require something like LILO to statically map hard drive sectors to load the modules at boot time, assuming you want your OS boot pool to be ZFS. Or compile or translate the ZFS code and distribute the binaries or translated code under a different license which is compatible with GPL.) The license issue is just one of many obstacles. Like ... in Linux, you've got a filesystem layer, which is just filesystems. They interact with a device layer, which knows nothing of filesystems. Throw in some software raid, and a separation of kernel space from user space... All of a sudden, if you think about building ZFS for Linux, you're stepping on a lot of toes, and violating a lot of the culture of the Linux kernel developers. They're a bunch of disperse programmers, who, in order to keep organized, must compartmentalize and modularize themselves. Unlike the ZFS developers, who almost all work under one roof (er ... company name.) The Linux guys don't like some big thing coming along, crossing over between kernel and userspace, undoing everything they've ever done, all being developed by one big company that they can't boss around. I don't know if you noticed that GPL is very much anti-corporation, or anti-commercial. They're more comfortable with just another filesystem, similar to all the other filesystems they've had in the past, with the notable support for copy on write. IMHO, one of the best benefits of ZFS (besides the obvious copy on write) is the fact that the RAID layer (if I may use that term) has intimate knowledge of both the block-level devices, and the filesystem. Which means ZFS is able to aggregate many small writes to separate sectors of separate files, and intelligently map all the filesystem blocks to consecutive physical blocks (or striped physical blocks), which means they're all consolidated into one large sequential write. This is a huge performance gain, for both small random operations and/or large sequential operations. I don't know if BTRFS is going to be able to do this sort of stuff, given the isolation from the RAID layer. I think BTRFS is just going to give Linux users snapshots, and block-level incremental backups. To gain the performance benefits, it necessitates erasing the separation between filesystem and block-level (raid) code. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
