On 04/24/2015 02:34 AM, Filipe David Manana wrote: > On Thu, Apr 23, 2015 at 8:50 PM, Chris Mason <c...@fb.com> wrote: >> On 04/23/2015 03:43 PM, Filipe David Manana wrote: >>> On Thu, Apr 23, 2015 at 4:48 PM, Filipe David Manana <fdman...@gmail.com> >>> wrote: >>>> On Thu, Apr 23, 2015 at 4:17 PM, Chris Mason <c...@fb.com> wrote: >>>>> On Thu, Apr 23, 2015 at 02:05:48PM +0100, Filipe David Manana wrote: >>>>>>>> Trying the current integration-4.1 branch, I ran into the following >>>>>>>> during xfstests/btrfs/049: >>>>>>>> >>>>>>> >>>>>>> Ugh, I must not be waiting correctly in one of the inode cache writeout >>>>>>> sections. But I've run 049 a whole bunch of times without triggering, >>>>>>> can you get this to happen consistently? >>>>>> >>>>>> All the time so far. >>>>> >>>>> I'm testing with this now: >>>>> >>>>> commit 9f433238891b1b243c4f19d3f36eed913b270cbc >>>>> Author: Chris Mason <c...@fb.com> >>>>> Date: Thu Apr 23 08:02:49 2015 -0700 >>>>> >>>>> Btrfs: fix inode cache writeout >>>>> >>>>> The code to fix stalls during free spache cache IO wasn't using >>>>> the correct root when waiting on the IO for inode caches. This >>>>> is only a problem when the inode cache is enabled with >>>>> >>>>> mount -o inode_cache >>>>> >>>>> This fixes the inode cache writeout to preserve any error values and >>>>> makes sure not to override the root when inode cache writeout is done. >>>>> >>>>> Reported-by: Filipe Manana <fdman...@suse.com> >>>>> Signed-off-by: Chris Mason <c...@fb.com> >>>> >>>> Thanks, btrfs/049 now passes with that patch applied. >>>> Running the whole xfstests suite now. >>> >>> btrfs/066 also failed once during final fsck with: >>> >>> _check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent >>> *** fsck.btrfs output *** >>> checking extents >>> checking free space cache >>> There is no free space entry for 21676032-21680128 >>> There is no free space entry for 21676032-87031808 >>> cache appears valid but isnt 20971520 >> >> Josef has a btrfs-progs patch for this. The kernel will toss the cache. >> There's a somewhat fundamental race in cache writeout this patch makes >> a little bigger, but it has always been there. >> >> (compare what find_free_extent can do with no trans running vs the >> actual cache writeback) > > There's also one list corruption I didn't get before and happened > while running fsstress (btrfs/078), apparently due to some race:
Can you please bang on this and get a more reliable reproduction? I'll take a look. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
