John, Rebooting showed that it wasn't a hardware problem. It could be a kernel bug, or other software problem. Next time it occurs,... things that might help... I suspect the need is to find what app still has an open file on that filesystem. Id use lsof, to weed the noise try the following -- run as root -- of course,, lsof |grep sr0 and grep for a path beginning with the mount point. the grep should reduce most of the noise.
THe previous suggestion of using 'umount -l' or 'umount -f' might solve the issue, theoretically the -l essentially goes into the kernel and force all the open files on that mounted system to be closed. It's use has always been iffy for me. I think this is such a seldom used edge case, that it just isn't well tested. And of course, since there are so many different ways to eject the drive, try to remember which way was used right before something funny started happening. That tool might have a software bug in the version you have. I think lsof, with some greps is the best way to find what's happening. Killing the culpret removes the issue, but if whatever you killed has bad error recovery, it may decide that device is bad, and just refuse to use it anymore - that is until a system reboot cleans up everything. steve John Jason Jordan wrote: > On Thu, 31 Dec 2015 15:58:05 -0800 > Ken Stephens <k...@cad2cam.com> dijo: > >> Did you notice the "busy inodes problem"? Wonder if you ran out of >> inodes? You might want to check out this webpage >> (http://blog.scoutapp.com/articles/2014/10/08/understanding-disk-inodes) >> for an explanation of inodes and how to you might overcome the >> difficulties they might cause. > I never had this problem with any Linux ever. In this case it occurred > right after I umounted a mount point that was not removed after > ejecting a DVD. When I tried to umount it I kept getting the "busy" > error message, even though it was obviously not busy (DVD ejected). So > I used 'umount -l' to get rid of it. Right after that is when I got the: > > [410083.768178] VFS: busy inodes on changed media or resized disk sr0 > > Considering that the drive (/dev/sr0) is not a hard disk I am pretty > convinced that the problem is not lack of inodes. The main drive is a > 512GB SSD with ext4. > > I am still searching for a way to fix this without rebooting. So far > Google hasn't turned up any solutions. For that matter, there's no > guarantee that rebooting will resolve the problem either. > _______________________________________________ > PLUG mailing list > PLUG@lists.pdxlinux.org > http://lists.pdxlinux.org/mailman/listinfo/plug > _______________________________________________ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug