All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: David Sterba <dsterba@suse.cz>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [bug] csum mismatches and failed xfstests with 3.8-rc1 -rc4
Date: Tue, 22 Jan 2013 15:26:15 +0100	[thread overview]
Message-ID: <20130122142615.GD28263@twin.jikos.cz> (raw)
In-Reply-To: <20130104125059.GE20089@twin.jikos.cz>

On Fri, Jan 04, 2013 at 01:50:59PM +0100, David Sterba wrote:
> I've noticed a few csum mismatch messages, and a few failed xfstests:

They're still there, we're on rc4, so I started looking for potential
patches to revert, but tonight the test reproduced csums with these
patches removed:

 Btrfs: do not call file_update_time in aio_write
 Btrfs: only unlock and relock if we have to
 Btrfs: use tokens where we can in the tree log
 Btrfs: only clear dirty on the buffer if it is marked as dirty
 Btrfs: log changed inodes based on the extent map tree
 Btrfs: do not mark ems as prealloc if we are writing to them
 Btrfs: keep track of the extents original block length
 Btrfs: inline csums if we're fsyncing
 Btrfs: don't bother copying if we're only logging the inode
 Btrfs: only log the inode item if we can get away with it

whole branch (test-next-csum in my git repo), was created by rebasing
btrfs-next/for-chris on top of linus/master commit
9a9284153d965a57edc7162a8e57c14c97f3a935.

The patches were selected semi-randomly and some of them are just
dependencies that made merging easier.

> 113:
> - it hung last evening and is still in that state, no disk or cpu activity,
>   there were only the tests running
> - no process is in D state, no btrfs kernel thread is active
> - the only interesting process is
> 
>   PID TTY      STAT   TIME COMMAND
> 15585 pts/0    Sl+    0:01 /root/xfstests/ltp/aio-stress -t 20 -s 10  -O -S -I	\
> 	1000 /mnt/a1/aiostress.15188.4 /mnt/a1/aiostress.15188.4.20		\
> 	/mnt/a1/aiostress.15188.4.19 /mnt/a1/aiostress.15188.4.18		\
> [<ffffffff810af447>] futex_wait_queue_me+0xc7/0x100
> [<ffffffff810affa1>] futex_wait+0x191/0x280
> [<ffffffff810b1cb6>] do_futex+0xd6/0xbd0
> [<ffffffff810b282b>] sys_futex+0x7b/0x180
> [<ffffffff8195fe99>] system_call_fastpath+0x16/0x1b

also reproduced, this happens like every 3rd run of the whole test.


david

  parent reply	other threads:[~2013-01-22 14:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-04 12:50 [bug] csum mismatches and failed xfstests with 3.8-rc1 David Sterba
2013-01-04 13:01 ` Chris Mason
2013-01-04 13:45   ` David Sterba
2013-01-07 17:03 ` [bug] csum mismatches and failed xfstests with 3.8-rc1 and rc2 David Sterba
2013-01-07 17:06   ` David Sterba
2013-01-08  1:17     ` Chris Mason
2013-01-22 14:26 ` David Sterba [this message]
2013-01-22 14:39   ` [bug] csum mismatches and failed xfstests with 3.8-rc1 -rc4 Chris Mason
2013-01-23  6:16     ` Liu Bo

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=20130122142615.GD28263@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --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.