On 18/11/17 18:47, Robin Laing wrote:
If I mount with the KDE system, then I have issues. If I mount
manually
I don't which is the confusing part and why I don't think it is related
to the kernel but interface between the two.
It's likely either caused by
udisks (which KDE seems to use to mount
removable drives) or the other file system mount options (kernel problem
then).
I don't know if udisks does anything while the file system is mounted.
Mounting (as your normal user) with "udisksctl mount -b /dev/sdxxx"
(where /dev/sdxxx has to be replaced by the partition block device (see
"dmesg" after plugging in the device)) should likely give the same
behavior. You can unmount again with "udisksctl unmount -b /dev/sdxxx".
If manually mounting with the mount same mount options as udisks does
(except for the "uhelper=udisks2") causes the same problem, you should
report that against the kernel. If it does not, I would report that
against udisks.
That is why I tried to use the copy paste feature of the File Manager
as
a test. Instant indication that the file had transferred. As soon as
I could start the copy and paste, I did an ls -l on the stick and
according to that, the full file had been transferred but things were
stuck.
That indicator on the panel when I looked showed 100% as well. I wanted
to see what the indicator showed.
You are seeing the write cache in action. With today's large amount of
RAM, write cache is usually multiple 100s of MiB. So when you copy a
file, you are first only seeing the read speed of the source medium
until the write cache is full and then it slows down to the speed with
which the actual write is performed. If the copied file is small enough
to fit into the write cache and it is already in the read cache of the
source medium (or the source medium is extremely fast) the copy seems to
be instantaneous. But the actual write is slower and you have to wait
for the write cache to be cleared until you can unmount the partition
(depending on the drive you will see a blinking LED during that time).