xfs
[Top] [All Lists]

Re: xfs_io bmap confused

To: Ming Lin <mlin@xxxxxxxxxx>
Subject: Re: xfs_io bmap confused
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 9 Jul 2015 12:07:51 +1000
Cc: xfs@xxxxxxxxxxx, Christoph Hellwig <hch@xxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <1436338913.13729.11.camel@hasee>
References: <1436338913.13729.11.camel@hasee>
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, Jul 08, 2015 at 12:01:53AM -0700, Ming Lin wrote:
> Hi list,
> 
> I am testing some direct-io patches.
> xfs_tests/xfs/080 failed.
> 
> It's strange.
> There is no hole in "rwtest.file",
> but when read it at some offset it returns zero because of hole.
> 
> root@block:~# xfs_io -c bmap /mnt/test/rwtest.file
> /mnt/test/rwtest.file:
>              0: [0..125671]: 160..125831
> 
> Then I read at file offset 659456,
> root@block:~# dd if=/mnt/test/rwtest.file of=tmp.file bs=512 skip=1288 count=1
> 
> The code actually goes to below if statements.
> 
> Any idea what's wrong?

XFS maps unwritten extents as holes on read so that they are
correctly zeroed by the generic code. See this patch:

http://oss.sgi.com/archives/xfs/2007-07/msg00742.html

And the followup for why it should be done:

http://oss.sgi.com/archives/xfs/2007-07/msg00744.html

Sadly I was unable to convince anyone to take the patch, and so that
wart in XFS mapping behaviour still exists because the generic
readpage code still doesn't understand unwritten extents natively.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>