On Wed, 5 Feb 2014 16:46:57 -0500 Josef Bacik <[email protected]> wrote: > > On 02/05/2014 04:42 PM, Johannes Hirte wrote: > > On Wed, 5 Feb 2014 14:36:39 -0500 > > Josef Bacik <[email protected]> wrote: > > > >> On 02/05/2014 02:30 PM, Johannes Hirte wrote: > >>> On Wed, 5 Feb 2014 14:00:57 -0500 > >>> Josef Bacik <[email protected]> wrote: > >>> > >>>> On 02/05/2014 12:34 PM, Johannes Hirte wrote: > >>>>> On Wed, 5 Feb 2014 10:49:15 -0500 > >>>>> Josef Bacik <[email protected]> wrote: > >>>>> > >>>>>> Ok none of those make sense which makes me think it may be the > >>>>>> ktime bits, instead of un-applying the whole patch could you > >>>>>> just comment out the parts > >>>>>> > >>>>>> ktime_t start = ktime_get(); > >>>>>> > >>>>>> and > >>>>>> > >>>>>> if (actual_count > 0) { > >>>>>> u64 runtime = > >>>>>> ktime_to_ns(ktime_sub(ktime_get(), start)); u64 avg; > >>>>>> > >>>>>> /* > >>>>>> * We weigh the current average higher than > >>>>>> our current runtime > >>>>>> * to avoid large swings in the average. > >>>>>> */ > >>>>>> spin_lock(&delayed_refs->lock); > >>>>>> avg = fs_info->avg_delayed_ref_runtime * 3 > >>>>>> + runtime; avg = div64_u64(avg, 4); > >>>>>> fs_info->avg_delayed_ref_runtime = avg; > >>>>>> spin_unlock(&delayed_refs->lock); > >>>>>> } > >>>>>> > >>>>>> in __btrfs_run_delayed_refs and see if that makes the problem > >>>>>> stop? If it does will you try chris's for-linus branch to see > >>>>>> if it still reproduces there? Maybe some patch changed > >>>>>> ktime_get() in -rc1 that is causing issues and we're just now > >>>>>> exposing it. Thanks, > >>>>> With the ktime bits disabled, I wasn't able to reproduce the > >>>>> problem anymore. With Chris' for-linus branch it took longer but > >>>>> still appeared. > >>>>> > >>>> Ok can you send your .config, maybe there's some weird time bug > >>>> being exposed. What kind of CPU do you have? Thanks, > >>>> > >>>> Josef > >>> It's a Core i5-540M, dualcore + hyperthreading > >> Ok while I'm doing this can you change > >> btrfs_should_throttle_delayed_refs to _always_ return 1, still with > >> all the ktime stuff commented out, and see if that causes the > >> problem to happen? Thanks, > > Yes it does. Same behavior as without ktime stuff commented out. > > > Ok perfect, can you send me a btrfs fi df of that volume, and do you > have any snapshots or anything? Thanks,
btrfs fi df / Data, single: total=220.01GiB, used=210.85GiB System, DUP: total=8.00MiB, used=32.00KiB System, single: total=4.00MiB, used=0.00 Metadata, DUP: total=4.00GiB, used=2.93GiB Metadata, single: total=8.00MiB, used=0.00 No snapshots but several subvolumes. / itself is a seperate subvolume and subvol 0 only contains the other subvolumes (5 at moment). qgroups aren't enabled. mount options are noatime,inode_cache, if this matters regards, Johannes -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
