Good day. I do not know English well, so I apologize in advance.
When working with the program, cp found an annoying issue that occurs exclusively when copying files between different physical devices.
For example, if i start copying
And at the same time begin to perform I/O operations on the source disk, for example, such as du -sh /something_on_the_source_disk, so that the cp utility will periodically return such messages:
This happens only when additional I/O load goes to the disk-source, such as du -sh /mnt/Z/blalba.
If produce additional I/O-load on the disk-destination in a similar way, then there are no interruptions and the copying goes well.
If you copy within a single device (cp -R /usr/ports /usr/ports_rc) and not between different devices, and similarly create additional I/O load during copying, then copying occurs successfully, without interruptions.
If we talk about a similar experiment, but instead of cp, use, for example, KDE (Dolphin) and make extra-io load on the source disk - copying also goes well.
It turns out that the cp command, if i make an additional load on the source disk, catches an interrupt, and as a result, not all files will be copied to the disk-destination, Dolphin-copy-paste works well even with additional load on the source disk
Can anyone share any tips on how to make cp work properly in this case, without interruptions?
In fact, this behavior of cp utilities is surprising, because it is native to FreeBSD, but it turns out that ported Dolphin behaves more stable when it comes to copying files.
When working with the program, cp found an annoying issue that occurs exclusively when copying files between different physical devices.
For example, if i start copying
Code:
cp -R /usr/ports /mnt/ZAnd at the same time begin to perform I/O operations on the source disk, for example, such as du -sh /something_on_the_source_disk, so that the cp utility will periodically return such messages:
Code:
cp: databases/php85-pdo_odbc/Makefile: aborted system call
cp: databases/phpmyadmin/pkg-plist-chunk: aborted system callThis happens only when additional I/O load goes to the disk-source, such as du -sh /mnt/Z/blalba.
If produce additional I/O-load on the disk-destination in a similar way, then there are no interruptions and the copying goes well.
If you copy within a single device (cp -R /usr/ports /usr/ports_rc) and not between different devices, and similarly create additional I/O load during copying, then copying occurs successfully, without interruptions.
If we talk about a similar experiment, but instead of cp, use, for example, KDE (Dolphin) and make extra-io load on the source disk - copying also goes well.
It turns out that the cp command, if i make an additional load on the source disk, catches an interrupt, and as a result, not all files will be copied to the disk-destination, Dolphin-copy-paste works well even with additional load on the source disk
Can anyone share any tips on how to make cp work properly in this case, without interruptions?
In fact, this behavior of cp utilities is surprising, because it is native to FreeBSD, but it turns out that ported Dolphin behaves more stable when it comes to copying files.
