From: Eric Sandeen <sandeen@sandeen.net>
To: xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] fix corruption case for block size < page size
Date: Sat, 13 Dec 2008 12:20:07 -0600 [thread overview]
Message-ID: <4943FCD7.2010509@sandeen.net> (raw)
In-Reply-To: <49435F35.40109@sandeen.net>
Eric Sandeen wrote:
> On a 4k page system and 512-byte blocksize, this:
>
> xfs_io \
> -c "pwrite -S 0x11 -b 4096 0 4096" \
> -c "mmap -r 0 512" -c "mread 0 512" -c "munmap" \
> -c "truncate 256" \
> -c "truncate 513" \
> -c "pwrite -S 0x22 -b 512 2048 512" \
> -t -d -f testfile
Not to keep belaboring the point, but if anyone reviews this here's a
bit more info.
If I blktrace the testcase it looks like this:
8,16 0 1 0.000000000 4222 C W 166979666 + 8 [0] 4k wr
8,16 0 2 0.000367043 4222 C R 166979666 + 8 [0] 4k map rd
8,16 0 3 0.002923548 4222 C N (35 00 ..) [0]
8,16 0 4 0.003108924 4222 C W 200708307 + 9 [0] Log?(trunc)
8,16 0 5 0.020357902 4222 C N (35 00 ..) [0]
8,16 0 6 0.020361434 4222 C W 200708307 + 9 [0] Log?(trunc)
8,16 0 7 0.020745509 4222 C W 166979666 + 1 [0] 512 wr @0
8,16 0 8 0.020940005 4222 C W 166979667 + 1 [0] 512 wr @1
8,16 0 9 0.021172749 4222 C W 166979670 + 1 [0] 512 wr @4
and a detailed look at the data on disk is this:
00000000 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 Block 0(OK)
*
00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Block 0...
*
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Block 1(OK)
*
00000400 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 Block 2(BAD)
*
00000600 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 Block 3(BAD)
*
00000800 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 Block 4(OK)
*
00000a00
And the bmap information is this:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL
0: [0..4]: 56..60 0 (56..60) 5
So the bad data in blocks 2 and 3 were never rewritten; the buffer heads
probably were fine (containing 0's, but I should check) and we simply
re-mapped blocks 2 and 3 back into existence, along with their stale
data, it seems.
So I think this was just a bad mapping decision, and not a buffer head
state/zeroing problem...?
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2008-12-13 18:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-13 7:07 [PATCH] fix corruption case for block size < page size Eric Sandeen
2008-12-13 17:48 ` Eric Sandeen
2008-12-13 18:20 ` Eric Sandeen [this message]
2008-12-16 5:00 ` Lachlan McIlroy
2008-12-16 5:40 ` Eric Sandeen
2008-12-16 6:05 ` Lachlan McIlroy
2008-12-16 6:10 ` Eric Sandeen
2008-12-16 6:21 ` Eric Sandeen
2008-12-16 6:51 ` Eric Sandeen
2009-01-07 5:23 ` Lachlan McIlroy
2009-01-07 5:53 ` Eric Sandeen
2009-01-07 6:32 ` Lachlan McIlroy
2009-01-07 21:42 ` Dave Chinner
2009-01-09 0:18 ` Lachlan McIlroy
2008-12-16 7:54 ` Lachlan McIlroy
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=4943FCD7.2010509@sandeen.net \
--to=sandeen@sandeen.net \
--cc=xfs@oss.sgi.com \
/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