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. > I also tried xfs_io with shutdown -f, but it had the same problem > because xfs_io couldn't access anything on the file system. Because the IO errors had already shut the filesystem down, as per the dmesg output you quoted below. > How is that supposed to work? Having to reboot just to recover > from IO errors doesn't seem to be very available. > > I don't think shutdown should prevent unmounting. It doesn't. Something was leaked or not cleaned up properly, preventing the filesytem from being unmounted. You know, a bug... > From googling I found some old RHEL bugzilla that such a problem > was fixed in some RHEL release. Is that a regression? RHEL has an upstream first policy, so whatever bug fix you find in a RHEL kernel is already in the upstream kernels. > This was on a 5.4.10 kernel. > > I got lots of: > > XFS (...): metadata I/O error in "xfs_trans_read_buf_map" at daddr > 0x4a620288 len 8 error 5 > > Then some > > XFS (...): writeback error on sector 7372099184 > > And finally: > > XFS (...): log I/O error -5 > XFS (...): xfs_do_force_shutdown(0x2) > called from line 1250 of file fs/xfs/xfs_log.c. Return address = > 00000000f7956130 > XFS (...): Log I/O Error Detected. > Shutting down filesystem > XFS (...): Please unmount the filesystem > and rectify the problem(s) > > (very funny XFS!) > > 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? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
