[Metalab] Distributed Redundant Storage

[gaelic]

Ah, that's why all major distributions are including btrfs at least as
a possibility, if not as default nowadays. Surprisingly also RedHat.
No word from Linus, etc.

On Tue, Nov 13, 2012 at 12:29 AM, Markus Kienast <elias1884 at gmail.com> wrote:
> The implementation of btrfs has been analyzed by some RedHat dev some
> time ago. And he concluded, that btrfs says it is following certain
> concepts of FS design, but actually does not strictly follow these
> concepts and diverts from them on impulse. These diversions have not
> been scientifically tested and WILL lead to unexpected behavior and
> unpredictability.
>
> One of which is the inability to correctly predict free space in the
> FS, if I remember right.
>
> I am referring to that paper, when I say "unprofessional". This
> analysis seems to have been ignored in the press mostly, which does
> not surprise me, for the  knowledge level needed to actually
> understand, the point the guy is trying to make.
>
> In short he says, by doing what btrfs devs are doing, they will never
> get out of the experimental state, as some unpredictable bullshit will
> pop up until worlds end. And if you look, how long it has been around
> and how many distributions use it as their default FS today (although
> its features are clearly everything we ever wanted), this prediction
> seems about right.
>
> Cheers,
> Markus
>
> On Mon, Nov 12, 2012 at 11:10 PM, gaelic <gaelic at luchmhor.net> wrote:
>> If you read the ceph mailinglist you also should know that you can use
>> virtually any FS you wan't and are not bound to btrfs, btrfs is only
>> suggested.
>> And I don't think you mean btrfs is unprofessional ... but at the
>> moment its still signed as 'experimental' by the devs. Still, my
>> experience is that it's very reliable as I never had failures within
>> the last 2 years on several machines.
>>
>> Regards,
>>
>> g
>>
>> On Mon, Nov 12, 2012 at 10:42 PM, Markus Kienast <elias1884 at gmail.com> wrote:
>>> Ceph, as far as the specs are concerned, is exactly what I need.
>>> But I do not really believe in its reliability, as I do not believe in
>>> the professionality of its underlaying FS btrfs.
>>> I am on there mailinglist and what I read is not so promising.
>>>
>>> Concerning the "productivity" of my system. Yes, it is production. I
>>> rent a full rack at a datacenter and I have to care for storage
>>> myself. I however would prefer a scalable system based on cheap
>>> commodity hardware over installing an expensive enterprise SAN
>>> solution.
>>>
>>> So long,
>>> Markus
>>>
>>>
>>> On Mon, Nov 12, 2012 at 10:12 PM, Zacharias <mail at sacharja.eu> wrote:
>>>> Am 2012-11-12 21:39, schrieb elias humbolt:
>>>>
>>>>>
>>>>> Can anybody recommend a redundant replicated storage solution stable
>>>>> enough to act as basis of production system?
>>>>>
>>>>> It will be used to store and serve video data to the web and to
>>>>> transcoding nodes.
>>>>>
>>>>> Any recommendations?
>>>>>
>>>> Yes, first of all:
>>>>
>>>> If it is a *production* system, this is, something you earn money with: Rent
>>>> a server in a data center. It is their job to care about redundancies.
>>>>
>>>> If it is *not* a "production system", this is, you are basically doing this
>>>> for fun, you might wanna check out ceph http://en.wikipedia.org/wiki/Ceph
>>>> although I admit I never used it myself.
>>>>
>>>> greetings, Zacharias
>>>>
>>>> _______________________________________________
>>>> Metalab mailing list
>>>> Metalab at lists.metalab.at
>>>> https://lists.metalab.at/mailman/listinfo/metalab
>>>
>>> _______________________________________________
>>> Metalab mailing list
>>> Metalab at lists.metalab.at
>>> https://lists.metalab.at/mailman/listinfo/metalab
>>
>> _______________________________________________
>> Metalab mailing list
>> Metalab at lists.metalab.at
>> https://lists.metalab.at/mailman/listinfo/metalab
>
> _______________________________________________
> Metalab mailing list
> Metalab at lists.metalab.at
> https://lists.metalab.at/mailman/listinfo/metalab