Boston Linux & Unix (BLU) 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

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] LVM Snapshot Wrapup



>> 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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org