Message-ID: <49474FE4.2030500@sandeen.net>
Date: Tue, 16 Dec 2008 00:51:16 -0600
From: Eric Sandeen <sandeen@sandeen.net>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: lachlan@sgi.com
CC: xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] fix corruption case for block size < page size
References: <49435F35.40109@sandeen.net>	<4943FCD7.2010509@sandeen.net>	<494735D9.8020809@sgi.com>	<49473F5C.3070308@sandeen.net>	<49474530.2080809@sgi.com>	<4947466D.7000705@sandeen.net> <494748FA.20404@sandeen.net>
In-Reply-To: <494748FA.20404@sandeen.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Eric Sandeen wrote:

> Gah; or not.  what is going on here...  Doing just steps 1, 2, 3, 4
> (ending on the extending truncate):
> 
> # 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 514" -t -d -f
> /mnt/scratch/testfile
> 
> # xfs_bmap -v /mnt/scratch/testfile
> /mnt/scratch/testfile:
>  EXT: FILE-OFFSET      BLOCK-RANGE      AG AG-OFFSET        TOTAL
>    0: [0..0]:          63..63            0 (63..63)             1
>    1: [1..1]:          hole                                     1
> 
> It looks like what I expect, at this point.  But then:
> 
> # sync
> # xfs_bmap -v /mnt/scratch/testfile
> /mnt/scratch/testfile:
>  EXT: FILE-OFFSET      BLOCK-RANGE      AG AG-OFFSET        TOTAL
>    0: [0..1]:          63..64            0 (63..64)             2
> 
> Um, why'd that last block get mapped in?  mmap vs. direct IO I'm
> guessing... w/o the mmap read this does not happen.

Replying to myself twice?  I really need to go to bed.

So this all does seem to come back to page_state_convert.

Both the extending write in the original case and the sync above find
their way there; but esp. in the sync test above, why do we have *any*
work to do?

With a little instrumentation I see that for the truncate out; sync test
above we get to xfs_vm_writepage() for a page which is *not* dirty, and
yet we call page_state_convert on it and map in that 2nd block... Is
that right!?  I guess it is; ->write_cache_pages() clears dirty before
calling writepage.  Still why would this page be found dirty on this
path.  Bah.  Bedtime.

-Eric