On Tue, Feb 05, 2013 at 01:22:42PM -0500, Tom wrote: > In a previous message, Dave Chinner wrote: > > > > Which doesn't tell us why the filesystem was not unmounted. We need to > > know why/how the unmount failed to solve the problem, so you'll need to > > do some debugging of the unmount to try to work that out... > > > > Thanks Dave. > > I can work on that tonight. > > Oddly, since the problem is kernel related (308 doesn't do it, 348 does), > the system shuts down the same way no matter what kernel I'm using. So > what would be the difference? The umounts and running processes shouldn't > change. Just seems to me that some resource isn't being released. And > only with kernel 348 and XFS. Quite puzzling.......... > > Any suggestions on how I would debug this? Find out if the unmount is returning an error first. If there is no error, then you need to find what is doing bind mounts on your system and make sure they are unmounted properly before the final unmount is done. If lazy unmount is being done, make it a normal unmount an see where the unmount is getting stcuk or taking time to complete by using sysrq-w if it gets delayed for any length of time. FWIW, because this is a old, old kernel, event tracing is not available, so the single most useful tool for tracking this down is not available... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
