From: Marc Joliet <marcec@gmx.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: Deleted files cause btrfs-send to fail
Date: Thu, 13 Aug 2015 10:54:58 +0200 [thread overview]
Message-ID: <20150813105458.676c884a@thetick> (raw)
In-Reply-To: <pan$1dd35$9501221a$dce0e6ab$9d04fcea@cox.net>
[-- Attachment #1: Type: text/plain, Size: 3278 bytes --]
Am Thu, 13 Aug 2015 08:29:19 +0000 (UTC)
schrieb Duncan <1i5t5.duncan@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
[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-08-13 8:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-12 22:34 Deleted files cause btrfs-send to fail Marc Joliet
2015-08-13 7:05 ` Marc Joliet
2015-08-13 8:29 ` Duncan
2015-08-13 8:54 ` Marc Joliet [this message]
2015-08-14 21:37 ` Marc Joliet
2015-08-15 5:10 ` Duncan
2015-08-15 9:19 ` Marc Joliet
2015-08-23 13:22 ` [SOLVED] " Marc Joliet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150813105458.676c884a@thetick \
--to=marcec@gmx.de \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.