On Tue, Feb 7, 2023 at 12:07 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Feb 07, 2023 at 10:02:51AM +0800, Zhongjie Zhu wrote: > > On Mon, Feb 6, 2023 at 11:17 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Mon, Feb 06, 2023 at 11:33:15AM +0800, 朱忠杰 wrote: > > > > Yes, this is a very special case. > > > > > > > > It will happen only when disconnecting the mass storage if there are > > > > too many files in the storage, and the scanning operation is running, > > > > and the file system is not unmounted. > > > > It looks like this issue should be fixed in the usb mass storage > > > > driver, but I don't find an appropriate place. > > > > > > That's not surprising, because usb-storage doesn't know anything about > > > what's happening on the mass-storage device it connects to. All it does > > > is send the commands that it gets from the SCSI subsystem to the device > > > and receive the results back. It has no idea whether there is a mounted > > > filesystem on the device, if the filesystem contains any files, or > > > whether a scanning operation is running, > > > > > > A better place to look for fixing this might be the filesystem code. > > > That's where the information about mounting, files, and scanning can be > > > found. > > > > > > Alan Stern > > > > The problem is there is a for loop in the invalidate_inodes(), this > > function is in the block device driver. when the usb_disconnect is > > called, the filesystem is not umounted, userspace applications will be > > noticed the usb storage is disconnected, and then do the umounting > > work. > > the invalidate_inodes() is called in the usb hub worker, and will run > > for a long time. To fix this issue, the long running loop need to be > > moved out from the usb hub worker. > > Oh, maybe I didn't understand. > > You've got a USB mass-storage device with a mounted filesystem and a lot > of dirty inodes, right? Then a USB disconnect happens, and as part of > the disconnect processing, invalidate_inodes() runs for a long time. > > Do you know why it takes so long? The I/O operations shouldn't need any > time; they will all fail immediately because the device has been > disconnected and so there is no way to communicate with it. > > Alan Stern Yes, invalidate_inodes() will free all the inodes related to the supper_block, there are more than 20 thousands inodes (some times more) need to be freed, the perf record shows the cpu is busy running the spin_lock and spin_unlock in the invalidate_inodes(). The work in this function is to free all the inodes with the super_block. Maybe I need to find out why the spin_lock is running so much first.
