xfs
[Top] [All Lists]

Re: [PATCH v2 2/7] xfs: add support FALLOC_FL_COLLAPSE_RANGE for falloca

To: Mark Tinguely <tinguely@xxxxxxx>
Subject: Re: [PATCH v2 2/7] xfs: add support FALLOC_FL_COLLAPSE_RANGE for fallocate
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 29 May 2014 08:48:59 +1000
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140528002906.GH8554@dastard>
References: <1378132151-2685-1-git-send-email-linkinjeon@xxxxxxxxx> <53850F92.7010401@xxxxxxx> <20140527225138.GD8554@dastard> <53851836.2070301@xxxxxxx> <20140528002906.GH8554@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, May 28, 2014 at 10:29:06AM +1000, Dave Chinner wrote:
> On Tue, May 27, 2014 at 05:56:54PM -0500, Mark Tinguely wrote:
> > On 05/27/14 17:51, Dave Chinner wrote:
> > >On Tue, May 27, 2014 at 05:20:02PM -0500, Mark Tinguely wrote:
> > >>On 09/02/13 09:29, Namjae Jeon wrote:
> > >>>From: Namjae Jeon<namjae.jeon@xxxxxxxxxxx>
> > >>>
> > >>>Add support FALLOC_FL_COLLAPSE_RANGE for fallocate.
> > >>>
> > >>>Signed-off-by: Namjae Jeon<namjae.jeon@xxxxxxxxxxx>
> > >>>Signed-off-by: Ashish Sangwan<a.sangwan@xxxxxxxxxxx>
> > >>>---
> > >>
> > >>>+                /* Check if we can merge 2 adjacent extents */
> > >>>+                if ((state&  BMAP_LEFT_VALID)&&  !(state&  
> > >>>BMAP_LEFT_DELAY)&&
> > >>>+                    left.br_startoff + left.br_blockcount == startoff&&
> > >>>+                    left.br_startblock + left.br_blockcount ==
> > >>>+                    xfs_bmbt_get_startblock(gotp)&&
> > >>>+                    xfs_bmbt_get_state(gotp) == left.br_state&&
> > >>>+                    left.br_blockcount + xfs_bmbt_get_blockcount(gotp)<=
> > >>>+                    MAXEXTLEN) {
> > >>>+                        blockcount =
> > >>>+                        left.br_blockcount + 
> > >>>xfs_bmbt_get_blockcount(gotp);
> > >>>+                        state |= BMAP_LEFT_CONTIG;
> > >>>+                        xfs_iext_remove(ip, *current_ext, 1, 0);
> > >>>+                        XFS_IFORK_NEXT_SET(ip, whichfork,
> > >>>+                                XFS_IFORK_NEXTENTS(ip, whichfork) - 1);
> > >>>+                        gotp = xfs_iext_get_ext(ifp, --*current_ext);
> > >>>+                }
> > >>>+
> > >>>+                if (cur) {
> > >>>+                        error = xfs_bmbt_lookup_eq(cur,
> > >>>+                                        xfs_bmbt_get_startoff(gotp),
> > >>>+                                        xfs_bmbt_get_startblock(gotp),
> > >>>+                                        xfs_bmbt_get_blockcount(gotp),
> > >>>+                                        &i);
> > >>>+                        if (error)
> > >>>+                                goto del_cursor;
> > >>>+                        XFS_WANT_CORRUPTED_GOTO(i == 1, del_cursor);
> > >>
> > >>I can reliably trigger this XFS_WANT_CORRUPTED_GOTO() with a
> > >>fsstress that fills the filesystem:
> > >>
> > >>xfstests>  ltp/fsstress -d /mnt/scratch -s 1370236858 -p 512 -n 8192&
> > >
> > >Hasn't reproduced after 10 minutes of running at ENOSPC here - how
> > >long does it take to reproduce? What storage hardware are you
> > >testing on? How many CPUs? RAM? ....
> > >
> > >http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F
> > >
> > >Cheers,
> > >
> > >Dave.
> > 
> > A 7-8 hours on spinning rust. This is my burn in test.
> 
> Can you try to narrow the problem down? Otherwise it's going to be a
> case of looking for a needle in a haystack....

The VMs I've left this running on have now been doing so for
almost 24 hours without triggering any issues. I'm really going to
need a more refined reproducer for this to confirm it is a real
problem and not a new machine burn-in issue...

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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