Re: Add device while rebalancing

[Juan Alberto Cirez <jacirez@rdcsafety.com>]

Holger,
If this is so, then it leaves even confused. I was under the
impression that the driving imperative for the creation of btrfs was
to address the shortcomings of current filesystems (within the context
of distributed data). That the idea was to create a low level
filesystem that would be the primary choice as a block/brick layer for a
scale-out, distributed data storage...

On Wed, Apr 27, 2016 at 10:38 AM, Juan Alberto Cirez
<jacirez@rdcsafety.com> wrote:
> Holger,
> If this is so, then it leaves with even confused. I was under the
> impression that the driving imperative for the creation of btrfs was
> to address the shortcomings of current filesystem within the context
> of distributed data. That the idea was to create a low level
> filesystem that would the primary choice as a block/brick layer for a
> scale-out, distributed data storage...
>
> On Wed, Apr 27, 2016 at 10:29 AM, Holger Hoffstätte
> <holger.hoffstaette@googlemail.com> wrote:
>> On 04/27/16 17:58, Juan Alberto Cirez wrote:
>>> Correct me if I'm wrong but the sum total of the above seems to
>>> suggest (at first glance) that BRTFS add several layers of complexity,
>>> but for little real benefit (at least in the case use of btrfs at the
>>> brick layer with a distributed filesystem on top)...
>>
>> This may come as a surprise, but the same can be said for every other
>> (common) filesystem (+ device management stack) that can be used
>> standalone.
>>
>> Jeff Darcy (of GlusterFS) just wrote a really nice blog post why
>> current filesystems and their historically grown requirements (mostly
>> as they relate to the POSIX interface standard) are in many ways
>> just not a good fit for scale-out/redundant storage:
>> http://pl.atyp.us/2016-05-updating-posix.html
>>
>> Quite a few of the capabilities & features which are useful or
>> necessary in standalone operation (regardless of single- or multi-
>> device setup) are *actively unhelpful* in a distributed context, which
>> is why e.g. Ceph will soon do away with the on-disk filesystem for
>> data, and manage metadata exclusively by itself.
>>
>> cheers,
>> Holger
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html