ntfs?

НУ конечно же НТФС!!! Что же еже я могу юзать под линухой, а топом жаловаться! (ладно сейчас выделю жирным что ехт4)

А разделы выровнены?

Не знаю, каждый раздел - все устройство... О каком выравнивании идет речь? Я об этом никогда не задумывался... Можно по подробнее?

Ты бы почитал, что такое DMA, а также что такое файловая система.

Если кратко: копирование файла — это не просто тупое переписывание байтиков с одного места на жёстком диске на другое место.

fdisk -l

Всё нормально.

Слишком толсто.

Если кратко

Это не кратко, это никак.

Ты бы почитал, что такое DMA, а также что такое файловая система.

Намек непонятен, что же именно делает процессор что возникает заметная загрузка?

Что perf top показывает?

sudo perf top -a -d 1 -v
В приоритете copy_user_generic_string

mmap size 528384B
Looking at the vmlinux_path (6 entries long)
Using /proc/kcore for kernel object code
Using /proc/kallsyms for symbols
Failed to open /tmp/.gll7xnLp, continuing without symbols
Failed to open /tmp/perf-2271.map, continuing without symbols
Failed to open /tmp/perf-2405.map, continuing without symbols

PerfTop: 1580 irqs/sec kernel:49.1% exact: 0.0% [4000Hz cycles], (all, 2 CPUs)
-------------------------------------------------------------------------------

6.76% /lib/x86_64-linux-gnu/libc-2.19.so 0x8b83a
3.84% /proc/kcore 0x7fff8139599c
3.17% /lib/x86_64-linux-gnu/libc-2.19.so 0x870ca
2.38% /proc/kcore 0x7fff810f14b3
2.23% /proc/kcore 0x7fff81392d9a
2.08% /proc/kcore 0x7fff813921ad
1.84% /lib/x86_64-linux-gnu/libc-2.19.so 0x7fd98
1.59% /tmp/perf-vdso.so-l2EsRy 0xfcf
1.51% /lib/x86_64-linux-gnu/libc-2.19.so 0x8bcf3
1.46% /proc/kcore 0x7fff813955c7
1.43% /proc/kcore 0x7fff81391415
1.28% /proc/kcore 0x7fff810f09b5
1.08% /proc/kcore 0x7fff81394630
1.07% /proc/kcore 0x7fff8139377d
1.02% /lib/x86_64-linux-gnu/libc-2.19.so 0x6ef60
0.92% /proc/kcore 0x7fff81394ad0
0.76% /lib/x86_64-linux-gnu/libc-2.19.so 0x83271
0.74% /proc/kcore 0x7fff81396c70
0.72% /usr/lib/linux-lts-utopic-tools-3.16.0-48/perf 0x94c0c
0.68% /lib/x86_64-linux-gnu/libc-2.19.so 0x97fd0

http://pastebin.com/EyHdK5fU

http://picpaste.com/snapshot20-IChZQJ2v.png

Так и запишем: линакс в 2015 году не умеет в DMA.

Всё вроде как норм, CPU тратится на копирование из ядра в пространство пользователя и обратно. Даже если нужно скопировать сплошной кусок с одного диска на другой, данные надо прочитать (DMA), потом скопировать из ядра в буфер пользователя, потом скопировать обратно в ядро и, наконец, записать на диск (DMA). Без DMA в операциях с диском ты упрёшься где-то в 33 МБ/c. Копирование в памяти — десятки ГБ/с, синхронное.

Какие скорости-то хоть?

sendfile() работает для двух файлов без копирования в userspace. Почему гнутый cp его не использует?

А чем ты копируешь? Попробуй в консоли cp/mv.

Посмотри биос -скорее всего включена совместимость с IDE ,включи наитивный режим ,иначе не включится планировщик очереди команд и dma 150 или 300 .

Почему гнутый cp его не использует?

coreutils-8.23/TODO

Integrate use of sendfile, suggested here:
http://mail.gnu.org/archive/html/bug-fileutils/2003-03/msg00030.html
I don't plan to do that, since a few tests demonstrate no significant benefit.

85-95 с винта на винт

Там AHCI

Начиная с Linux 2.6.33 системный вызов sendfile позволяет копировать файл в файл. В таком случае данные не будут копироваться в юзерспейс и обратно, а пойдут по DMA. Обычный cp этого не делает

I don't plan to do that, since a few tests demonstrate no significant benefit.

Брешут'с

Я вот смотрел диспетчер задача под седьмым ведром там такие операции вообще не влияют на «картинку»... Както обидно получается...

Кстати вот сейчас смотрю htop и KDE System Monitor
у первого загрузка по двую ядрам 16%+16%, а у второго «пила» от 80 до 100%. Интересная разница, смотрю в /proc/stat кажется KDE прав. Тогда что показывает htop?

krusader из консоли эффект тот же

few tests demonstrate

Ага, и без самих тестов и их результатов.

Держите говнокод для теста:

//c++ -std=c++1z -o sendfile sendfile.cc
#include<cassert>
#include<fcntl.h>
#include<sys/sendfile.h>
#include<sys/stat.h>

int main(int argc,char**argv){
  assert(argc==3);
  auto in=open(argv[1],O_RDONLY),
      out=creat(argv[2],S_IRUSR|S_IWUSR);

  struct stat stt;
  assert(in>=0 && out>=0 && !fstat(in,&stt) && S_ISREG(stt.st_mode));

  off_t off=0;
  while(1){
    auto res=sendfile(out,in,&off,0x7ffff000);
    assert(res>=0);
    if(!res)
      break;
    }
  }

Я надеюсь, ты имеешь в виду не то, что krusader запускал в консоли?

тьху блин! а я на планировщик вместе с 12309 грешил, а они оказывается такие ракалы

TTY1 cp 1.iso ~/2.iso

Да неважно, команда «cp откуда куда» в консоли. Да?

Ок, не видел исправления.

А вот это скомпилить и запустить вместо cp попробуй: DMA только на словах? (комментарий)

12309 закрыли же!

Теперь это не баг а фича!

Хм. Да вроде один в один 4.3Гб/45сек

А у тебя есть прирост скорости? Какой дистр? Я уже думаю может Цент7й посмотреть вроде проэкт солидный...

Я не проверял, только убедился что работает.

Давно уже пора сажать за cp