Qu Wenruo <quwenruo.btrfs@xxxxxxx> writes: >> btrfs check --readonly /dev/$NAME >> >> runs out of 16GB of memory within 20 seconds and is killed by the >> kernel. > > That's why we have btrfs check --mode=lowmem Thank you for pointing this out Qu. btrfs check --mode=lowmem finds checksum verify failed on 1383731085312 found 000000CC wanted FFFFFFF5 checksum verify failed on 1383731085312 found 000000CC wanted FFFFFFF5 bad tree block 1383731085312, bytenr mismatch, want=1383731085312, have=15281531241332003907 ERROR: shared extent 1776065458176 referencer lost (parent: 1383731085312) ERROR: errors found in extent allocation tree or chunk allocation When creating a backup of the home directory after the filesystem was mounted ro, only a single log file could not be included in the backup due to failure to read it. Is there any way to fix the filesystem, given that btrfs check --mode=lowmem does not support --repair? Do you think this corruption is related to some kernel bug, triggered during suspend / resume cycle? Or could it be simply a harddrive (SSD) failure? (An extended disk self test did not report any errors though.) Best regards Leonard
