Thank you all for your help so far. I'm doing backups at the moment. My other Server is a ZFS system. I think what I'm going to do, is to have this system, that's currently BTRFS RAID5 migrated to using ZFS and once that's done, migrate my backup system to BTRFS RAID5. That way I can still experiment with BTRFS Raid5, but starting from scratch is not so problematic, since it's a backup system and not being actively used. I'm still going to try the steps you mentioned with btrfs check -- repair and see what that's going to spit out. Am Donnerstag, den 03.10.2019, 14:18 -0600 schrieb Chris Murphy: > On Thu, Oct 3, 2019 at 6:18 AM Robert Krig > <robert.krig@xxxxxxxxxxxxxxxxxx> wrote: > > By the way, how serious is the error I've encountered? > > I've run a second scrub in the meantime, it aborted when it came > > close > > to the end, just like the first time. > > If the files that are corrupt have been deleted is this error going > > to > > go away? > > Maybe. > > > > > > > Opening filesystem to check... > > > > > Checking filesystem on /dev/sda > > > > > UUID: f7573191-664f-4540-a830-71ad654d9301 > > > > > [1/7] checking root items (0:01:17 > > > > > elapsed, > > > > > 5138533 items checked) > > > > > parent transid verify failed on 48781340082176 wanted 109181 > > > > > found > > > > > 109008items checked) > > > > > parent transid verify failed on 48781340082176 wanted 109181 > > > > > found > > > > > 109008 > > > > > parent transid verify failed on 48781340082176 wanted 109181 > > > > > found > > > > > 109008 > > These look suspiciously like the 5.2 regression: > https://lore.kernel.org/linux-btrfs/20190911145542.1125-1-fdmanana@xxxxxxxxxx/T/#u > > You should either revert to a 5.1 kernel, or use 5.2.15+. > > As far as I'm aware it's not possible to fix this kind of corruption, > so I suggest refreshing your backups while you can still mount this > file system, and prepare to create it from scratch. > > > > > > > Ignoring transid failure > > > > > leaf parent key incorrect 48781340082176 > > > > > bad block 48781340082176 > > > > > [2/7] checking extents (0:03:22 > > > > > elapsed, > > > > > 1143429 items checked) > > > > > ERROR: errors found in extent allocation tree or chunk > > > > > allocation > > That's usually not a good sign. > > > > > > > > [3/7] checking free space cache (0:05:10 > > > > > elapsed, > > > > > 7236 > > > > > items checked) > > > > > parent transid verify failed on 48781340082176 wanted 109181 > > > > > found > > > > > 109008ems checked) > > > > > Ignoring transid failure > > > > > root 15197 inode 81781 errors 1000, some csum missing48 > > > > > elapsed, > > That's inode 81781 in the subvolume with ID 15197. I'm not sure what > error 1000 is, but btrfs check is a bit fussy when it enounters files > that are marked +C (nocow) but have been compressed. This used to be > possible with older kernels when nocow files were defragmented while > the file system is mounted with compression enabled. If that sounds > like your use case, that might be what's going on here, and it's > actually a benign message. It's normal for nocow files to be missing > csums. To confirm you can use 'find /pathtosubvol/ -inum 81781' to > find the file, then lsattr it and see if +C is set. > > You have a few options but the first thing is to refresh backups and > prepare to lose this file system: > > a. bail now, and just create a new Btrfs from scratch and restore > from backup > b. try 'btrfs check --repair' to see if the transid problems are > fixed; if not > c. try 'btrfs check --repair --init-extent-tree' there's a good > chance > this fails and makes things worse but probably faster to try than > restoring from backup >
