On 11/28/2016 07:53 AM, Samuel Sieb wrote: > On 11/27/2016 10:40 PM, drago01 wrote: >> On Monday, November 28, 2016, Py <py@xxxxxxxxx <mailto:py@xxxxxxxxx>> wrote: >> >An SSD drive might not have this problem, but a spinning disk >> >definitely >> >will. You should never try running multiple copies on the same disk if >> > >> >you want it to finish in a reasonable time. With one copy, you can do >> >long contiguous reads and writes, but if you have multiple copies >> >happening, the read and write head will be bouncing all over the disk. >> >> So ideally this is the file manager job to queue copy operations. >> This allows to do right even when the user is wrong, or wants to >> launch big copy before coffee. >> >> >> No. The kernel (io scheduler) is supposed to order requests to avoid >> this scenario. Also sequential reads / writes only happen for large >> files if there is no fragmentation. >> > How could the kernel ever schedule this nicely? Is it going to hold up > one process until the other one is finished? one thing the kernel knows reasonably well but user-space has to work out with some effort is which of the multiple copy operations the user has started are actually working on completely independent storage devices, in which case there is no penalty to doing them in parallel. is there an implementation of an heuristic to determine that from user-space? i'm quite sure it's more complicated than it appears at first glance, what with DM, MD, eCryptFS, FUSE, iSCSI, NFS etc. complicating things, not to mention you could be running in a VM where you have no idea where your "sda" and "sdb" actually are. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
