On Mon, Aug 14, 2017 at 2:18 PM, Goffredo Baroncelli wrote:
>> Anyway, I do wish I read the code better, so I knew exactly where, if
>> at all, the RMW code was happening on disk rather than just in memory.
>> There very clearly is RMW in memory code as a performanc
On 08/14/2017 09:28 PM, Chris Murphy wrote:
> On Mon, Aug 14, 2017 at 8:12 AM, Goffredo Baroncelli
> wrote:
>> On 08/13/2017 08:45 PM, Chris Murphy wrote:
>>> [2]
>>> Is Btrfs subject to the write hole problem manifesting on disk? I'm
>>> not sure, sadly I don't read the code
On Mon, Aug 14, 2017 at 8:12 AM, Goffredo Baroncelli wrote:
> On 08/13/2017 08:45 PM, Chris Murphy wrote:
>> [2]
>> Is Btrfs subject to the write hole problem manifesting on disk? I'm
>> not sure, sadly I don't read the code well enough. But if all Btrfs
>> raid56 writes are
On 08/13/2017 08:45 PM, Chris Murphy wrote:
> [2]
> Is Btrfs subject to the write hole problem manifesting on disk? I'm
> not sure, sadly I don't read the code well enough. But if all Btrfs
> raid56 writes are full stripe CoW writes, and if the prescribed order
> guarantees still happen: data CoW
On Sun, Aug 13, 2017 at 8:45 PM, Chris Murphy wrote:
> Further, the error detection of corrupt reconstruction is why I say
> Btrfs is not subject *in practice* to the write hole problem. [2]
>
> [1]
> I haven't tested the raid6 normal read case where a stripe contains
>
On Sun, Aug 13, 2017 at 8:16 AM, Goffredo Baroncelli wrote:
> Hi all,
>
> in the BTRFS wiki, in the status page, in the "line" RAID5/6 it is reported
> that the parity is not checksummed. This was reported several time in the ML
> and also on other site (e.g. phoronix) as a
Hi all,
in the BTRFS wiki, in the status page, in the "line" RAID5/6 it is reported
that the parity is not checksummed. This was reported several time in the ML
and also on other site (e.g. phoronix) as a BTRFS defect.
However I was unable to understand it, and I am supposing that this is a