From: Milko Krachounov <sombre@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Error on creating snapshots (btrfs: could not do orphan cleanup -116)
Date: Mon, 5 Sep 2011 18:57:21 +0300 [thread overview]
Message-ID: <CAJ-vRAKSGSXa5kjJ6zwk8qos2LgoJq8m4CYFPz+zHmkaoiGGDw@mail.gmail.com> (raw)
This happens on a freshly created btrfs filesystem in a raid10 (4x1TB)
configuration with three
subvolumes and 1.5 TB data.
When I try to snapshot one of the subvolumes (with 100 GB of data), it
says that the snapshot
creation failed and I get the following error message:
btrfs: could not do orphan cleanup -116
After the failure:
- The snapshot exists in `btrfs subvolume list'
- The snapshot CAN'T be accessed from the mounted subvolume where I created the
snapshot (but the directory entry exists and displays non-sense when
you try to do `ls -la')
- The snapshot CAN be accessed from any other mount of the same subvolume
- The snapshot CAN be accessed after unmount/remount
This was also coupled with a warning in dmesg that was fixed with
slyich's patch from
`[PATCH] btrfs: fix warning in iput for bad-inode.'
I did a little bit of research on the problem, and while I'm too
unfamiliar with the code of btrfs to diagnose it,
I'd like to share some of the observations as they appear to be of importance:
The failure happens when btrfs_orphan_cleanup calls btrfs_iget to get
the inode and it returns
ERR_PTR(-ESTALE). This happens when is_bad_inode(inode) is true.
However, after the call
to btrfs_iget there is an explicit code path for the case when
is_bad_inode(inode) is true (line 2393).
This code path would *never ever* get executed unless something
happening in another thread can
affect the return value between the two calls. I believe that lines
2394-2402 would never be executed.
What's more I discovered the following patch:
[PATCH 5/6] btrfs: Add per subvolume cached inode tree #2
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg02435.html
The patch changes the behaviour of btrfs_orphan_cleanup -- without it
there is no code that would lead
to ERR_PTR(-ESTALE) and the bad inode code path will run. With it,
suddenly this code path isn't called
and instead an error is produced.
I think I should try and reverse this specific change in the following
days and see if it fixes the problem, but
I'm not confident enough to blindly change the code without asking for
comments first, so any comment is
appreciated.
Thank you.
next reply other threads:[~2011-09-05 15:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-05 15:57 Milko Krachounov [this message]
2011-09-06 18:22 ` [PATCH] make btrfs_orphan_cleanup process bad inodes Milko Krachounov
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=CAJ-vRAKSGSXa5kjJ6zwk8qos2LgoJq8m4CYFPz+zHmkaoiGGDw@mail.gmail.com \
--to=sombre@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).