> > > I did some calculations. Default journal size for a filesystem of your
> > > size is 128 MB which allows recording of around 128 GB of data. So your
> > > test probably didn't hit the point where the journal is recycled yet. An
> > > easy way to make sure journal gets recycled is to set its size to a lower
> > > value when creating the filesystem by
> > > mke2fs -J size=8
> >
> > I tried the "-J size=8" and get similar interesting results for
> > ext3/4, before/after this change:
> >
> > if (work->for_kupdate) {
> > oldest_jif = jiffies -
> > msecs_to_jiffies(dirty_expire_interval * 10);
> > - work->older_than_this = &oldest_jif;
> > - }
> > + } else if (work->for_background)
> > + oldest_jif = jiffies;
> >
> > So I only attach the graphs for one case:
> >
> > ext4-1dd-4k-8p-2941M-1000M:10-3.1.0-ioless-full-next-20111025+
> >
> > Two of the graphs are very interesting. balance_dirty_pages-pause.png
> > shows increasingly large negative pause times, which indicates large
> > delays inside some ext4's routines.
> Likely we are hanging waiting for transaction start. 8 MB journal puts
> rather big pressure on journal space so we end up waiting on kjournald a
> lot. But I'm not sure why wait times would increase on large scale - with
> ext4 it's harder to estimate used journal space because it uses extents so
> the amount of metadata written depends on fragmentation. If you could post
> ext3 graphs, maybe I could make some sense from it...
Oops it's me that messed it up again -- two chunks were lost during
when rebasing the patchset which leads to the misbehavior -- big sorry!
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
