From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id mBG6pIJb016812 for ; Tue, 16 Dec 2008 00:51:19 -0600 Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D3D5D173A30D for ; Mon, 15 Dec 2008 22:51:17 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id Q75xOdg57WzKWM7D for ; Mon, 15 Dec 2008 22:51:17 -0800 (PST) Message-ID: <49474FE4.2030500@sandeen.net> Date: Tue, 16 Dec 2008 00:51:16 -0600 From: Eric Sandeen MIME-Version: 1.0 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> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: lachlan@sgi.com Cc: xfs-oss 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 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs