[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Nautilus usability
From:       drago01 <drago01 () gmail ! com>
Date:       2016-11-28 6:40:02
Message-ID: CAMqY-Ffaa8s=9sqvZAosnr5Hm6nDbWCCpeX2-1Fc_0SBdhHV4A () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Monday, November 28, 2016, Py <py@luyten.fr> wrote:

>
>
>
> >>> Have you ever made Nautilus copy/move a huge directory tree and then
> >>> started a similar task for other directories while Nautilus was
> >still
> >>> working on the first task?
> >>
> >> A directory containing 10,000 1MiB files moved to another directory
> >> completes immediately. Copying takes a while, as expected, and
> >multiple
> >> copies has the behavior you describe.
> >>
> >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.

[Attachment #5 (text/html)]

<br><br>On Monday, November 28, 2016, Py &lt;<a \
href="mailto:py@luyten.fr">py@luyten.fr</a>&gt; wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><br> <br>
<br>
&gt;&gt;&gt; Have you ever made Nautilus copy/move a huge directory tree and then<br>
&gt;&gt;&gt; started a similar task for other directories while Nautilus was<br>
&gt;still<br>
&gt;&gt;&gt; working on the first task?<br>
&gt;&gt;<br>
&gt;&gt; A directory containing 10,000 1MiB files moved to another directory<br>
&gt;&gt; completes immediately. Copying takes a while, as expected, and<br>
&gt;multiple<br>
&gt;&gt; copies has the behavior you describe.<br>
&gt;&gt;<br>
&gt;An SSD drive might not have this problem, but a spinning disk<br>
&gt;definitely<br>
&gt;will.   You should never try running multiple copies on the same disk if<br>
&gt;<br>
&gt;you want it to finish in a reasonable time.   With one copy, you can do<br>
&gt;long contiguous reads and writes, but if you have multiple copies<br>
&gt;happening, the read and write head will be bouncing all over the disk.<br>
&gt;_____________________________<wbr>___________<br>
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.<br> \
______________________________<wbr>______________<br> \
</blockquote><div><br></div><div>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.  </div>


[Attachment #6 (text/plain)]

_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org


[prev in list] [next in list] [prev in thread] [next in thread]