> Might this be related to shutdowns taking a long time to actually
> unmount fs...
> I noticed since I upped the kernel to an 2.4.10 release ( dont know the
> exact checkout)
> shutdowns hang on umount for a significant larger period... as in taking
> 2-3 minutes istd of 20-30 secs.
Hmm, thats a new one to me too, my shutdowns on all xfs boxes do not appear
to have become any longer - however, the systems are not busy before the
unmount usually. The new VM showed up later in the 2.4.10-pre series,
possibly this was the cause.
Can you characterize how much activity there is on the system before
shutdown - would there typically be a lot of dirty data in filesystems?
Also, you mention write activity - is this during shutdown?
Steve
>
> I also noticed a relationship with the write activity on that disk.
> Which did not occur with the 1.0.1 release...
>
>
> Eric Sandeen wrote:
> >
> > Krzysztof Rusocki wrote:
> > >
> > > Hello,
> > >
> > > I witnessed xfs_force_shutdown doing its best yesterday ;-)
> >
> > > After reboot f/s could NOT be remounted r/w - same things
> > > happened (xfs_force_shutdown).
> > >
> > > So i booted from CD and repaired f/s.
> >
> > We've been seeing a couple people with this lately... it's probably not
> > a memory problem, it may be an underlying XFS problem.
> >
> > xfs_repair may "fix" the problem, but it's throwing the baby out with
> > the bath water, as they say... You're running xfs_repair on a filesystem
> > with a dirty log, which is not so good.
> >
> > I have a patch that spits out some more information on the way to
> > _xfs_force_shutdown, if anyone is reliably hitting this error and would
> > be willing to try it again with the patch, please let me know.
> >
|