Eric Sandeen wrote:
> Lachlan McIlroy wrote:
>> Eric Sandeen wrote:
>>> Actually; after the truncate down step (3) we should have:
>>>
>>> |<--------trunc-----------------------
>>> 3: |11??| trunc down to 1/2 block
>>> ^
>>> |
>>> EOF
>>>
>>> Hm, but does the end of this block get zeroed now or only when we
>>> subsequently extend the size? The latter I think...?
>> Only when extending the file size.
>
> Right.
>
>>> So I think in the next step:
>>>
>>> trunc-->|
>>> 4: |1100| trunc up to block+1byte
>>> ^^
>>> now || this part of the block gets zeroed, right, by xfs_zero_eof?
>> Yes (by xfs_zero_last_block()).
>
> Right. :) But I *think* that after this step we are actually zeroing
> into block 1 (2nd block) and causing it to get zeroed/mapped. Off by
> one maybe?
>
>>>> Because of the truncate to 256 bytes
>>>> only the first block is allocated and everything beyond 512 bytes is
>>>> a hole.
>>> Yep, up until the last write anyway.
>>>
>>>> More specifically there is a hole under the remainder of the
>>>> page so xfs_zero_eof() will skip that region and not zero anything.
>>> Well, the last write (step 5) is still completely within the page...
>>>
>>> Right, that's what it *should* be doing; but in page_state_convert (and
>>> I'll admit to not having this 100% nailed down) we write block 1 and map
>>> blocks 2 & 3 back into the file, and get:
>>>
>>> # |1100|0000|1111|1111|2222|----|----|----|
>>> ^^^^ ^^^^
>>> where these |||| |||| blocks are stale data, and block 1 is written
>>> (but at least zeroed). How block 1 got zeroed I guess I'm not quite
>> I think block 1 got zeroed during the last write because the file size
>> was extended from 513 to 2048. Byte 513 is just inside block 1. But
>> that block should have been a hole and xfs_zero_last_block() should
>> have skipped it.
>
> I think the 2nd extending write does skip it but from a bit more looking
> the first extending truncate might step into it by one... still looking
> into that.
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.
-Eric (heading to bed now...)
|