Re: Shutdown preventing umount

[Dave Chinner <david@fromorbit.com>]

On Sun, Mar 15, 2020 at 08:37:19PM -0700, Andi Kleen wrote:
> On Mon, Mar 16, 2020 at 01:03:42PM +1100, Dave Chinner wrote:
> > On Sat, Mar 14, 2020 at 06:31:10AM -0700, Andi Kleen wrote:
> > > 
> > > Hi,
> > > 
> > > I had a cable problem on a USB connected XFS file system, triggering 
> > > some IO errors, and the result was that any access to the mount point
> > > resulted in EIO. This prevented unmounting the file system to recover
> > > from the problem. 
> > 
> > Full dmesg output, please.
> 
> http://www.firstfloor.org/~andi/dmesg-xfs-umount

So /dev/sdd went away, XFS shutdown eventually. There's no
indication that an XFS unmount has started, because the first thing
XFS does in it's ->put_super method is emit this to the log:

XFS (dm-4): Unmounting Filesystem

and that is missing. Hence the VFS unmount path has not reached as
far as XFS before it has errorred out. THis is confirmed by....

> > > 
> > > XFS (...): log I/O error -5
> > > 
> > > scsi 7:0:0:0: rejecting I/O to dead device
> > 
> > Where is unmount stuck? 'echo w > /proc/sysrq-trigger' output if it
> > is hung, 'echo l > /proc/sysrq-trigger' if it is spinning, please?
> 
> It's not stuck. It always errored out with EIO.

... the fact that filesystems cannot return errors from unmount
proceedings as generic_shutdown_super() is a void function.  Hence
where this EIO is coming from is not obvious - it isn't from XFS
failing to unmount the filesystem as it's not gettting that far into
the unmount path.

You're going to need to strace umount to find what syscall is
failing, then probably use tracepoints or some one kernel
introspection tool to work out where the EIO is coming from...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com