Am 11.02.20 um 23:13 schrieb Chris Murphy:
>
> I think it's a straight up Btrfs bug. But it should be reported
> upstream to find out what's going on. Off hand I don't see a relevant
> patch between 4.19.95 and 4.19.103. If you write up the email, put me
> in the cc and I can fill in some of th
Am 10.02.20 um 01:22 schrieb Chris Murphy:
> You might just go straight to ARM, and try to mount -o ro and see if
> it mounts it OK. I think the error messages you got from Btrfs
> previously had to do with the bogus GPT error messages - which we
> don't know why that happened.
>
Unfortunately
Sorry, Valentines preparation.
Am 07.02.20 um 23:10 schrieb Chris Murphy:
> OK so neither fdisk nor gdisk have any complaints about the GPT. And
> yet the kernel is complaining. That's wrong and weird.
>
> Have the drives always been in these USB enclosures, for the life of
> this Btrfs file syst
hance of permanently losing the file system.
>
>
> On Thu, Feb 6, 2020 at 2:01 PM Simeon Felis wrote:
>>
>> 4.19.75 dmesg:
>>
>> [ 17.707873] GPT:Primary header thinks Alt. header is not at the end of
>> the di
>> sk.
>> [ 17.707889] GPT:78140
Am 07.02.20 um 05:02 schrieb Chris Murphy:
> On Thu, Feb 6, 2020 at 3:03 PM Chris Murphy wrote:
>>
>> There is a gotcha moving Btrfs between different archs. "Btrfs sector
>> size", which is an internal Btrfs thing, not a reference to either
>> logical or physical sector size of the device, mus
I have a btrfs raid1 on raspbian (kernel 4.19.75) which overheated. To fix the
btrfs filesystem I attached the raid1 to my workstation with Arch Linux (kernel
5.5.1). I run scrub to identify broken files and fixed them. Furthermore I run
--full-balance and defrag -r. All fine so far.
Now I can'
6 matches
Mail list logo
