Thank you for this. I had been having problems with re-purposed 2.5" SATA, non-SSD drives which I have put in USB 3.0 enclosures. I tried using the USB 3 ports on laptop versus my USB 3 hub and that made no difference. Swap settings didn’t help either. Interestingly, I did not have this issue with the commercial type drives (WD My Passport, Toshiba, etc.). On the drives in the enclosure(s) it would choke with the message “Queued” which when I changed a Thunar setting "Transfer files in parallel, it seemed better, but would take a very long time to eject/safely remove the drive. I also tried different formatting(ext4, xfs, etc.) which made no difference.
I just implemented your solution(manually), rebooted and the process was smooth, no issues. I copied over a 15GB .vdi, unmounted/removed and remounted. All is good. This is a preliminary impression, but I feel confidant with this going forward. Thanks again.
My original topic doesn’t deal with dirty pages or anything else - there is a reference to a topic but that is merely reminder that we have seen these topics from time to time and they always end with various tuning suggestions which always is a matter of system and use case.
What I suggest is a simple disable write-cache for the added device if it is an usb disk.
Your suggestion is not bad but I still don’t see why your suggestion is
Your repo was created March 11. - this topic is from March 4. - are you trying to promote something?
I am not critizing your suggestion, I merely curious as to why you think your solution is superior?
Does it mean that the idea presented in the OT or the idea presented by @megavolt is less real?
It is just another way of reaching the goal of having the data written and when no more data - we are done and the device can be ejected.
I don’t know how you interpret the term real solution, English is not my native language, but the difference I looked for when making the solution I presented was to find a method that could be installed in the distribution by default and solve the problem in a way that is useful for almost all users.
The solutions presented before generate effects that, in my point of view, prevent them from being applied in the system.
Your idea and implementation of the idea is great.
The earlier discussions has always ended with some system tweaking which always addressed the system as a whole and thus not targeting removable USB media.
In that regard you are correct - all the previous topics did not address directly USB devices - as it should have.
This is also why I created this topic - a simple method to address the single specific usb attached storage device.
My idea - which was not mine at all - I just expanded on it to only target USB devices and using hdparm to disable write-cache.
Your idea is change the dirty_pages to a size minimal enough to flush quickly - also for the given USB device.
Both works - which one you decide to use - I don’t care - I had my greatest time figuring it out - passing on the knowledge is the least of it.
Perhaps I can enhance your understanding of a solution and a real solution.
A solution could be a work-around - a monkey patch - a bandaid - name it what you like - what matters is that the solution work - but it doesn’t really handle the root cause.
Compared to the above example the real solution is the one which handles the root cause.
We cannot change how the kernel works - but we can apply some rules as how different situations should be handled.
When you look at it that way - there may be multiple options available to achieve the end goal - to be able to remove the USB device immediately when the copy process ends - not waiting - perhaps several mintes before the stick can be removed.
To that end you idea and the idea I grabbed and worked with is equically good.