On 2020/2/3 下午6:10, Qu Wenruo wrote:
> 
> 
> On 2020/2/3 下午4:42, Skibbi wrote:
>> pon., 3 lut 2020 o 07:51 Qu Wenruo <quwenruo.btrfs@gmx.com> napisał(a):
>>>
>>>> I'm beginning to think that my Pi draws more power when used with
>>>> external drive (I used only pendrives so far) so I need to investigate
>>>> for power issues.
>>>
>>> That also looks promising.
>>> But since it's a USB hdd, what about try it with regular PC?
>>
>> I tried on widows and disk worked fine. I replaced Pi power supply and
>> surprise-surprise my disk is working fine! Btrfs + luks encryption. So
>> it seems power was the culprit.
> 
> That's great to know!
> 
>> However I'm a bit concerned about stability of the filesystem. I would
>> expect some data loss when drive is disconnected, but why the whole
>> filesystem is broken?
> 
> It depends on the timing.
> 
> In fact, as your initial report said, btrfs even succeeded to read some
> tree copy from the disk when we lost the device for a while.
> And finally goes RO if btrfs fails to write any tree blocks.
> 
> In all cases, btrfs shouldn't fail if all disks follows FUA/FLUSH
> behavior (aka, if FUA/FLUSH returns, all related write should reach disk).

BTW, here "shouldn't fail" I mean, btrfs shouldn't lose COW data or
metadata at all.

Either the disk fails before superblock write, then the fs should be
what it used to be.
Or the disk fails after super block write, then the fs should be in the
new stats (including both metadata and CoWed data).

Unlike traditional fs, they only keep metadata sane while can lose data
when experiencing power loss by default. (They can do journal protection
for data, but has huge performance penalty than btrfs COW)

For re-appearing disk, I really don't have much good idea to address,
nor other fses would.
What we can really do is just to keep the fs is still fine to be mounted
back after disk disapperance.

Thanks,
Qu
> 
>> I can't ensure that power failures will not happen in the future, so
>> I'm still not sure if I should go with btrfs?
>>
> IIRC, either other fses just ignore any write error (and cause more
> serious problem later, not only data corruption but also metadata
> corruption) or just fail like btrfs when disks suddenly disappear.
> 
> If the disk is not reliable, then it depends on what really you want.
> 
> A kinda paranoid fs which refuses to further screw up the fs, or a fs
> ignoring most errors until the whole thing experience a rapid
> unscheduled disassembly.
> 
> Thanks,
> Qu
>