Messages in this thread | | | Date | Fri, 4 Apr 2008 12:02:42 -0300 | From | Marcelo Tosatti <> | Subject | Re: BUG: ext3 hang in transaction commit |
| |
On Fri, Apr 04, 2008 at 12:34:50PM +0200, Jan Kara wrote:
> > Max throughput per process = 66393.62 KB/sec > > Avg throughput per process = 26518.38 KB/sec > > Min xfer = 44424.00 KB > > > > And this is when fsync becomes nasty. > Could you get for me movies from Seekwatcher (taken on the host) - > http://oss.oracle.com/~mason/seekwatcher/ > That should confirm my suspicion. Actually, if writing data in the bad > order is really the problem than my rewrite of ordered mode in JBD can > substantially help this workload (I can send you the patches if you dare > to try something really experimental ;).
OK, will record the animation.
Will be pleased to try your patches. Where can they be found?
> > blktrace output shows that the maximum latency for a single write > > request io complete is 1.5 seconds, which is similar to what is seen > > under "writeback" mode. > > > > I reduced hung_task_timeout_secs to 30 for this report, but vim and > > rsyslogd have been seen hung up to 120 seconds. > > > > <snip traces of processes waiting for commit> > > > As Peter mentioned it eventually gets out of this state (after several > > minutes) and fsync instances complete. > Yes, that is just a combined effect of *lots* of ordered data > accumulated in one transaction (we don't limit amount of ordered data in > a transaction in any way) and writing them out during transaction order > in a random order.
| |