Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
>> From: markw at mohawksoft.com [mailto:markw at mohawksoft.com] >> >> >> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss- >> >> bounces+blu=nedharvey.com at blu.org] On Behalf Of >> >> >> >> ZFS has license issues. >> >> Btrfs not considered "stable" yet. >> > >> > I don't recall you ever expanding into what you mean by saying those 2 >> > things. >> > >> ZFS: >> http://arstechnica.com/open-source/news/2010/06/uptake-of-native-linux- >> zfs-port-hampered-by-license-conflict.ars > > What about solaris/openindiana/freebsd or whatever instead of linux? If > you're trying to solve a specific design requirement - I am a fan of > separating the storage from the machine. Use solaris to manage my storage > and distribute it to the linux clients. If you're trying to solve the > general case problem, creating more optional solutions for any random > people > out there who need storage managed by linux for any random reason, then > the > ZFS license conflict (which is only part of the real problem) is a real > obstacle to widespread usage of ZFS in linux. That license issue is a real issue for a business. Besides that, storage is a commodity. I think the market for something that is billed as storage is pretty much saturated. While you can say that anything you can run on Linux you can run on FreeBSD is basically true, but there is better hardware support with Linux. While I have a day job, I am working on an idea. It is not "storage" per se' but it is heavily dependent on flexible storage. > > So I respect the "ZFS has license issues" statement only in the context of > running on linux directly. Which, if you want to run Linux, is a problem. > > >> Btrfs: >> Doesn't have a completely functional fsck yet, and still has performance >> issues. It is still not considered "stable" yet with regard to the >> kernel. > > Are you trying to solve a problem for yourself, or trying to create a new > product for general use by people on the internet at large? If it's a > general product you're planning to invent ... the "not stable yet" > argument > against btrfs won't hold water for long. It barely holds water now, as > people are starting to deploy btrfs in production, and btrfs is being > included (but not enabled by default) in most major distributions. It has been well over a year since it was rejected by RedHat because of the issue and it still does not have one. > > You have to consider the time and momentum that btrfs has, versus the time > necessary to do something else, and the momentum there... There seems to be a lot of hype, but I feel it is subsiding and I see little actual movement in performance and completion. While it would be very premature to predict collapse, I don't think caution at this juncture is unreasonable. When it is in the kernel and considered stable, I'll consider it. When it has been stable for a year or so and the default file system for a big Linux distro, I think it would be safe to use.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |