[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Another rfe: "cp" this time
From: |
Bruce Korb |
Subject: |
Re: Another rfe: "cp" this time |
Date: |
Tue, 1 May 2012 13:01:32 -0700 |
Hi Pádraig,
On Tue, May 1, 2012 at 9:59 AM, Pádraig Brady <address@hidden> wrote:
> It should be possible at least on a per file basis,
> to indicate we want to read the file sequentially,
> and thus the kernel can use appropriate read-ahead
> to keep its buffers full, and network protocols
> can behave intelligently too, like interleaving reads
> for example.
"extended read ahead", methinks. The read ahead needs to tune itself
to latency.
> Now many coreutils already provide such a hint to the kernel:
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=47076e3c
> But copy.c does not currently. I'm not sure why I didn't
> do it for copy.c now, but
:) I'm glad I'm not the only one guilty of oversight....
> In the meantime you might be able to tweak cifs read-ahead
> settings, or ask on a samba list as to how to more efficiently
> stream over high latency links.
Read ahead is more likely tuned at a slightly higher layer, the glue
layer over CIFS or NFS (or EXT4?). I would hope anyway.
There are dusty cobwebs layered over my recollections of the ufs
file system. That is the code that ought to be looking at response
delays and deciding how much read ahead is needed for the
demand rate vs. the turnaround time.
If that fix goes in, I could see it in less than 5 years! :)
Regards, Bruce