xfs
[Top] [All Lists]

Re: sparse file handling bug in XFS

To: Sean Noonan <Sean.Noonan@xxxxxxxxxxxx>
Subject: Re: sparse file handling bug in XFS
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 16 Jun 2011 12:33:49 -0500
Cc: "'linux-xfs@xxxxxxxxxxx'" <linux-xfs@xxxxxxxxxxx>, Martin Bligh <Martin.Bligh@xxxxxxxxxxxx>, Stephen Degler <Stephen.Degler@xxxxxxxxxxxx>, Ian Baum <Ian.Baum@xxxxxxxxxxxx>, Trammell Hudson <Trammell.Hudson@xxxxxxxxxxxx>
In-reply-to: <4DFA2A76.6000104@xxxxxxxxxxx>
References: <081DDE43F61F3D43929A181B477DCA95639B561F@xxxxxxxxxxxxxxxxxxxx> <4DFA2A76.6000104@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
On 6/16/11 11:08 AM, Eric Sandeen wrote:
> On 6/16/11 9:49 AM, Sean Noonan wrote:
>> Sparse files do not stay sparse.
>> Here's the simplest test case I've got so far.  I don't think it can get 
>> much simpler than this.
>>
>> This did not exist in 2.6.36.  It appeared by 2.6.38-rc8.  It continued into 
>> 2.6.38.2.  It continues to exist on 3.0.0-rc3.
>>
>> # for x in gogo xfs; do date | dd of=sparse-file bs=1k seek=4096; stat 
>> sparse-file; done
> 
> Funky; if we do xfs_bmap, it shows the right nr of blocks allocated:
> 
> # for x in gogo xfs; do date | dd of=sparse-file bs=1k seek=4096; stat 
> sparse-file | grep Blocks; xfs_bmap -v sparse-file; done
>   Size: 4194333       Blocks: 8          IO Block: 4096   regular file
> sparse-file:
>  EXT: FILE-OFFSET      BLOCK-RANGE          AG AG-OFFSET            TOTAL
>    0: [0..8191]:       hole                                          8192
>    1: [8192..8199]:    450475168..450475175  2 (18736320..18736327)     8
> 
>   Size: 4194333       Blocks: 8192       IO Block: 4096   regular file
> sparse-file:
>  EXT: FILE-OFFSET      BLOCK-RANGE          AG AG-OFFSET            TOTAL
>    0: [0..8191]:       hole                                          8192
>    1: [8192..8199]:    459367952..459367959  2 (27629104..27629111)     8
> 
> 
> And if we unmount & remount it's right again:
> 
> # stat sparse-file | grep Blocks
>   Size: 4194333       Blocks: 8          IO Block: 4096   regular file
> 
> so they do remain sparse, but stat tells us the wrong thing.  I think it has
> to do with the count of delayed blocks but I'll try to look into it.

Actually this looks like it's a result of

6e857567dbbfe14dd6cc3f7414671b047b1ff5c7 xfs: don't truncate prealloc from 
frequently accessed inodes

I thought Dave's patch from the "Re: drastic changes to allocsize semantics in 
or around 2.6.38?"
thread would fix it, but it doesn't seem to.  Here it is anyway ;)

xfs: clear inode dirty release flag when recycling it

From: Dave Chinner <dchinner@xxxxxxxxxx>

The state used to track dirty inode release calls is not reset when
an inode is reallocated and reused from the reclaimable state. This
leads to specualtive preallocation not being truncated away in the
expected manner for local files until the inode is subsequently
truncated, freed or cycles out of the cache.

Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
---
 fs/xfs/xfs_iget.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/fs/xfs/xfs_iget.c b/fs/xfs/xfs_iget.c
index cb9b6d1..e75e757 100644
--- a/fs/xfs/xfs_iget.c
+++ b/fs/xfs/xfs_iget.c
@@ -241,6 +241,13 @@ xfs_iget_cache_hit(
                 */
                ip->i_flags |= XFS_IRECLAIM;
 
+               /*
+                * clear the dirty release state as we are now effectively a
+                * new inode and so we need to treat speculative preallocation
+                * accordingly.
+                */
+               ip->i_flags &= ~XFS_IDIRTY_RELEASE;
+
                spin_unlock(&ip->i_flags_lock);
                rcu_read_unlock();


-Eric

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