My syncing disks problem

[Jean-Marc Zucconi]

>>>>> Matthew Dillon writes:

 >     Ok, I've looked at the crash dump.  The stuck buffer is marked as 
 >     having an I/O in progress, but there is some weirdness that doesn't
 >     make sense such as b_resid being 0.  The buffer also has two softupdates
 >     dependancies, both inode dependancies, which are causing the buffer to
 >     remain marked dirty.  There should not be any inode dependancies, not
 >     after 20 loops and syncs!

 >     None of it makes much sense to me, because as far as I know the disk
 >     subsystem is still intact.  If I assume that the in-progress I/O is
 >     simply in-progress because that was what it was doing when Jean-Marc
 >     ctl-alt-esc'd we are left with the softupdates inode dependancies that
 >     should not be there.

In fact I didn't type ctl-alt-esc (and as it's a serial console it
should have been cr ~ ^B), the system switched itself in ddb mode.

 >     The only thing I can think of that would cause these dependancies to
 >     remain intact through 20 attempts to write them out is if the shutdown
 >     code is not syncing the disks the same way that the syncer syncs them
 >     (the syncer thread is already shutdown by this time so it is no longer
 >     syncing the filesystems).

 >     The only difference between the syncer thread and the sync() calls 
 >     the shutdown code makes is that the sync() calls the shutdown code makes
 >     are asynchronous.  And, in fact, there is a softupdates related 
 >     call that is not made for asynchronous filesystem syncs.

 >     So, here is a patch to try.  I only give it a 30% chance of working
 >     due to the huge number of guesses I have made above.

It didn't work. Do you want the new crash dump?

Jean-Marc

-- 
Jean-Marc Zucconi -- PGP Key: finger jmz at xxxxxxxxxxx [KeyID: 400B38E9]