Re: Nautilus usability

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux