On Wed, Oct 14, 2009 at 12:09 AM, Hugo Mills <hugo-lkml@xxxxxxxxxxxxx> wrote: > On Tue, Oct 13, 2009 at 10:58:12PM +0800, Yan, Zheng wrote: >> On Tue, Oct 13, 2009 at 10:50 PM, Hugo Mills <hugo-lkml@xxxxxxxxxxxxx> wrote: >> > On Tue, Oct 13, 2009 at 06:31:45AM -0400, Chris Mason wrote: >> >> On Mon, Oct 12, 2009 at 03:09:35PM +0100, Hugo Mills wrote: >> >> > On Sun, Oct 04, 2009 at 08:06:30AM -0400, Chris Mason wrote: >> >> > > On Sat, Oct 03, 2009 at 05:55:32PM -0400, Josef Bacik wrote: >> >> > > > On Sat, Oct 03, 2009 at 01:21:09PM +0100, Hugo Mills wrote: >> >> > > > > I've just had the following on my home server. I believe that it's >> >> > > > > btrfs that's responsible, as the machine wasn't doing much other than >> >> > > > > reading/writing on a btrfs filesystem. The process that was doing so >> >> > > > > is now stuck in D+ state, and can't be killed. The timing of the oops >> >> > > > > at the end is also suggestive of being involved in the same incident. >> >> > > > > This is the only btrfs filesystem on the machine. >> >> > > > >> >> > > > Patches have gone to Linus to fix the enospc problems. You can try running the >> >> > > > enospc branch of Chris's git tree and it should behave better for you. Thanks, >> >> > > >> >> > > The right tree for this is the master branch of btrfs-unstable for >> >> > > 2.6.31. >> >> > >> >> > Thanks, Josef and Chris. I've now found the time to check out and >> >> > build the btrfs-unstable tree, and it is indeed handling the ENOSPC >> >> > condition much more cleanly. >> >> > >> >> > However, it seems to have got into a position where I have lots of >> >> > free space reported by df (over 10% of the size of the volume -- 185 >> >> > GiB free of 1474 GiB total), but still refuses to write anything to >> >> > the filesystem. Do you have any suggestions for what I could try? >> >> >> >> You've probably got most of that 10GB free allocated as metadata. You >> >> could try btrfs-vol -b. >> > >> > I moved some 13 GiB of data off the filesystem, and ran >> > btrfs-vol -b. As I reported on IRC, I then got this in my syslog: >> > >> > Oct 13 13:16:19 vlad kernel: btrfs: relocating block group 1401224691712 flags 1 >> > Oct 13 13:17:02 vlad kernel: btrfs: found 123 extents >> > Oct 13 13:17:10 vlad kernel: btrfs: found 123 extents >> > Oct 13 13:17:11 vlad kernel: btrfs: found 28 extents >> > Oct 13 13:17:21 vlad kernel: btrfs: found 28 extents >> > Oct 13 13:17:25 vlad kernel: btrfs: found 28 extents >> > Oct 13 13:17:26 vlad kernel: btrfs: found 27 extents >> > Oct 13 13:17:36 vlad kernel: btrfs: found 27 extents >> > Oct 13 13:17:39 vlad kernel: btrfs: found 27 extents >> > Oct 13 13:17:48 vlad kernel: btrfs: found 27 extents >> > ... repeat forever (or at least for 50 minutes or so). >> > >> > The btrfs-vol -b process didn't respond to ^C, so on advice of >> > yanzheng on IRC I rebooted the machine. I'm currently running a >> > btrfsck on the filesystem, and will try btrfs-vol -b again when that's >> > done. >> > >> don't do that, It will run into infinite loop again. > I got this from the btrfsck: > hrm@vlad:~ $ sudo btrfsck /dev/media/scratch > root 5 inode 3949 errors 2000 > found 1366552736241 bytes used err is 1 > total csum bytes: 1336783032 > total tree bytes: 1944158208 > total fs tree bytes: 20267008 > btree space waste bytes: 462357950 > file data blocks allocated: 1368865824768 > referenced 1368851816448 > Btrfs Btrfs v0.19 > I guess that means that there were errors found -- is the btrfs-vol > -b still going to cause an infinite loop, or is it worth trying that > again? > Hugo. Yes, there is an error. One inode's link count is wrong. It's unlikely the error is caused by "btrfs-vol -b", but I'm not sure. Don't run btrfs-vol -b, it will enter infinite loop again. Yan, Zheng -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
