All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liu Bo <bo.li.liu@oracle.com>
To: Kenny MacDermid <kenny.macdermid@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs issues in 3.14
Date: Fri, 9 May 2014 18:54:25 +0800	[thread overview]
Message-ID: <20140509105424.GC4250@localhost.localdomain> (raw)
In-Reply-To: <CAEVbaUctopBtA2Db6+OEt-=sYngXs+WJ-+Jyfc3RXWP_5eTowQ@mail.gmail.com>

On Thu, May 08, 2014 at 10:51:03AM -0300, Kenny MacDermid wrote:
> On Wed, May 7, 2014 at 11:48 PM, Liu Bo <bo.li.liu@oracle.com> wrote:
> >
> > On Wed, May 07, 2014 at 09:35:06AM -0300, Kenny MacDermid wrote:
> > > On Tue, May 6, 2014 at 11:22 PM, Liu Bo <bo.li.liu@oracle.com> wrote:
> > > >
> > > > What does sysrq+w say when the hang happens?
> > >
> > > The whole system isn't hung, I may have explained that wrong. The
> > > system will hang if I try to shutdown, and the process will hang if I
> > > try to kill -9 it.
> > >
> > > It looks like the browser is in this state currently so I did an 'echo
> > > w >/proc/sysrq-trigger' and have attached the full dmesg with the
> > > browser issues and the output.
> >
> > Those stacks show the blocked tasks are waiting for a page's writeback, but
> > they don't show what blocks the endio process of that page.
> >
> > I'd recommand you to try the lastest 3.15.0-rc4 or btrfs-next, as many fixes
> > are merged during this period.
> >
> 
> Thank you, I upgraded to the Arch package for 3.15.0-1-mainline (it's
> rc4) and I'll let you know if the errors reoccur.

FYI, this patch seems to address your problem.

Btrfs: fix hang on error (such as ENOSPC) when writing extent pages
https://patchwork.kernel.org/patch/4139971/

-liubo

> 
> Should the filesystem be rebuilt again?
> 
> A 'btrfs check' of it returned:
> 
> checking extents
> checking free space cache
> checking fs roots
> checking csums
> checking root refs
> Checking filesystem on /dev/mapper/home
> UUID: 9a60a25f-eeb4-494c-b1af-ebd8e4f79b6b
> free space inode generation (0) did not match free space cache generation (6409)
> free space inode generation (0) did not match free space cache generation (6397)
> found 41686685877 bytes used err is 0
> total csum bytes: 74074632
> total tree bytes: 907673600
> total fs tree bytes: 807567360
> total extent tree bytes: 18251776
> btree space waste bytes: 116552179
> file data blocks allocated: 112191107072
>  referenced 75535110144
> Btrfs v3.14.1

      reply	other threads:[~2014-05-09 10:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-06 23:49 btrfs issues in 3.14 Kenny MacDermid
2014-05-07  2:22 ` Liu Bo
2014-05-07 12:35   ` Kenny MacDermid
2014-05-07 13:13     ` Kenny MacDermid
2014-05-08  2:48     ` Liu Bo
2014-05-08 13:51       ` Kenny MacDermid
2014-05-09 10:54         ` Liu Bo [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=20140509105424.GC4250@localhost.localdomain \
    --to=bo.li.liu@oracle.com \
    --cc=kenny.macdermid@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 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.