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. OK > As for the problem itself, noting that I'm not a dev, just a user/admin > following the list, I believe... > > There was a recent bug (early 4.0 or 4.1, IDR which) that (as I recall > understanding it) would fail to decrement link count and would thus leave > unnamed inodes hanging around in directories with no way to delete them. > That looks very much like what you're seeing. Now that you mention it, I think I remember seeing that patch (series?). > The bug has indeed been > fixed in current, and a current btrfs check should fix it, but I don't > believe that v4.0.1 userspace from the initramfs is new enough to have > that fix. The 4.1.2 userspace on your main system (from the first post) > is current and should fix it, I believe, however. I have updated the initramfs in the meantime. (Funny: I *just* started using one, mainly to be able to use btrfstune on /, but now I have a genuine necessity for it.) > 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. Greetings -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup
pgpXLNONJFRwt.pgp
Description: Digitale Signatur von OpenPGP
