From: Chris Murphy <lists@colorremedies.com>
To: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: device delete, error removing device
Date: Sat, 27 Oct 2012 12:25:25 -0600 [thread overview]
Message-ID: <6FC0FD8D-EC25-41DF-BF07-04648A2D0E87@colorremedies.com> (raw)
In-Reply-To: <50899269.8080208@gmail.com>
3.6.3-3.fc18.x86_64.debug
btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18.x86_64
I'm getting a very different result with this kernel compared to 3.6.2, when I do the same thing. I fill the btrfs volume to 97% full again, no errors. Add a device of the *same* size, and then device delete.
In this case, the 'device delete' command hangs, no recovery, and dmesg from another shell reports the file system is forced read only. The debug kernel produces quite a bit more information so I'll post that here:
http://pastebin.com/8d1b6eCn
Label: 'filltest' uuid: c0a4c7d7-7a23-4ce3-bafe-20cb92156562
Total devices 3 FS bytes used 13.84GB
devid 3 size 8.00GB used 19.00MB path /dev/sdd
devid 2 size 8.00GB used 8.00GB path /dev/sdc
devid 1 size 8.00GB used 8.00GB path /dev/sdb
[root@f18v ~]# btrfs fi df /mnt
Data, RAID0: total=13.95GB, used=13.82GB
Data: total=8.00MB, used=0.00
System, RAID1: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=1.02GB, used=19.09MB
Metadata: total=8.00MB, used=0.00
Two minutes later I get more from dmesg since btrfs is blocked:
http://pastebin.com/BznS3dF0
The volume can't be unmounted and the stuck process can't be killed. So I reboot. Mounting it produces:
[ 45.540143] device label filltest devid 1 transid 17 /dev/sdb
[ 45.545417] btrfs: disk space caching is enabled
[ 45.566326] btrfs: free space inode generation (0) did not match free space cache generation (1858)
[ 45.598677] btrfs: free space inode generation (0) did not match free space cache generation (1832)
[ 45.794886] btrfs: unlinked 1 orphans
Otherwise the file system seems fine. And
btrfs balance start -dconvert=single /mnt
Does eventually unwind the problem.
If the scenario allows adding a 4th device to this situation, it's faster because the balance isn't required. Thus deleting the (hypothetically troublesome) device occurs more quickly while also not requiring significant write capability to it.
Chris Murphy
prev parent reply other threads:[~2012-10-27 18:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-22 4:32 device delete, error removing device Chris Murphy
2012-10-22 5:04 ` dima
2012-10-22 5:30 ` Chris Murphy
2012-10-22 6:02 ` Chris Murphy
2012-10-22 9:19 ` Hugo Mills
2012-10-22 16:42 ` Chris Murphy
2012-10-22 17:04 ` Goffredo Baroncelli
2012-10-22 19:36 ` Chris Murphy
2012-10-22 19:50 ` Hugo Mills
2012-10-22 20:35 ` Goffredo Baroncelli
2012-10-22 20:46 ` Chris Murphy
2012-10-22 17:18 ` Hugo Mills
2012-10-23 7:57 ` Michael Kjörling
2012-10-23 18:10 ` Goffredo Baroncelli
2012-10-23 18:17 ` Chris Murphy
2012-10-23 19:02 ` Goffredo Baroncelli
2012-10-23 20:28 ` Chris Murphy
2012-10-23 22:16 ` Goffredo Baroncelli
2012-10-23 22:29 ` Chris Murphy
2012-10-24 18:06 ` device delete, error removing device [SOLVED] Goffredo Baroncelli
2012-10-24 19:13 ` Chris Murphy
2012-10-24 21:30 ` Goffredo Baroncelli
2012-10-24 21:43 ` Chris Murphy
2012-10-25 19:26 ` Goffredo Baroncelli
2012-10-27 18:25 ` Chris Murphy [this message]
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=6FC0FD8D-EC25-41DF-BF07-04648A2D0E87@colorremedies.com \
--to=lists@colorremedies.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 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.