Hello,
Just updated my F26 and went to copy some files to a stick for transfer. If I try to copy a file either with drag and drop or using Konsole and cp, the system will not copy the full file and will just freeze. I tried different sticks on the system with no luck.
I have tested with the same results on two different computers with different sticks.
It looks like I can copy small files but large files won't work. Even if I try copy files using sudo, it still does the same thing, using 3 or 4 processors to 100% and the copy process hangs.
I can mount the stick manually using sudo and copy files with no issue.
Mount differences are:
This is what mount shows when I use the KDE desktop /dev/sdc1 on /run/media/user/MyStick type vfat (rw,nosuid,nodev,relatime,uid=1100,gid=1100,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
Mounting by sudo /dev/sdc1 on /mnt/temp type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
ps shows that the process is waiting for the drive with a D+ in the status. It will do this for an hour if I leave it.
I don't know where to start looking to report a bug to provide more details for the bug report.
Robin
On 11/18/17 09:16, Robin Laing wrote:
Just updated my F26 and went to copy some files to a stick for transfer. If I try to copy a file either with drag and drop or using Konsole and cp, the system will not copy the full file and will just freeze. I tried different sticks on the system with no luck.
I have tested with the same results on two different computers with different sticks.
It looks like I can copy small files but large files won't work. Even if I try copy files using sudo, it still does the same thing, using 3 or 4 processors to 100% and the copy process hangs.
I can mount the stick manually using sudo and copy files with no issue.
Mount differences are:
This is what mount shows when I use the KDE desktop /dev/sdc1 on /run/media/user/MyStick type vfat (rw,nosuid,nodev,relatime,uid=1100,gid=1100,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
Mounting by sudo /dev/sdc1 on /mnt/temp type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
ps shows that the process is waiting for the drive with a D+ in the status. It will do this for an hour if I leave it.
I don't know where to start looking to report a bug to provide more details for the bug report.
First, can you define "large"? I just transferred a 1GB file to mine without trouble.
When I plug in a USB drive and select "Open with File Manager" mount shows...
/dev/sdg1 on /run/media/egreshko/0E3723CF5E376877 type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
I think the differences may be due to my formatting the drive partition as ntfs. Is there a chance you could use that instead of vfat?
On 17/11/17 18:50, Ed Greshko wrote:
On 11/18/17 09:16, Robin Laing wrote:
Just updated my F26 and went to copy some files to a stick for transfer. If I try to copy a file either with drag and drop or using Konsole and cp, the system will not copy the full file and will just freeze. I tried different sticks on the system with no luck.
I have tested with the same results on two different computers with different sticks.
It looks like I can copy small files but large files won't work. Even if I try copy files using sudo, it still does the same thing, using 3 or 4 processors to 100% and the copy process hangs.
I can mount the stick manually using sudo and copy files with no issue.
Mount differences are:
This is what mount shows when I use the KDE desktop /dev/sdc1 on /run/media/user/MyStick type vfat (rw,nosuid,nodev,relatime,uid=1100,gid=1100,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
Mounting by sudo /dev/sdc1 on /mnt/temp type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
ps shows that the process is waiting for the drive with a D+ in the status. It will do this for an hour if I leave it.
I don't know where to start looking to report a bug to provide more details for the bug report.
First, can you define "large"? I just transferred a 1GB file to mine without trouble.
When I plug in a USB drive and select "Open with File Manager" mount shows...
/dev/sdg1 on /run/media/egreshko/0E3723CF5E376877 type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
I think the differences may be due to my formatting the drive partition as ntfs. Is there a chance you could use that instead of vfat?
NTFS is not an option. I don't know how many sticks you purchase that are already formatted with NTFS and work on old and new windows. How many cameras do you know that work with NTFS cards. I have to test some cards later when time permits.
I am talking 400MB and above with my few tests. Same sticks when manually mounted work okay.
I wonder why the system shows that it is waiting for the drive which points me to a communication issue between the USB sub system and KDE.
I still want to know what sub-systems I need to watch to find out how to report this. I have a bunch of work to do and if this is a continuing issue, it will cost me in lost productivity.
Funny thing happened when I tried to transfer a file with File Manager. ls -l showed the whole file transferred in less than 1 sec, even though it was a 700MB file. Even the status graph was full before I could open the widget. Then the hang. Full file was never transferred.
To me this is a critical bug.
On 11/18/17 13:41, Robin Laing wrote:
On 17/11/17 18:50, Ed Greshko wrote:
On 11/18/17 09:16, Robin Laing wrote:
Just updated my F26 and went to copy some files to a stick for transfer. If I try to copy a file either with drag and drop or using Konsole and cp, the system will not copy the full file and will just freeze. I tried different sticks on the system with no luck.
I have tested with the same results on two different computers with different sticks.
It looks like I can copy small files but large files won't work. Even if I try copy files using sudo, it still does the same thing, using 3 or 4 processors to 100% and the copy process hangs.
I can mount the stick manually using sudo and copy files with no issue.
Mount differences are:
This is what mount shows when I use the KDE desktop /dev/sdc1 on /run/media/user/MyStick type vfat (rw,nosuid,nodev,relatime,uid=1100,gid=1100,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
Mounting by sudo /dev/sdc1 on /mnt/temp type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
ps shows that the process is waiting for the drive with a D+ in the status. It will do this for an hour if I leave it.
I don't know where to start looking to report a bug to provide more details for the bug report.
First, can you define "large"? I just transferred a 1GB file to mine without trouble.
When I plug in a USB drive and select "Open with File Manager" mount shows...
/dev/sdg1 on /run/media/egreshko/0E3723CF5E376877 type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
I think the differences may be due to my formatting the drive partition as ntfs. Is there a chance you could use that instead of vfat?
NTFS is not an option. I don't know how many sticks you purchase that are already formatted with NTFS and work on old and new windows. How many cameras do you know that work with NTFS cards. I have to test some cards later when time permits.
Ahh, OK. I suppose it would have been sufficient to just say you can't use NTFS for your case.
I am talking 400MB and above with my few tests. Same sticks when manually mounted work okay.
OK. I found an old, cheap, USB stick that had nothing of value on it and it is already formatted as vfat. Inserting it gives me
/dev/sdg1 on /run/media/egreshko/EB65-B61D type vfat (rw,nosuid,nodev,relatime,uid=1029,gid=65539,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
I copied, via D&D in Dolphin, a 702MB mp4 file without difficulty. Forgot to check my watch to see how long it took so I ran it again with time and this was the result. The source file is on an NFS mounted partition so that may have affected the speed. As I said, it is an old stick of unknown manufacture and doesn't have any speed markings on it.
real 5m24.971s user 0m0.003s sys 0m1.713s
I wonder why the system shows that it is waiting for the drive which points me to a communication issue between the USB sub system and KDE.
Sorry, I don't know. But if the transfer also fails to complete using "cp" from the command line it sounds not related to KDE but more kernelish.
I still want to know what sub-systems I need to watch to find out how to report this. I have a bunch of work to do and if this is a continuing issue, it will cost me in lost productivity.
Funny thing happened when I tried to transfer a file with File Manager. ls -l showed the whole file transferred in less than 1 sec, even though it was a 700MB file. Even the status graph was full before I could open the widget. Then the hang. Full file was never transferred.
To me this is a critical bug.
I'm sure it is. Unfortunately I've been unable to duplicate and am therefore of little help.
On 17/11/17 23:33, Ed Greshko wrote:
On 11/18/17 13:41, Robin Laing wrote:
On 17/11/17 18:50, Ed Greshko wrote:
On 11/18/17 09:16, Robin Laing wrote:
Just updated my F26 and went to copy some files to a stick for transfer. If I try to copy a file either with drag and drop or using Konsole and cp, the system will not copy the full file and will just freeze. I tried different sticks on the system with no luck.
I have tested with the same results on two different computers with different sticks.
It looks like I can copy small files but large files won't work. Even if I try copy files using sudo, it still does the same thing, using 3 or 4 processors to 100% and the copy process hangs.
I can mount the stick manually using sudo and copy files with no issue.
Mount differences are:
This is what mount shows when I use the KDE desktop /dev/sdc1 on /run/media/user/MyStick type vfat (rw,nosuid,nodev,relatime,uid=1100,gid=1100,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
Mounting by sudo /dev/sdc1 on /mnt/temp type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
ps shows that the process is waiting for the drive with a D+ in the status. It will do this for an hour if I leave it.
I don't know where to start looking to report a bug to provide more details for the bug report.
First, can you define "large"? I just transferred a 1GB file to mine without trouble.
When I plug in a USB drive and select "Open with File Manager" mount shows...
/dev/sdg1 on /run/media/egreshko/0E3723CF5E376877 type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
I think the differences may be due to my formatting the drive partition as ntfs. Is there a chance you could use that instead of vfat?
NTFS is not an option. I don't know how many sticks you purchase that are already formatted with NTFS and work on old and new windows. How many cameras do you know that work with NTFS cards. I have to test some cards later when time permits.
Ahh, OK. I suppose it would have been sufficient to just say you can't use NTFS for your case.
I am talking 400MB and above with my few tests. Same sticks when manually mounted work okay.
OK. I found an old, cheap, USB stick that had nothing of value on it and it is already formatted as vfat. Inserting it gives me
/dev/sdg1 on /run/media/egreshko/EB65-B61D type vfat (rw,nosuid,nodev,relatime,uid=1029,gid=65539,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
I copied, via D&D in Dolphin, a 702MB mp4 file without difficulty. Forgot to check my watch to see how long it took so I ran it again with time and this was the result. The source file is on an NFS mounted partition so that may have affected the speed. As I said, it is an old stick of unknown manufacture and doesn't have any speed markings on it.
real 5m24.971s user 0m0.003s sys 0m1.713s
I wonder why the system shows that it is waiting for the drive which points me to a communication issue between the USB sub system and KDE.
Sorry, I don't know. But if the transfer also fails to complete using "cp" from the command line it sounds not related to KDE but more kernelish.
I still want to know what sub-systems I need to watch to find out how to report this. I have a bunch of work to do and if this is a continuing issue, it will cost me in lost productivity.
Funny thing happened when I tried to transfer a file with File Manager. ls -l showed the whole file transferred in less than 1 sec, even though it was a 700MB file. Even the status graph was full before I could open the widget. Then the hang. Full file was never transferred.
To me this is a critical bug.
I'm sure it is. Unfortunately I've been unable to duplicate and am therefore of little help.
Thanks for trying.
I tried this on two machines yesterday. Three different sticks. All the same results.
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.
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.
If I get time today, I want to try some things on a machine that has not been updated (it is not used much) to see if there is a difference in the mount options or something else.
I will also try strace on the cp command.
Robin
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).
On Sat, 2017-11-18 at 10:47 -0700, Robin Laing wrote:
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.
The panel indicator merely shows that the user-level process has finished pushing the bits out to the system. I doesn't know anything about how long the system will take to flush the buffers onto the physical medium (in fact you can see the same effect when copying to an NFS-mounted drive). If it's genuinely stuck that's another issue, but even in the best case you can't reply on the app-level indication to tell you the copy has finished. That's basically why there's an Eject button.
poc
On 18/11/17 02:16, Robin Laing wrote:
I can mount the stick manually using sudo and copy files with no issue.
Mount differences are:
This is what mount shows when I use the KDE desktop /dev/sdc1 on /run/media/user/MyStick type vfat (rw,nosuid,nodev,relatime,uid=1100,gid=1100,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
Mounting by sudo /dev/sdc1 on /mnt/temp type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
Did you try to reproduce the mount options while mounting manually? I don't know what uhelper does (and it likely will not work adding that manually), but you should be able to add the rest. Especially "flush" sounds like this might be the important option.
On 18/11/17 02:13, Lukas Middendorf wrote:
On 18/11/17 02:16, Robin Laing wrote:
I can mount the stick manually using sudo and copy files with no issue.
Mount differences are:
This is what mount shows when I use the KDE desktop /dev/sdc1 on /run/media/user/MyStick type vfat (rw,nosuid,nodev,relatime,uid=1100,gid=1100,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
Mounting by sudo /dev/sdc1 on /mnt/temp type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
Did you try to reproduce the mount options while mounting manually? I don't know what uhelper does (and it likely will not work adding that manually), but you should be able to add the rest. Especially "flush" sounds like this might be the important option. _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org
No, I will try it. Good suggestion. Hopefully find some time today.
Robin
-
Ed Greshko -
Lukas Middendorf -
Patrick O'Callaghan -
Robin Laing