Il giorno mar, 04/06/2019 alle 07.43 +0200, Greg KH ha scritto: > On Mon, Jun 03, 2019 at 01:13:48PM +0200, Andrea Vai wrote: > > Il giorno gio, 30/05/2019 alle 06.25 -0700, Greg KH ha scritto: > > > [...] > > Hi, > > > > > Any chance you can use 'git bisect' to find the offending > commit? > > Yes, I am doing it as I managed to build the kernel from source > > Great! What did you find? so far, something in between 2ac5e38ea4203852d6e99edd3cf11f044b0a409f (good) and b3cc2bfe7244e848f5e8caa77bbdc72c04abd17c (bad)... (about 8 steps left) > > > > And did you accidentally turn on "sync" for the filesystem? > > Sorry, I don't think so but actually I don't know exactly what it > is > > nor how to check it... > > > > > How do you > > > know the old kernel really flushed the buffers out in 1 minute? > > > > I used to try to unmount the usb media (e.g. "eject" using > Nautilus > > file manager), and got a message stating the filesystem was in use > and > > could not be mounted, so always answered to not eject it until it > was > > unmounted without any warning... does it make sense? > > That does not mean that the data is not flushed to the device yet, > that > just means that some userspace program is still accessing the > device. > You need to run some other type of test to validate how long it taks > for > the data to get to the device. I understand, I actually omitted here what I found out by using "top", "ps" and "iotop" to catch the moment when the data write finish. I found a process named "kworker/u8:0+flush-8:16", or similar, which is alive while the cp process is in D state (and as long as I can't "eject" the device), and disappears when the media can be ejected, so I assumed it to be a good indicator for the data write. But I admit I am really poorly skilled on this matter, so thanks for pointing it out, and for any other explanation (or links to deepen it furthermore). > > > > But 12 > > > minutes is really long, did anything else change in your > userspace > > > between the kernel changes as well? > > I am not sure if I understand correctly the "userspace" you > mention: > > if you mean my home directory and contents, settings etc, then > yes, > > maybe... but while I am doing the tests I am quite sure I didn't > > change anything, and double-checked many times that the 4.20 > kernel is > > always working (I usually boot up with it when I need to do the > usual > > day work). > > I mean, did any other programs on your machine change between the > upgrade of your kernel? Maybe some gnome-tracker is going off and > indexing all of the data on that device after you mount it, and it > wasn't previously doing that before. As it is still busy, something > has > some open files on that device. Thank you, now I understand what you mean. Yes, this is definitively possible (may a "lsof | grep mount_point_of_the_device" or similar could give some clue?) Thanks, and bye, Andrea
