public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Alain Renaud <arenaud@sgi.com>
To: xfs@oss.sgi.com
Subject: [PATCH 0/1] xfstest: using extsize cause corruption with multi buffer page
Date: Fri, 01 Jun 2012 14:58:15 -0400	[thread overview]
Message-ID: <20120601185815.883227033@sgi.com> (raw)


Hi all,

  I just found a problem which cause file corruption with filesystem that 
have block size smaller then the page size. The problem occur when
using extsize on file and having multiple extents in the same PAGE.

The scenario that I am looking at is a page that look like this:
buffer  content
0       empty  b_state = 0
1       DATA   b_state = 0x1023
2       DATA   b_state = 0x1023
3       empty  b_state = 0
4       empty  b_state = 0
5       DATA   b_state = 0x1023
6       DATA   b_state = 0x1023
7       empty  b_state = 0

At the end the extent should look like this

0   : unwritten extent.
1-2 : real extent
3-4 : unwritten extent.
5-6 : real extent.
7-EOF : unwritten extent.

However the current version of xfs_vm_writepage() will put all the buffer in 
the page into 1 ioend which cause the extent list to look like this.

0   : unwritten extent.
1-4 : real extent
5-EOF : unwritten extent.

The test generate a 'template' file which is created
without using extsize look like this.

# xfs_bmap -vp /xfsqa_scratch/testdir/template 
/xfsqa_scratch/testdir/template:
 EXT: FILE-OFFSET      BLOCK-RANGE      AG AG-OFFSET        TOTAL FLAGS
   0: [0..8]:          hole                                     9
   1: [9..23]:         48..62            0 (48..62)            15 00000
# hexdump  /xfsqa_scratch/testdir/template
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0001200 4242 4242 4242 4242 4242 4242 4242 4242
*
0001600 0000 0000 0000 0000 0000 0000 0000 0000
*
0001a00 4343 4343 4343 4343 4343 4343 4343 4343
*
0001e00 0000 0000 0000 0000 0000 0000 0000 0000
*
0003000

The test file which is created with 'extsize == 10 pages' give us
this result.
(notice block 13-12 are unwritten but should contain the 'C')

# xfs_bmap -vp /xfsqa_scratch/testdir/zfile-00 
/xfsqa_scratch/testdir/zfile-00:
 EXT: FILE-OFFSET      BLOCK-RANGE      AG AG-OFFSET        TOTAL FLAGS
   0: [0..8]:          167..175          0 (167..175)           9 10000
   1: [9..12]:         176..179          0 (176..179)           4 00000
   2: [13..23]:        180..190          0 (180..190)          11 10000
# hexdump  /xfsqa_scratch/testdir/zfile-00 
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0001200 4242 4242 4242 4242 4242 4242 4242 4242
*
0001600 0691 3c24 d01f 3de9 0597 3e65 b312 3ebf
*
0003000

Looking at the xfs_db output I know that the data get correctly written
to disk but the coversion from unwritten to real seem broken. I have
Isolated the problem to the fact that all buffer in the page are put
into a single xfs_ioend instead of 2. I will propose a fix in a separate
patch. This test is only to show the problem

-- 
===============================================
Alain Renaud     - Cluster File System Engineer 
arenaud@sgi.com  - SGI
===============================================

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

             reply	other threads:[~2012-06-01 18:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-01 18:58 Alain Renaud [this message]
2012-06-01 18:58 ` [PATCH 1/1] xfstest: using extsize cause corruption with multi buffer page Alain Renaud
2012-06-05  9:13   ` Dave Chinner
2012-06-05 12:22     ` Alain Renaud
2012-07-13 10:15       ` [PATCH v2] xfstest: test corruption with multi extent in PAGE Alain Renaud
2012-07-13 18:23         ` Mark Tinguely

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=20120601185815.883227033@sgi.com \
    --to=arenaud@sgi.com \
    --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