[Top] [All Lists]

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

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH v2 2/7] xfs: add support FALLOC_FL_COLLAPSE_RANGE for fallocate
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Thu, 29 May 2014 09:27:44 -0500
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: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 05/27/14 19:29, 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? ....




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....



Nod on the needle in a hay stack if it bmbt is really corrupt.

I am running fsstress from xfstests with the top commit 9b7f704, and I don't see any newer fsstress patches since then.

I moved the test to another box with a kdump that works on top of tree Linux and grabbed a vmcore. I grabbed a metadata dump of the filesystem after the ASSERT. That should give some idea of what inode/block it was looking up.

I sent email to Namjae when I first tripped over this problem in late April. No longer on the face of the earth and I can't look at this until the weekend.


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