Re: [PATCH] fix corruption case for block size < page size

From: Eric Sandeen <sandeen@sandeen.net>
To: lachlan@sgi.com
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] fix corruption case for block size < page size
Date: Tue, 06 Jan 2009 23:53:32 -0600	[thread overview]
Message-ID: <4964435C.802@sandeen.net> (raw)
In-Reply-To: <49643C5A.30608@sgi.com>

Lachlan McIlroy wrote:
> Eric Sandeen wrote:
>> 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?
> Eric, did you find out why sync was allocating that second block?

I'm afraid this has been on the back burner (or maybe further back) for
a while... so... either "no" or "I don't remember" :)

-Eric

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