From: Chris Mason <chris.mason@fusionio.com>
To: David Sterba <dsterba@suse.cz>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
Josef Bacik <jbacik@fusionio.com>
Subject: Re: [bug] csum mismatches and failed xfstests with 3.8-rc1
Date: Fri, 4 Jan 2013 08:01:44 -0500 [thread overview]
Message-ID: <20130104130144.GF14537@shiny> (raw)
In-Reply-To: <20130104125059.GE20089@twin.jikos.cz>
Thanks Dave,
On Fri, Jan 04, 2013 at 05:50:59AM -0700, David Sterba wrote:
> Hi,
>
> I've noticed a few csum mismatch messages, and a few failed xfstests:
>
> - 3.8.0-rc1
> - defautl mkfs options
> - MOUNT_OPTIONS -- -o space_cache,noatime,inode_cache
> - test device: 40G
> - scratch device: 10G
Josef, are the problems you see with 083 coming on the scratch drive or
the main disk?
>
> 091:
> --- 091.out 2011-11-01 10:31:12.000000000 +0100
> +++ 091.out.bad 2013-01-03 21:07:29.000000000 +0100
> @@ -1,7 +1,45 @@
> QA output created by 091
> fsx -N 10000 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
> -fsx -N 10000 -o 8192 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
> -fsx -N 10000 -o 32768 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
> -fsx -N 10000 -o 8192 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
> -fsx -N 10000 -o 32768 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
> -fsx -N 10000 -o 128000 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -W
> +fsx -N 10000 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z -R -W
> +mapped writes DISABLED
> +truncating to largest ever: 0x12a00
> +truncating to largest ever: 0x75400
> +doread: read: Input/output error
> +LOG DUMP (35 total operations):
> +1( 1 mod 256): SKIPPED (no operation)
> +2( 2 mod 256): WRITE 0x62600 thru 0x6bdff (0x9800 bytes) HOLE
> +3( 3 mod 256): FALLOC 0x2e0f2 thru 0x3134a (0x3258 bytes) INTERIOR
> +4( 4 mod 256): TRUNCATE DOWN from 0x6be00 to 0x12a00
> +5( 5 mod 256): READ 0x0 thru 0xdfff (0xe000 bytes)
> +6( 6 mod 256): FALLOC 0x7048 thru 0x9f54 (0x2f0c bytes) INTERIOR
> +7( 7 mod 256): WRITE 0x5ea00 thru 0x6e7ff (0xfe00 bytes) HOLE
> +8( 8 mod 256): READ 0x16000 thru 0x17fff (0x2000 bytes)
> +9( 9 mod 256): FALLOC 0x4957f thru 0x5298e (0x940f bytes) INTERIOR
> +10( 10 mod 256): SKIPPED (no operation)
> +11( 11 mod 256): WRITE 0x10a00 thru 0x173ff (0x6a00 bytes)
> +12( 12 mod 256): WRITE 0x53800 thru 0x5a7ff (0x7000 bytes)
> +13( 13 mod 256): WRITE 0x5ae00 thru 0x5afff (0x200 bytes)
> +14( 14 mod 256): READ 0x5d000 thru 0x66fff (0xa000 bytes)
> +15( 15 mod 256): SKIPPED (no operation)
> +16( 16 mod 256): READ 0x21000 thru 0x2bfff (0xb000 bytes)
> +17( 17 mod 256): SKIPPED (no operation)
> +18( 18 mod 256): READ 0x47000 thru 0x4ffff (0x9000 bytes)
> +19( 19 mod 256): WRITE 0x17600 thru 0x25bff (0xe600 bytes)
> +20( 20 mod 256): READ 0x3f000 thru 0x48fff (0xa000 bytes)
> +21( 21 mod 256): FALLOC 0xea89 thru 0x19800 (0xad77 bytes) INTERIOR
> +22( 22 mod 256): FALLOC 0x569aa thru 0x586ea (0x1d40 bytes) INTERIOR
> +23( 23 mod 256): WRITE 0x35c00 thru 0x453ff (0xf800 bytes)
> +24( 24 mod 256): SKIPPED (no operation)
> +25( 25 mod 256): SKIPPED (no operation)
> +26( 26 mod 256): READ 0x21000 thru 0x26fff (0x6000 bytes)
> +27( 27 mod 256): READ 0x5e000 thru 0x61fff (0x4000 bytes)
> +28( 28 mod 256): WRITE 0x6f600 thru 0x6f7ff (0x200 bytes) HOLE
> +29( 29 mod 256): READ 0x13000 thru 0x19fff (0x7000 bytes)
> +30( 30 mod 256): TRUNCATE UP from 0x6f800 to 0x75400
> +31( 31 mod 256): READ 0x4000 thru 0xafff (0x7000 bytes)
> +32( 32 mod 256): SKIPPED (no operation)
> +33( 33 mod 256): FALLOC 0x31d49 thru 0x3c520 (0xa7d7 bytes) INTERIOR
> +34( 34 mod 256): FALLOC 0x2bbb3 thru 0x37ad8 (0xbf25 bytes) INTERIOR
> +35( 35 mod 256): READ 0x68000 thru 0x73fff (0xc000 bytes)
> +Correct content saved for comparison
> +(maybe hexdump "/mnt/a1/junk" vs "/mnt/a1/junk.fsxgood")
>
> I'm not quite sure if the messages match the test (best guess, neighbouring
> tests were fine):
>
> [102885.667444] btrfs csum failed ino 638 off 425984 csum 1842675109 private 2279232751
> [102885.676804] btrfs csum failed ino 638 off 430080 csum 1842675109 private 1192041375
> [102885.686094] btrfs csum failed ino 638 off 434176 csum 2297282744 private 1619428542
> [102885.686103] btrfs csum failed ino 638 off 438272 csum 3709984297 private 2868627320
> [102885.686112] btrfs csum failed ino 638 off 442368 csum 1504116677 private 1239355148
> [102885.686121] btrfs csum failed ino 638 off 446464 csum 1957839041 private 3848200057
> [102885.686129] btrfs csum failed ino 638 off 450560 csum 3836729483 private 2867416946
I think fsx leaves the bad file, you can test the inode number?
>
>
> 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
Hmmm, I wonder if something else in rc1 is causing this?
-chris
next prev parent reply other threads:[~2013-01-04 13:01 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 [this message]
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 ` [bug] csum mismatches and failed xfstests with 3.8-rc1 -rc4 David Sterba
2013-01-22 14:39 ` 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=20130104130144.GF14537@shiny \
--to=chris.mason@fusionio.com \
--cc=dsterba@suse.cz \
--cc=jbacik@fusionio.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).