On 05/03/2018 02:47 PM, Alberto Bursi wrote:
>
>
> On 01/05/2018 23:57, Gandalf Corvotempesta wrote:
>> Hi to all
>> I've found some patches from Andrea Mazzoleni that adds support up to 6
>> parity raid.
>> Why these are wasn't merged ?
>> With modern disk size, having something greater than 2
On 05/03/2018 01:26 PM, Austin S. Hemmelgarn wrote:
>> My intention was to highlight that the parity-checksum is not related to the
>> reliability and safety of raid5/6.
> It may not be related to the safety, but it is arguably indirectly related to
> the reliability, dependent on your
On 01/05/2018 23:57, Gandalf Corvotempesta wrote:
> Hi to all
> I've found some patches from Andrea Mazzoleni that adds support up to 6
> parity raid.
> Why these are wasn't merged ?
> With modern disk size, having something greater than 2 parity, would be
> great.
> --
> To unsubscribe from
On 2018-05-03 04:11, Andrei Borzenkov wrote:
On Wed, May 2, 2018 at 10:29 PM, Austin S. Hemmelgarn
wrote:
...
Assume you have a BTRFS raid5 volume consisting of 6 8TB disks (which gives
you 40TB of usable space). You're storing roughly 20TB of data on it, using
a 16kB
On 2018-05-02 16:40, Goffredo Baroncelli wrote:
On 05/02/2018 09:29 PM, Austin S. Hemmelgarn wrote:
On 2018-05-02 13:25, Goffredo Baroncelli wrote:
On 05/02/2018 06:55 PM, waxhead wrote:
So again, which problem would solve having the parity checksummed ? On the best
of my knowledge nothing.
On Wed, May 2, 2018 at 10:29 PM, Austin S. Hemmelgarn
wrote:
...
>
> Assume you have a BTRFS raid5 volume consisting of 6 8TB disks (which gives
> you 40TB of usable space). You're storing roughly 20TB of data on it, using
> a 16kB block size, and it sees about 1GB of
Goffredo Baroncelli posted on Wed, 02 May 2018 22:40:27 +0200 as
excerpted:
> Anyway, my "rant" started when Ducan put near the missing of parity
> checksum and the write hole. The first might be a performance problem.
> Instead the write hole could lead to a loosing data. My intention was to
>
Gandalf Corvotempesta posted on Wed, 02 May 2018 19:25:41 + as
excerpted:
> On 05/02/2018 03:47 AM, Duncan wrote:
>> Meanwhile, have you looked at zfs? Perhaps they have something like
>> that?
>
> Yes, i've looked at ZFS and I'm using it on some servers but I don't
> like it too much for
On 05/02/2018 11:20 PM, waxhead wrote:
>
>
[...]
>
> Ok, before attempting and answer I have to admit that I do not know enough
> about how RAID56 is laid out on disk in BTRFS terms. Is data checksummed pr.
> stripe or pr. disk? Is parity calculated on the data only or is it calculated
> on
Andrei Borzenkov wrote:
02.05.2018 21:17, waxhead пишет:
Goffredo Baroncelli wrote:
On 05/02/2018 06:55 PM, waxhead wrote:
So again, which problem would solve having the parity checksummed ?
On the best of my knowledge nothing. In any case the data is
checksummed so it is impossible to
On 05/02/2018 09:29 PM, Austin S. Hemmelgarn wrote:
> On 2018-05-02 13:25, Goffredo Baroncelli wrote:
>> On 05/02/2018 06:55 PM, waxhead wrote:
So again, which problem would solve having the parity checksummed ? On the
best of my knowledge nothing. In any case the data is
On 2018-05-02 13:25, Goffredo Baroncelli wrote:
On 05/02/2018 06:55 PM, waxhead wrote:
So again, which problem would solve having the parity checksummed ? On the best
of my knowledge nothing. In any case the data is checksummed so it is
impossible to return corrupted data (modulo bug :-) ).
On 05/02/2018 03:47 AM, Duncan wrote:
> Meanwhile, have you looked at zfs? Perhaps they have something like that?
Yes, i've looked at ZFS and I'm using it on some servers but I don't like
it too much for multiple reasons, in example:
1) is not officially in kernel, we have to build a module
On 05/02/2018 08:17 PM, waxhead wrote:
> Goffredo Baroncelli wrote:
>> On 05/02/2018 06:55 PM, waxhead wrote:
So again, which problem would solve having the parity checksummed ? On the
best of my knowledge nothing. In any case the data is checksummed so it is
impossible to
Goffredo Baroncelli wrote:
On 05/02/2018 06:55 PM, waxhead wrote:
So again, which problem would solve having the parity checksummed ? On the best
of my knowledge nothing. In any case the data is checksummed so it is
impossible to return corrupted data (modulo bug :-) ).
I am not a BTRFS
On 05/02/2018 06:55 PM, waxhead wrote:
>>
>> So again, which problem would solve having the parity checksummed ? On the
>> best of my knowledge nothing. In any case the data is checksummed so it is
>> impossible to return corrupted data (modulo bug :-) ).
>>
> I am not a BTRFS dev , but this
On 2018-05-02 12:55, waxhead wrote:
Goffredo Baroncelli wrote:
Hi
On 05/02/2018 03:47 AM, Duncan wrote:
Gandalf Corvotempesta posted on Tue, 01 May 2018 21:57:59 + as
excerpted:
Hi to all I've found some patches from Andrea Mazzoleni that adds
support up to 6 parity raid.
Why these are
Goffredo Baroncelli wrote:
Hi
On 05/02/2018 03:47 AM, Duncan wrote:
Gandalf Corvotempesta posted on Tue, 01 May 2018 21:57:59 + as
excerpted:
Hi to all I've found some patches from Andrea Mazzoleni that adds
support up to 6 parity raid.
Why these are wasn't merged ?
With modern disk size,
Hi
On 05/02/2018 03:47 AM, Duncan wrote:
> Gandalf Corvotempesta posted on Tue, 01 May 2018 21:57:59 + as
> excerpted:
>
>> Hi to all I've found some patches from Andrea Mazzoleni that adds
>> support up to 6 parity raid.
>> Why these are wasn't merged ?
>> With modern disk size, having
Gandalf Corvotempesta posted on Tue, 01 May 2018 21:57:59 + as
excerpted:
> Hi to all I've found some patches from Andrea Mazzoleni that adds
> support up to 6 parity raid.
> Why these are wasn't merged ?
> With modern disk size, having something greater than 2 parity, would be
> great.
1)
Hi to all
I've found some patches from Andrea Mazzoleni that adds support up to 6
parity raid.
Why these are wasn't merged ?
With modern disk size, having something greater than 2 parity, would be
great.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a
21 matches
Mail list logo