From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [2.6.32 ubuntu] I/O hang at start_this_handle Date: Tue, 12 Apr 2011 21:50:51 +0200 Message-ID: <20110412195051.GG5246@quack.suse.cz> References: <20110216155317.GD5592@quack.suse.cz> <201102170813.p1H8DhOJ083597@www262.sakura.ne.jp> <20110217153847.GE4947@quack.suse.cz> <201104082338.GCG69297.FQVLtSJOFHOMOF@I-love.SAKURA.ne.jp> <20110408182916.GA16729@quack.suse.cz> <201104091121.BFC34844.OHLtMOJVFFOSQF@I-love.SAKURA.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: jack@suse.cz, linux-fsdevel@vger.kernel.org To: Tetsuo Handa Return-path: Received: from cantor2.suse.de ([195.135.220.15]:59121 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756733Ab1DLTux (ORCPT ); Tue, 12 Apr 2011 15:50:53 -0400 Content-Disposition: inline In-Reply-To: <201104091121.BFC34844.OHLtMOJVFFOSQF@I-love.SAKURA.ne.jp> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sat 09-04-11 11:21:40, Tetsuo Handa wrote: > Jan Kara wrote: > > Hmm, but 2.6.18 is really ancient. I'm afraid I cannot help you much with > > it. There have been numerous bugs fixed since then. > > It is RHEL5.6 kernel which the known bugs have been fixed. I guess that RHEL6.0 Yes, but RHEL (as well as SLES) kernels are generally fixed on as needed basis - i.e., when a customer reports an error, support debugs it and adds the fix to the kernel. So you could well be the first one to spot the issue with RHEL 5.6 kernel... > kernel also has this bug (since this bug is in Ubuntu 10.04 kernels). Yes, Ubuntu 10.04 is more relevant. 2.6.32 is not that old and I don't remember any fixes in that area. > So, I want to try establishing the steps to reproduce. > > Does anybody come up with common characteristics between below hangups? > > (a) Updating rpm packages using rpm executed from zypper. > > Although, the process actually hanged is /bin/sh which > I guess was invoked for pre- or post- install scripts. > > Installing: grub-0.97-173.6 [91%] > > (b) Logging in from console using /bin/login . > > Although, the process actually hanged seems to be auditd process > which attempted to write an audit log immediately after login event. > > (c) PostgreSQL and Apache. > > http://www.mail-archive.com/pgsql-bugs@postgresql.org/msg24852.html > > Writing with O_SYNC? Or calling fsync()? Or calling ftruncate()? Or ...? I wouldn't expect any of this. If your original Ubuntu 10.04 report is right, we block on j_barrier_count which is changed only in journal_lock/unlock_updates() which gets called only from a few places. The problem is that the hung process need not be directly related to the hang. It can be just a victim of a race with some other process manipulating j_barrier_count. But I don't see any such race in the code. So I'd need a way to reproduce this so that we can perform some debugging. Honza -- Jan Kara SUSE Labs, CR