Re: [PATCH RFC] btrfs: Don't create SINGLE or DUP chunks for degraded rw mount

[Qu Wenruo <wqu@suse.de>]

[-- Attachment #1.1: Type: text/plain, Size: 1245 bytes --]



On 2019/2/12 下午3:43, Remi Gauvin wrote:
> On 2019-02-12 2:22 a.m., Qu Wenruo wrote:
> 
>>> Does this mean you would rely on scrub/CSUM to repair the missing data
>>> if device is restored?
>>
>> Yes, just as btrfs usually does.
>>
> 
> I don't really understand the implications of the problems with mounting
> fs when single/dup data chunk are allocated on raid1,

Consider this use case:

One btrfs with 2 devices, RAID1 for data and metadata.

One day devid 2 got failure, and before replacement arrives, user can
only use devid 1 alone. (Maybe that's the root fs).

Then new disk arrived, user replaced the missing device, caused SINGLE
or DUP chunks on devid 1, and more importantly, some metadata/data is
already in DUP/SINGLE chunks.

Then some days later, devid 1 get failure too, now user is unable to
mount the fs degraded RW any more, since SINGLE/DUP chunks are all on
devid 1, and no way to replace devid 1.

Thanks,
Qu

> but I would think
> that would actually be a preferable situation than filling a drive with
> 'data' we know is completely bogus... converting single/dup data to raid
> should be much faster than tripping on CSUM errors, and less prone to
> missed errors?
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]