sparse file handling bug in XFS

[Eric Sandeen]

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 at redhat.com>

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 at redhat.com>
---
 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