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
|