[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[soredake]

https://bugs.kde.org/show_bug.cgi?id=342056

soredake  changed:

   What|Removed |Added

 CC|katyaberezy...@gmail.com|

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[postix]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #55 from postix  ---
Question for those who can reproduce the issue: Is the issue fixed or improved
by https://invent.kde.org/frameworks/kio/-/merge_requests/957 ?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[soredake]

https://bugs.kde.org/show_bug.cgi?id=342056

soredake  changed:

   What|Removed |Added

 CC||ndrzj1...@relay.firefox.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=342056

Nate Graham  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|REPORTED|CONFIRMED

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=342056

Nate Graham  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REPORTED

--- Comment #54 from Nate Graham  ---
Indeed, just because one person was experiencing faulty hardware, doesn't mean
the legitimate issue in KDE software is fixed for everyone. I will hide the
non-relevant comments.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #53 from ric...@nakts.net ---
Any chance to hide the comments that deal with faulty hardware?
They make the bugreport impossible to follow.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[empyreal]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #52 from empyreal  ---
Seagate is to blame for everything. This is shit SMR technology. This drive
needs brakes and smaller packs of data. It’s busy working for 10 min after huge
copy process. After brake works faster, then slows down. And if you turn it off
immediately, which on USB is common thing, it's internal program may go into
some sort of loop or what.
https://ubuntuforums.org/archive/index.php/t-2370055.html

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[empyreal]

https://bugs.kde.org/show_bug.cgi?id=342056

empyreal  changed:

   What|Removed |Added

 Status|REPORTED|RESOLVED
 Resolution|--- |FIXED

--- Comment #51 from empyreal  ---
It didn’t work out that easily, till I dd whole drive with zeros. Switching to
SATA makes things easier, but... Drive started glitching again after copy
canceling. dd with zeros took 11 hrs starting from 140 MB/s and finished with
95 MB/s. Then drive stopped slowing boot and restart. Formatted with AOMEI from
USB stick. Copying very rarely drops to 200 KB/s, but generally ok - 388 GB in
3:20 hrs. Copied more than 1,5 TB already and continue. And now I do not need
to Offline disk in Windows. It mounts rw on Kubuntu.

smartctl -l devstat shows few things but no time when they happened:
0x03  0x030  4               1  ---  Number of Mechanical Start Failures
0x03  0x038  4   0  ---  Number of Realloc. Candidate Logical
Sectors
0x04  0x008  4               1  ---  Number of Reported Uncorrectable Errors

Nick, your advice was to the point! Easiest thing to do - wiping with zeros and
then move forward. “Low level format” helped me in the past with few drives,
but in this case, as it was very long process and there were no bads or relocs,
I thought dd MBR will be enough. Maybe this drive was glitching long time but I
didn’t noticed on small data volumes and cancel operation triggered smth... My
bad...

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[empyreal]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #50 from empyreal  ---
Seagate is to blame for supplying bad controllers for it’s USB drives? How to
check that USB controller properly? I don’t want my 3.6 TB go into coma again.
The only thing I can do, connect old 2.5” Seagate 80 GB and try to mess with
it. Any decent utilities?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Nick]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #49 from Nick  ---
For what's it's worth I think you have a bad USB controller, I've comes across
plenty of poor quality USB controllers, not to mention an inadequate power
supply that's supposed to power the drive. In fact I have several USB
controllers that only work properly when I power the drive that's attached to
USB with a ATX power supply, a lot depends on the drive power ratings. If I was
you I'd throw that particular USB controller in the bin and buy a decent
quality USB controller with lots of good reviews. Good luck, now you are using
SATA, I'm sure everything will be fine ! I'm going to log off and stay quiet
now as I don't really think this problem is solely related to KIO copying.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[empyreal]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #48 from empyreal  ---
I read so many forums that I got bloodshot eyes.

I wrote how it all started. Slow copy and laggy copy canceling in Krusader on
perfectly working 3 years old USB drive. No glitch ever! I never ever
experienced such issues on Windows. No slow copying or laggy copy canceling in
Total Commander with USB drives.

That’s was the reason to try cp in Konsole. Canceled cp in Konsole and got
this...
Just finished copying with Krusader 335 GB via SATA – 2,5 hrs. I think, now
this drive works as it should. I have no inclination to mess with USB
controller again and continue to use it as SATA. If it fails, I’ll give notice.

I do not expect slow copy problem to be addressed anytime soon, actually I do
not expect anything, but maybe this info will help in some way, whatever.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[postix]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #47 from postix  ---
> I need to figure out whether it is hardware issue or not.

empyreal, would you maybe like to discuss this first in a forum until you have
ruled out that this is not a _disk_ issue on your side?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[empyreal]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #46 from empyreal  ---
USB Seagate Backup Plus Drive. I tried copy in Konsole, because I noticed slow
copy in Krusader. Copy canceling in Krusader was slow too. After I canceled cp
process in Konsole, I got Partition 1 does not start on physical sector
boundary. Fixed issue in GParted by reformatting. It also realigned
automatically. Somehow “HDD reset” on Windows and started working properly. I
thought that everything is ok and left it to copy whole night on Kubuntu. Speed
dropped and mess started again. It’s interesting whether it is hardware fault
or software fault leading to hardware fault. Slow copying to USB drive is
common problem on Linux and it should be addressed properly. It’s unacceptable
that server system has issues with data transfers.

GParted drive again in vain. Made things worse on Windows. Strange
manipulations on Windows and I noticed that drive became responsive again.
Checked it with SeaTools once again. Populated volumes info. Drive works fast
but copy sucks. Offline. Disconnected USB drive. Booted Kubuntu. Waited for USB
drive to cool down. Connected drive. Mounted. Tried copying. Works as expected!
Booted Windows. 1 MB/s. Booted Kubuntu again. Copy on 2-3 MB/s speed. Could not
Remove safely… Shutdown.

Removed drive from case. Never believe SeaTools... USB controller is OK.
Checked with other Seagate drive. Connected HDD to SATA port. GParted messaging
about errors. dd everything. Successfully formatted drive. Problems with
mounting in Kubuntu. I could create files on it as sudo su only. chown chmod
remount - no result, except now sudo su can’t create anything too. Windows
boots very slow with the drive. Connected hot, but copying sucks. Drive clicks
like it constantly is reading smth. It behaves like this after unsuccessful
mounting on Kubuntu, after copying/canceling on Kubuntu and reboot or PC hard
reset from Kubuntu. On Windows it stopped clicking after a while. Windows
detects hard drive as removable, despite it is SATA now. I need to Offline it
as USB to mount rw file system on Kubuntu.

Now I have ST4000LM024-2AN17V which can write with 1 MB/s speed at best on
Windows.
Kubuntu first copy starts fast, the slows down to zero. Second copy almost zero
speed. And what happens next!!!

//All drives are SATA. Faulty drive ST4000LM024-2AN17V. I test and copy to it.
//Just booted Kubuntu. No copying

sudo hdparm -Tt /dev/sdc

/dev/sdc:
 Timing cached reads:   23030 MB in  2.00 seconds = 11531.43 MB/sec
 Timing buffered disk reads:  48 MB in  3.04 seconds =  15.78 MB/sec

//Started copy process in Krusader. Starts fast and slows down.

/dev/sdc:
Timing cached reads:   24952 MB in  2.00 seconds = 12494.70 MB/sec
 Timing buffered disk reads: 268 MB in  3.06 seconds =  87.55 MB/sec

//Started copy process in Krusader. Worked as expected O_O 
//Started copy process in Krusader. Worked as expected O_O

sudo hdparm -Tt /dev/sdc

/dev/sdc:
 Timing cached reads:   22382 MB in  2.00 seconds = 11206.40 MB/sec
 Timing buffered disk reads: 176 MB in  3.01 seconds =  58.46 MB/sec

//Started copy process in Krusader. Worked as expected. 20 GB in 4 min. O_O

Now I have ST4000LM024-2AN17V copying properly on Kubuntu or not? Any ideas?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[empyreal]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #45 from empyreal  ---
I know that my approach is unprofessional but what to do?
There are plenty of tools in Windows to check SMART. It is ok.
Also there are no surface or file errors.
SeaTools gives me hint that smth is wrong with USB controller.
99% that when I remove HDD from case, it will work properly.
But I need USB drive and check copy on Windows.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Nick]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #44 from Nick  ---
You could also run smartmontools on the drive, you may have to plug it into a
SATA internal connector or ESATA if you have one. For smartmontools to be able
to access the drive as not all USB to SATA adapters support ATA pass through.
Again ShredoS will confirm whether the controller supports ATA pass through.
Smartmontools will tell you all about the general health of the drive. I don't
know this but I'm assuming windows can also do this but as I don't use Windows
I don't know that for sure.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Nick]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #43 from Nick  ---
(In reply to empyreal from comment #42)
> I need to figure out whether it is hardware issue or not.
> It’s some sort of interface buffer problem, because changing settings in
> Windows helped for short period of time.
> 
> Windows. Mount slow. Copy slow.
> Offline and disconnected drive. Waited few min.
> Connected drive and Online. Mount slow. Copying slow.
> Device Manager => Volumes => Populate. Data received but no help. Mount
> slow. Copy slow. Very long Shutdown.
> 
> Windows. Waited few min. Connected USB drive. Mount slow. Copy slow.
> Noticed that folders, copied on Kubuntu open with lag. Formatted USB drive
> just in case. Switched buffer settings in Windows. Sometimes it helped USB
> drive to copy faster, but for short period of time. Speed was unstable.
> 
> Made few Short DST of SAS-SCSI-FC until device passed in SeaTools.
> Rescanned. USB 1394 showed up. Copy slow.
> Disconnected drive. Restarted Windows. Connected drive.
> Copying started fast, then became slow.
> 
> Device Manager => Volumes => Populate. Volume data received. Copying became
> faster. I have no idea how it works, but it shows some effect.
> Started copying. Starts very slow and then goes fast.
> 
> Reboot with USB drive. Stuck. Unplugged drive. Rebooted Windows.
> Connected USB drive. Started copying video files in Total Commander. Started
> fast then speed dropped to 1 MB/s.
> 
> Now drive steadily behaves like this: when connected, starts fast copy, the
> slows down to … KB/s. Drive slows boot and restart.

That initial burst is actually normal, but dropping to 1MB/s is classic
behaviour when you have a bad drive or controller that's generating I/O errors.
The reason for the initial burst is that when the I/O writes first start, the
operating system is filling the I/0 buffer in CPU RAM which it does very much
quicker than sustained disc I/O then once there is no more space in memory you
then see the true I/O speed and if you have a bad drive or controller you will
see it drop way down. For a spinning disc I'd expect anything from
30MB-160MB/sec. SSD maybe 200-400MB/s. So say you have 8GB CPU memory you would
expect to see that initial burst drop off after you had copied maybe 4-6GB of
files. As you are seeing 1MB/s after the initial burst I would say you do seem
to have a hardware fault. Like I mentioned earlier using ShredOS will confirm
that. Assuming you have a backup of everything on that disk. By using ShredOS
if you see the same effect i.e an initial burst (which is expected as explained
above) but then it drops to 1MB/s that would confirm to me you have a hardware
fault. Even on a 20 year old spinning disc you would see 20-35MB/s 30 seconds
or so after that initial burst. However if you don't see 1MB/s but see a
sustained throughput that is much higher, then you most likely have a software
issue. Until you run ShredOS you won't be able to isolate the problem. I'd also
do a grep on /var/log/ messages and also Windows event log to look for I/O
errors.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[empyreal]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #42 from empyreal  ---
I need to figure out whether it is hardware issue or not.
It’s some sort of interface buffer problem, because changing settings in
Windows helped for short period of time.

Windows. Mount slow. Copy slow.
Offline and disconnected drive. Waited few min.
Connected drive and Online. Mount slow. Copying slow.
Device Manager => Volumes => Populate. Data received but no help. Mount slow.
Copy slow. Very long Shutdown.

Windows. Waited few min. Connected USB drive. Mount slow. Copy slow.
Noticed that folders, copied on Kubuntu open with lag. Formatted USB drive just
in case. Switched buffer settings in Windows. Sometimes it helped USB drive to
copy faster, but for short period of time. Speed was unstable.

Made few Short DST of SAS-SCSI-FC until device passed in SeaTools. Rescanned.
USB 1394 showed up. Copy slow.
Disconnected drive. Restarted Windows. Connected drive.
Copying started fast, then became slow.

Device Manager => Volumes => Populate. Volume data received. Copying became
faster. I have no idea how it works, but it shows some effect.
Started copying. Starts very slow and then goes fast.

Reboot with USB drive. Stuck. Unplugged drive. Rebooted Windows.
Connected USB drive. Started copying video files in Total Commander. Started
fast then speed dropped to 1 MB/s.

Now drive steadily behaves like this: when connected, starts fast copy, the
slows down to … KB/s. Drive slows boot and restart.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[empyreal]

https://bugs.kde.org/show_bug.cgi?id=342056

empyreal  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REPORTED

--- Comment #41 from empyreal  ---
Copied 379 GB from internal notebook drive to USB drive. Different files,
mostly short videos. Process went successfully and took 4 hrs.
Queued 783 GB from internal desktop HDD”. In 6 hrs it copied 535 GB and again
stuck on mp3 (163 GB of mp3). Copying speed dropped to 2 MB/s which is strange:
these are not tiny files.
Assuming that average copying speed to USB 3.0 drive is 3 GB/min, these are
still bad results.

The only solution to make copying faster seems in queuing folders (F2 in
Krusader), which is annoying pain in the ass, when you need just to copy all
content from one drive to another.

Paused copy process and drive became unresponsive. Can’t open anything on USB
drive. Two CPU cores froze on 100% load. Krusader became unresponsive. Nothing
can be done.
Killed kioslave5 in System Monitor. Krusader became responsive. USB drive works
too.

Tried to copy 5 GB of jpegs. Very slow. 1 GB in 5 min. Cancelled. Krusader
works, drive works. No freeze.
Tried to copy 5 GB of mp3s. Same story. 1-2 MB/s.
Reached target Reboot. Stuck. Reset.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Luis Miguel García Mancebo]

https://bugs.kde.org/show_bug.cgi?id=342056

Luis Miguel García Mancebo  changed:

   What|Removed |Added

 CC|kte...@ktecho.com   |

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[empyreal]

https://bugs.kde.org/show_bug.cgi?id=342056

empyreal  changed:

   What|Removed |Added

 Status|REPORTED|RESOLVED
 Resolution|--- |FIXED

--- Comment #40 from empyreal  ---
When there is dual boot, Offline USB drive in Windows Disk Management after
use.

Now USB drive mounts properly - rw. Moreover - it works properly! Copying goes
as fast as on Windows and I feel dumb. But question remains: why Ctrl+C of cp
process in Konsole created issue with USB drive?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[empyreal]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #39 from empyreal  ---
Nick, thanks for help!

It’s system problem. Krusader and cp worked same way. Why expect rsync work
another way? I wrote that I got problem after canceling cp process in Konsole.
I never had any problems with this drive, till I tried copying in Konsole. I
was noticing sometimes that copying speed was slow, but I didn’t copy 200-300
GB to this USB drive, because all backups were done on Windows. I copied small
volumes from time to time. I’ll test it again after I deal away with ro mount
issue.

I managed to awake USB drive from coma in Windows 10 with Device Manager
(Populate function somehow worked out) and formatted drive in AOMEI, because
Windows showed messages with errors. Now on Windows everything works as it
should – 5 GB in 2 minutes! No issues with USB drive detection and mounting.

On Kubuntu I still have mount problem.
It always mounts USB drive as ro file system:
drwxrwxrwx  1 user user  4096 sep 18 20:31 'Seagate Backup Plus Drive'

/dev/sdc1 on /media/user/Seagate Backup Plus Drive type fuseblk
(ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)

$ sudo mount -o remount,uid=1000,gid=1000,rw /dev/sdc1
/dev/sdc1 on /media/user/Seagate Backup Plus Drive type fuseblk
(rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
rw now but still I can’t copy or create files.
It’s another issue, so I won’t flame here anymore.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Nick]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #38 from Nick  ---
(In reply to empyreal from comment #37)
> Copying finished. 5 GB transfer took almost 1hr O_O
> 
> Reboot failed. Linux was stopping Disk Manager for 90 sec and failed.
> Rebooting to Windows 10. Problems with loading drive.
> Reboot failed. Reset.
> Rebooting to Linux. 
> Can’t mount USB drive.
> sudo mount -o remount,uid=1000,gid=1000,rw /dev/sdc1 do not work too
> shutdown now
> Started PC and booted Kubuntu.
> Connected USB drive.
> Partition 1 does not start on physical sector boundary. AGAIN!!!
> Can’t mount in Krusader and Notifier.
> sudo mount -o remount,uid=1000,gid=1000,rw /dev/sdc1 do not work too
> Deleted partition. Formatted to NTFS.
> Partition 1 does not start on physical sector boundary. GONE!
> shutdown now
> Started PC. Booted Kubuntu.
> I am not authorized to mount device. No automount.
> sudo mount -o remount,uid=1000,gid=1000,rw /dev/sdc1 WORKED!!!
> Unmount in Notifier.
> shutdown now
> Started PC. Booted Kubuntu.
> USB drive is not mounted automatically.
> Notifier don’t show any messages.
> 
> All that nonsense went on till Partition Manager reported that it can’t
> create partition because of errors. I booted to Windows again and make all
> necessary operations in AOMEI. Then booted to Linux and got Partition 1 does
> not start on physical sector boundary. Installed GParted, reformatted
> everything and got USB drive which mounts on Linux with read-only file
> system and can’t mount on Windows anymore.
> 
> I don’t know exactly what happened, but USB drive started working on Kubuntu
> after I tried it on old notebook with Windows 7 where it didn't mount.
> Booted Kubuntu. Then connected USB drive. At first it was automatically
> detected like ro file system and then system redetected it again
> automatically in new folder with rw files system.
> 
> But now not only copying sucks in Krusader but Alt+Enter counts for
> eternity. Now is hard to tell whether Linux sucks or USB drive sucks, but I
> feel that USB controller on USB drive is glitchy, because even SeaTools on
> Windows do not detect it at first try.
> 
> Tried rsync but with 5 GB of images but it stuck after 2,5 GB as Krusader.
> Cancelled and got one CPU core freezed with 100% load.
> 
> That’s most annoying problem on Linux so far. Just simple cp canceling in
> Konsole... I wasted 3 days, figured basically nothing and made things worse.
> Last solution will be to open case and use external drive as internal. At
> least I am sure that drive inside has standard ports.

I've had very little problem with USB drives, I've been using KDE Neon for a
few years now. Sounds like you have a hardware fault especially as rsync
doesn't work either, I use rsync on a daily basis to check and copy thousands
of files, never have a problem. If that was my system I'd probably wipe the
drive with nwipe (ShredOS) https://github.com/PartialVolume/shredos.x86_64  ,
it will give you an idea of throughput and will check every block with
verification. if that bombs out with an I/O error I'd test the drive on another
system with a different USB controller in order to isolate the problem. If it's
the drive scrap it, it's not worth the hassle.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[empyreal]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #37 from empyreal  ---
Copying finished. 5 GB transfer took almost 1hr O_O

Reboot failed. Linux was stopping Disk Manager for 90 sec and failed.
Rebooting to Windows 10. Problems with loading drive.
Reboot failed. Reset.
Rebooting to Linux. 
Can’t mount USB drive.
sudo mount -o remount,uid=1000,gid=1000,rw /dev/sdc1 do not work too
shutdown now
Started PC and booted Kubuntu.
Connected USB drive.
Partition 1 does not start on physical sector boundary. AGAIN!!!
Can’t mount in Krusader and Notifier.
sudo mount -o remount,uid=1000,gid=1000,rw /dev/sdc1 do not work too
Deleted partition. Formatted to NTFS.
Partition 1 does not start on physical sector boundary. GONE!
shutdown now
Started PC. Booted Kubuntu.
I am not authorized to mount device. No automount.
sudo mount -o remount,uid=1000,gid=1000,rw /dev/sdc1 WORKED!!!
Unmount in Notifier.
shutdown now
Started PC. Booted Kubuntu.
USB drive is not mounted automatically.
Notifier don’t show any messages.

All that nonsense went on till Partition Manager reported that it can’t create
partition because of errors. I booted to Windows again and make all necessary
operations in AOMEI. Then booted to Linux and got Partition 1 does not start on
physical sector boundary. Installed GParted, reformatted everything and got USB
drive which mounts on Linux with read-only file system and can’t mount on
Windows anymore.

I don’t know exactly what happened, but USB drive started working on Kubuntu
after I tried it on old notebook with Windows 7 where it didn't mount. Booted
Kubuntu. Then connected USB drive. At first it was automatically detected like
ro file system and then system redetected it again automatically in new folder
with rw files system.

But now not only copying sucks in Krusader but Alt+Enter counts for eternity.
Now is hard to tell whether Linux sucks or USB drive sucks, but I feel that USB
controller on USB drive is glitchy, because even SeaTools on Windows do not
detect it at first try.

Tried rsync but with 5 GB of images but it stuck after 2,5 GB as Krusader.
Cancelled and got one CPU core freezed with 100% load.

That’s most annoying problem on Linux so far. Just simple cp canceling in
Konsole... I wasted 3 days, figured basically nothing and made things worse.
Last solution will be to open case and use external drive as internal. At least
I am sure that drive inside has standard ports.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[empyreal]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #36 from empyreal  ---
Trying to put my USB drive to normal working state.
Booted Linux. Connected USB drive.
Notifier said that I am not authorized to mount it, so USB drive didn’t mount
automatically.

I mount it with this command:
sudo mount -o remount,uid=1000,gid=1000,rw /dev/sdc1
USB drive mounted.

Started copying 5 GB of jpg files for testing purposes. Regretted. After 2.5 GB
speed dropped to 256 KiB/s. Afraid to cancel copying, because it will
definitely make HDD unresponsive again.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[empyreal]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #35 from empyreal  ---
Reboot stuck. Made hard reset. Rebooted.
Booting slowed dramatically both on BIOS phase and Linux HDD detecting phase.

After reboot to Kubuntu, it can’t automount external USB drive. I can’t mount
it in Notifier.

After reboot to Windows, it can’t mount external USB drive.
Shutdown PC. Disconnected and booted Kubuntu.
Connected external USB after boot. It didn’t mount automatically and I can’t
mount it manually in Notifier.
Deleted partition in Partition Manager. After that reboot became normal.

Booted to Windows. Formatted partition with AOMEI. Process was very slow, which
is abnormal, but finished. This copy process in Linux definitely hurts external
USB drive.

Start copying same data in Windows with Total Commander and got same problem.

Windows couldn’t shutdown with external USB drive.

It looks like canceling copy process in Linux makes external USB drive
unresponsive and reformatting, rebooting do not help.

Problems with this external USB drive started after canceling cp in Konsole.
After that I got some weird things with mounting. I was using this drive
happily without any problems till that moment. I am going through this problem
second time. Copy canceling is dangerous...

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[empyreal]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #34 from empyreal  ---
https://superuser.com/questions/424512/why-do-file-copy-operations-in-linux-get-slower-over-time
 
10 years later…

I cancelled this joke copying and it stuck two cores of my CPU on 100% and
freezed Krusader.

Before copying I didn’t have this message: Partition 1 does not start on
physical sector boundary. 
sudo fdisk -l
Disk /dev/sdb: 3,64 TiB, 4000787029504 bytes, 7814037167 sectors
Disk model: BUP BK  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: A601FD60-033F-4D1A-8E6C-BCEDD9D0D189

Device StartEndSectors  Size Type
/dev/sdb1 63 7814032063 7814032001  3,6T Microsoft basic data

Partition 1 does not start on physical sector boundary.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Nick]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #33 from Nick  ---
(In reply to empyreal from comment #31)
> This problem persists. 362 GB of data. F5 list of folders in Krusader from
> internal NTFS HDD to external NTFS USB 3.0 HDD.
> 
> 40 GB were copied very fast – 20 min or so. 180 GB were copied slowly in 3hr
> and I thought the rest 182 GB would be copied in 3hrs but it didn’t happen.
> Almost 12 hrs passed, but it copied 270 GB.
> 90 GB still to go according to copying status.
> It’s definitely not OK.

I feel your pain, while I love Dolphin, for me it's only capable of dealing
with small amounts of data due to this 'grave' bug. And yes it is a grave bug
for those that work with a lot of data. I generally use cp and rsync instead of
dolphin for anything more than a few files. Having said that there is
absolutely no reason why Dolphin should not be as fast as cp or rsync , we are
talking I/O here, orders of magnitude slower than any CPU can operate at. The
problem here is a bug or at least the way Dolphin does the copy. If that's
correct that every time a file is copied some massive list is sorted then
that's just not the way you do it. I only wish I could devote my time to fixing
this problem. It's the one bug/feature in Dolphin that spoils an otherwise
excellent program.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[empyreal]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #32 from empyreal  ---
lsusb
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 0bc2:ab30 Seagate RSS LLC BUP BK
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 056a:033b Wacom Co., Ltd CTL-490 [Intuos Draw (S)]
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

lsusb -t
/:  Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 1M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 1M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 1M
|__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
|__ Port 13: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 13: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 13: Dev 2, If 2, Class=Human Interface Device, Driver=usbhid, 12M

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[empyreal]

https://bugs.kde.org/show_bug.cgi?id=342056

empyreal  changed:

   What|Removed |Added

 Status|CONFIRMED   |REPORTED
 Ever confirmed|1   |0

--- Comment #31 from empyreal  ---
This problem persists. 362 GB of data. F5 list of folders in Krusader from
internal NTFS HDD to external NTFS USB 3.0 HDD.

40 GB were copied very fast – 20 min or so. 180 GB were copied slowly in 3hr
and I thought the rest 182 GB would be copied in 3hrs but it didn’t happen.
Almost 12 hrs passed, but it copied 270 GB.
90 GB still to go according to copying status.
It’s definitely not OK.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[empyreal]

https://bugs.kde.org/show_bug.cgi?id=342056

empyreal  changed:

   What|Removed |Added

 CC||empyr...@ukr.net

--- Comment #30 from empyreal  ---
I have similar issue copying to external 3.6TB USB3.0 NTFS drive in Krusader.
362 GB of data. Different files: music, video, pictures, text…
It couldn’t copy this information volume during whole night O_o

Now I reformatted drive in NTFS with default cluster size without any
additional parameters. Before drive was formatted by vendor and had additional
small partition at the beginning.

At first copying started with 100MB/s and after 40 GB speed dropped to 0,5-2
MB/s while copying mp3 files. Speed is very unstable. Sometimes jumps to 30-60
MB/s, then drops to 0,5-2 MB/s. It copies better after formatting, but is it
OK?

Operating System: Kubuntu 21.04
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.86.0
Qt Version: 5.15.2
Kernel Version: 5.11.0-34-generic (64-bit)
Graphics Platform: X11

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Safeer Pasha]

https://bugs.kde.org/show_bug.cgi?id=342056

Safeer Pasha  changed:

   What|Removed |Added

 CC||safeerpas...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Salvatore]

https://bugs.kde.org/show_bug.cgi?id=342056

Salvatore  changed:

   What|Removed |Added

 CC||sannythebes...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Patrick Silva]

https://bugs.kde.org/show_bug.cgi?id=342056

Patrick Silva  changed:

   What|Removed |Added

 CC||bug@petzel.at

--- Comment #29 from Patrick Silva  ---
*** Bug 428073 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Postix]

https://bugs.kde.org/show_bug.cgi?id=342056

Postix  changed:

   What|Removed |Added

 CC||pos...@posteo.eu

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Méven Car]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #28 from Méven Car  ---
Git commit 10cf5aca5b3da2608eaf2967415d0b09b36121ac by Méven Car.
Committed on 04/04/2020 at 18:52.
Pushed by meven into branch 'master'.

File ioslave : use Better setting for sendfile syscall

Summary:
Changes :
 * use sendfile when copying file bigger than 2 GB
 * copy 512 kB instead of previously 32 kB for each sendfile or read/write
copying iteration

This effectively increase the copying speed, since the filesystem is asked to
copy more at once, it lets it reach higher speed before getting the next data
to copy.
Related: bug 402276

Test Plan: Copying large files or folders with medium sized files (for instance
photos) is noticebly faster.

Reviewers: #frameworks, dfaure

Reviewed By: dfaure

Subscribers: bruns, broulik, kde-frameworks-devel

Tags: #frameworks

Maniphest Tasks: T11627

Differential Revision: https://phabricator.kde.org/D28555

M  +3-5src/ioslaves/file/file_unix.cpp

https://commits.kde.org/kio/10cf5aca5b3da2608eaf2967415d0b09b36121ac

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=342056

Nate Graham  changed:

   What|Removed |Added

   Priority|NOR |HI

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=342056

Nate Graham  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=339830

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Alexander Potashev]

https://bugs.kde.org/show_bug.cgi?id=342056

Alexander Potashev  changed:

   What|Removed |Added

 CC||aspotas...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=342056

alex...@gmx.net changed:

   What|Removed |Added

 CC||alex...@gmx.net

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=342056

Nate Graham  changed:

   What|Removed |Added

 CC||kte...@ktecho.com

--- Comment #27 from Nate Graham  ---
*** Bug 396093 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Nick]

https://bugs.kde.org/show_bug.cgi?id=342056

Nick  changed:

   What|Removed |Added

 CC||nick.craig@gmail.com

--- Comment #26 from Nick  ---
Hmmm, I've just posted what sounds like the same problem here
https://bugs.kde.org/show_bug.cgi?id=393748

I've added attachments showing the debug output of the plasma-shell threads and
dolphin threads. Hope it is useful.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=342056

Nate Graham  changed:

   What|Removed |Added

 CC||ka...@seznam.cz

--- Comment #25 from Nate Graham  ---
*** Bug 203277 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[karaluh]

https://bugs.kde.org/show_bug.cgi?id=342056

karaluh  changed:

   What|Removed |Added

 CC|kara...@karaluh.pl  |

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=342056

Nate Graham  changed:

   What|Removed |Added

 CC||kara...@karaluh.pl

--- Comment #24 from Nate Graham  ---
*** Bug 304136 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Simon Andric]

https://bugs.kde.org/show_bug.cgi?id=342056

Simon Andric  changed:

   What|Removed |Added

 CC||simonandr...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[David M]

https://bugs.kde.org/show_bug.cgi?id=342056

David M  changed:

   What|Removed |Added

 CC||davidmarch...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Jaime Torres]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #23 from Jaime Torres  ---
Git commit e1fe26f1fc78082fdb215cb818177541d4607d9c by Jaime Torres.
Committed on 19/02/2018 at 20:09.
Pushed by jtamate into branch 'master'.

Reduce plasmashell frozen time to almost nothing

Summary:
Related: bug 358231
Even the icon with the number of tasks pending moves from time to time.

To reduce the frozen time, a similar patch must be applied also to
frameworks/kwindowsystem src/platforms/xcb/kxmessages.cpp
frameworks/plasma-framework src/plasma/private/effectwatcher.cpp

According to the documentation (and a look to the source code)
http://doc.qt.io/qt-5/qabstractnativeeventfilter.html

The type of event eventType is specific to the platform plugin chosen
at run-time, and can be used to cast message to the right type.

On X11, eventType is set to "xcb_generic_event_t", and the message can
be casted to a xcb_generic_event_t pointer.

The other eventType are "windows_generic_MSG" and "mac_generic_NSEvent".
No other eventType starts with an 'x'.

Test Plan:
Cut & paste 2000 small files.
Before, a freeze (plasmashell not responding) of minutes
After, a freeze of seconds

Reviewers: #frameworks, #plasma, davidedmundson

Reviewed By: #plasma, davidedmundson

Subscribers: broulik, davidedmundson, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D10627

M  +1-1shell/screenpool.cpp

https://commits.kde.org/plasma-workspace/e1fe26f1fc78082fdb215cb818177541d4607d9c

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Philippe Didier]

https://bugs.kde.org/show_bug.cgi?id=342056

Philippe Didier  changed:

   What|Removed |Added

 CC||philippedid...@laposte.net

--- Comment #22 from Philippe Didier  ---
I don't know if it would be useful for this bug but I got some problems with
Dolphin (Mageia 6, KF5 16.12.3  Dolphin 16.12.3 plasma 5.8.7)


It seems that Dolphin doesn't work always the same way for ntfs partitions
 on USB external disk:

 It depends on the way this partition is mounted :

 1) if it is mounted with fstab (in this case it apparently DOES NOT USE 
 udisks2) we can explore the content on the mout point choosen in fstab but it 
 freezes eating CPU with mout.ntfs-3g and gam_server 
Dolphin is quite unresponsive when exploring a huge folder containing
subfolders with thousands of photos

 2) if it is an hotplugged partition (in this case it seems to use udisks2) a
 notification pop-up proposes to use Dolphin and it is OK : 
 we explore it in /run/media/username/hddname 
 (mount-ntfs-3g and gam_server use CPU for 3 seconds) and we get no freeze
exploring the same NTFS partition

https://bugs.mageia.org/show_bug.cgi?id=7985#c12

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Jaime Torres]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #21 from Jaime Torres  ---
Oh!, I misread the data. The file operations are fast, but plasma is still
showing information about half the files when the files operations has already
concluded. (This could be easier to improve than the lock and could reduce the
lock time).

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Jaime Torres]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #20 from Jaime Torres  ---
The performance improvements apply also to the problem with several thousands
of files in several directories.
Just to be sure, I've checked a harder test case (50.000 little files in
several directories) and the performance improvements apply, but there is still
room for improvement, because after moving 25.000 files, the performance drops.
The problem with plasma being locked is still pending, but we are working on
it.
As you can see, it is not an easy bug to fix.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Kevin Kofler]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #19 from Kevin Kofler  ---
The reporter wrote:

(Alexander Nestorov from comment #5)
> I copy the entire folder, without getting inside it.

but as far as I can tell, your optimizations are all only addressing the case
where somebody selects many individual files and drags them somewhere as
a group, not the case the reporter described (a recursive copy of one single
folder that just happens to contain many small files inside).

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Jaime Torres]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #18 from Jaime Torres  ---
Git commit 9fbf7a0b624aee6b116efdf69462e73f0275fab6 by Jaime Torres.
Committed on 05/02/2018 at 18:25.
Pushed by jtamate into branch 'master'.

Faster drag in directories with thousands of files

Summary:
The check is called when the mouse is moved in a drag operation.

Dragging all files in a directory with 3000 files under callgrind,
moving the mouse to the other panel and then canceling, doing it twice,
callgrind shows that the method urlListMatchesUrl is called around
200 times, spending around 9,30% of the cpu in those calls.
Applying the patch, callgrind tells it uses now 0.31% of the cpu in 1208 calls.

Reviewers: #dolphin, elvisangelaccio, markg

Reviewed By: #dolphin, elvisangelaccio, markg

Subscribers: markg, anthonyfieroni, michaelh, elvisangelaccio, ngraham

Differential Revision: https://phabricator.kde.org/D10085

M  +3-0src/kitemviews/kitemlistcontroller.cpp
M  +17   -3src/views/draganddrophelper.cpp
M  +10   -0src/views/draganddrophelper.h

https://commits.kde.org/dolphin/9fbf7a0b624aee6b116efdf69462e73f0275fab6

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Jaime Torres]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #17 from Jaime Torres  ---
Git commit 18e4d245d3d595cdc17ad40aa88495d6d2c30bf7 by Jaime Torres.
Committed on 28/01/2018 at 11:01.
Pushed by jtamate into branch 'master'.

Use the much faster urls() method from QMimeData

Summary:
When requesting a list of text/uri-list, use the much faster QMimeData
urls() method.
The unittests pass (the desktop: protocol) and
is half solved. The paste speed is as fast as drag in local files
and with fish: files.
The lock in X11 plasma or kwin still needs another patch.

Test Plan: Select 2000 files in one folder, cut and paste them in another disk.

Reviewers: #frameworks, dfaure

Reviewed By: dfaure

Tags: #frameworks

Differential Revision: https://phabricator.kde.org/D10155

M  +6-3src/lib/io/kurlmimedata.cpp

https://commits.kde.org/kcoreaddons/18e4d245d3d595cdc17ad40aa88495d6d2c30bf7

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=342056

aux...@gmail.com changed:

   What|Removed |Added

 CC||aux...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #16 from Nate Graham  ---
Thanks, that's hugely helpful! We're actively investigating this, BTW.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Dr . Chapatin]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #15 from Dr. Chapatin  ---
I did some tests on Arch Linux running plasma 5.12 beta and dolphin 17.12.1.
Always copying/moving a folder containing 104.607 small files and 1.678
subfolders (889 MiB) from a hard disk to another hard disk, both formatted with
NTFS file system.

copy using ctrl+c/ctrl+v: completed in 9 minutes
copy using "copy" and "paste" from dolphin context menu: completed in 11
minutes

move using ctrl+x/ctrl+v: completed in 72 minutes
move using "cut" and "paste" from dolphin context menu: completed in 158
minutes (???)

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=342056

Nate Graham  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |CONFIRMED

--- Comment #14 from Nate Graham  ---
For people experiencing this, how are you doing the copy?

copy-paste?
drag-and-drop?

Does it happen for both methods, or just one?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=342056

Nate Graham  changed:

   What|Removed |Added

 CC||jtam...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Dr . Chapatin]

https://bugs.kde.org/show_bug.cgi?id=342056

--- Comment #13 from Dr. Chapatin  ---
This old bug makes dolphin unusable to deal with high amount of small files.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=342056

Nate Graham  changed:

   What|Removed |Added

Product|kio |frameworks-kio
Version|4.14.1  |5.42.0
 CC||kdelibs-b...@kde.org
  Component|general |general

-- 
You are receiving this mail because:
You are watching all bug changes.