Am Thu, 13 Aug 2015 10:54:58 +0200 schrieb Marc Joliet <mar...@gmx.de>:
> Am Thu, 13 Aug 2015 08:29:19 +0000 (UTC) > schrieb Duncan <1i5t5.dun...@cox.net>: > > > Marc Joliet posted on Thu, 13 Aug 2015 09:05:41 +0200 as excerpted: > > > > > Here's the actual output now, obtained via btrfs-progs 4.0.1 from an > > > initramfs emergency shell: > > > > > > checking extents checking free space cache checking fs roots root 5 > > > inode 8338813 errors 2000, link count wrong > > > unresolved ref dir 26699 index 50500 namelen 4 name root > > > filetype 0 errors 3, no dir item, no dir index > > > root 5 inode 8338814 errors 2000, link count wrong > > > unresolved ref dir 26699 index 50502 namelen 6 name marcec > > > filetype 0 errors 3, no dir item, no dir index > > > root 5 inode 8338815 errors 2000, link count wrong > > > unresolved ref dir 26699 index 50504 namelen 6 name systab > > > filetype 0 errors 3, no dir item, no dir index > > > root 5 inode 8710030 errors 2000, link count wrong > > > unresolved ref dir 26699 index 59588 namelen 6 name marcec > > > filetype 0 errors 3, no dir item, no dir index > > > root 5 inode 8710031 errors 2000, link count wrong > > > unresolved ref dir 26699 index 59590 namelen 4 name root > > > filetype 0 errors 3, no dir item, no dir index > > > Checking filesystem on /dev/sda1 UUID: > > > 0267d8b3-a074-460a-832d-5d5fd36bae64 found 63467610172 bytes used err is > > > 1 total csum bytes: 59475016 total tree bytes: 1903411200 total fs tree > > > bytes: 1691504640 total extent tree bytes: 130322432 btree space waste > > > bytes: 442495212 file data blocks allocated: 555097092096 > > > referenced 72887840768 > > > btrfs-progs v4.0.1 > > > > > > Again: is this fixable? > > > > FWIW, root 5 (which you asked about upthread) is the main filesystem > > root. So all these appear to be on the main filesystem, not on snapshots/ > > subvolumes. > [...] > > But if it's critical, you may wish to wait and have someone else confirm > > that before acting on it, just in case I have it wrong. > > I can wait until tonight, at least. The FS still mounts, and it's just the > root > subvolume that's affected; running btrfs-send on the /home subvolume still > works. Well, I got impatient, and just went ahead and did it (I have backups, after all). It looks like it worked: the affected files were moved to /lost+found/, where I deleted them again, and btrfs-send works again. The output of "btrfs check" after --repair: checking extents checking free space cache checking fs roots checking csums There are no extents for csum range 0-69632 Csum exists for 0-69632 but there is no extent record Checking filesystem on /dev/sda1 UUID: 0267d8b3-a074-460a-832d-5d5fd36bae64 block group 274307481600 has wrong amount of free spacefailed to load free space cache for block group 274307481600 found 60980420666 bytes used err is 1 total csum bytes: 57521732 total tree bytes: 1996800000 total fs tree bytes: 1791721472 total extent tree bytes: 127942656 btree space waste bytes: 460072661 file data blocks allocated: 478650343424 referenced 73326161920 btrfs-progs v4.1.2 If I notice anything amiss, I'll report back. (One other thing I found interesting was that "btrfs scrub" didn't care about the link count errors.) Greetings. -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup
pgpvHFAJ5LvQi.pgp
Description: Digitale Signatur von OpenPGP
