On Mon, Dec 23, 2019 at 07:45:57PM +0100, Andrea Vai wrote: > basically, it's: > > mount UUID=$uuid /mnt/pendrive > SECONDS=0 > cp $testfile /mnt/pendrive > umount /mnt/pendrive > tempo=$SECONDS > > and it copies one file only. Anyway, you can find the whole script > attached. OK, so whether we are doing the writeback at the end of cp, or when you do the umount, it's probably not going to make any difference. We can get rid of the stack trace in question by changing the script to be basically: mount UUID=$uuid /mnt/pendrive SECONDS=0 rm -f /mnt/pendrive/$testfile cp $testfile /mnt/pendrive umount /mnt/pendrive tempo=$SECONDS I predict if you do that, you'll see that all of the time is spent in the umount, when we are trying to write back the file. I really don't think then this is a file system problem at all. It's just that USB I/O is slow, for whatever reason. We'll see a stack trace in the writeback code waiting for the I/O to be completed, but that doesn't mean that the root cause is in the writeback code or in the file system which is triggering the writeback. I suspect the next step is use a blktrace, to see what kind of I/O is being sent to the USB drive, and how long it takes for the I/O to complete. You might also try to capture the output of "iostat -x 1" while the script is running, and see what the difference might be between a kernel version that has the problem and one that doesn't, and see if that gives us a clue. > > And then send me > btw, please tell me if "me" means only you or I cc: all the > recipients, as usual Well, I don't think we know what the root cause is. Ming is focusing on that stack trace, but I think it's a red herring..... And if it's not a file system problem, then other people will be best suited to debug the issue. - Ted
