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@xxxxxxxxxxxxx
