ext3 file system I/O blocks until reboot

Robert Davidson rdavidson at obsidian.com.au
Mon Oct 27 01:10:12 UTC 2008


Christian Kujau wrote:
> Probably too late anyway, but:
>
> On Mon, 20 Oct 2008, Robert Davidson wrote:
>> The "kjournald" process also got stuck in the "D" state.
>
> Did you try a SysReq-w to show all blocked tasks? OR even -d, or -t.
> You mentioned /var/log was on a different filesystem, so this
> information might make it to the disks. If not, your serial console
> should catch it. Maybe then we'll find out *why* these process are in
> "D" state.

Hi Christian,

Not too late - this is an ongoing problem still.  I'm currently trying
to see if I can get some newer vserver patches so I can build a newer
kernel and try that.  Currently I'm stuck with 2.6.22.19

I've tried doing various SysRq requests, none of them would give me
anything back on the serial console, but it seems that may have been my
own fault for having the console logging set too low.  I've fixed that
up now.

In any case, the responses you'd expect to see from the kernel for the
various SysRq commands never made it into the logs.

About a month ago when the server last had problems, I made a new ext3
filesystem and copied everything from the old filesystem to the new
one.  I thought that worked but then last night we lost the same
filesystem again and had to reboot.

After copying everything off the original filesystem (also ext3) I ran a
forced fsck.ext3 on it and it didn't find any problems.

-- 
Regards,
Robert Davidson.
Obsidian Consulting Group.
Ph. 03-9355-7844
E-Mail: support at obsidian.com.au





More information about the Ext3-users mailing list