Интересно, почему линукс тормозит при копировании с HDD на HDD, хотя система на SSD

Интересно, почему линукс тормозит при копировании с HDD на HDD, хотя система на SSD

потому что при копировании с HDD на HDD неважно, что у тебя там за SSD не используется. толсто, скучно, язабан.

а линукс-то здесь при чем? Пусть себе копирует с hdd на hdd, чего система-то страдать должна, объясни?

Потому что он копирует. 12309 заключаетс в пониженной отзывчивости во время тяжелого дискового IO. Система при этом может хоть в tmpfs лежать, хоть в Гонолулу, лишь бы был IO.

Вроде объясняют это говёным взаимодействием подсистем vm и io, те ядро пытается прикинуть что можно закэшировать а что высваписть, вместо того чтобы выполнять само io.

А пробовал I/O polling ?

Поддержка поллинга ввода/вывода для блочных устройств (I/O polling). Поллинг позволяет уменьшить нагрузку на систему при использовании высокопроизводительных устройств за счёт периодического опроса состояния вместо генерации прерываний. Как следствие, в определённых ситуациях включение поллинга позволяет существенно повысить пропускную способность и сократить задержки ввода/вывода. Включение производится через запись 1 в /sys/block/DEV/queue/io_poll. В настоящее время поддерживается только режим O_DIRECT, а реализация помечена как экспериментальная и предназначенная для тестирования;

как раз в 4.4 появилось.

в венде вирусы, в линуксах 12309, у каждой системы свои косяки

А линукс тут может быть и не при чем. Я и на виндах такое видел: при интенсивном дисковом IO все тормозит и лагает, даже RDP-сессия к удаленному компьютеру.

Не пробовал, можно затеститровать, но на данных массивах пока-что неохота испортить fs/данные, если оно предназначено для тестирования. Чуть позже потестю, когда будет свободное место.

Запусти копирование через это: https://github.com/Feh/nocache

Попробую, спасибо.

попробуй отключить cfq/bfq и/или включить blk-mq, scsi-mq etc.

в венде вирусы, в линуксах 12309, у каждой системы свои косяки

в макоси ни первого, ни второго нет

про вирусы ложь, не говоря уж о червях.

их в и линуксе полно.

зато макося плохо кастомизируется.

А uksm на 4.4 ты сам портировал? Вот это не применяется: http://kerneldedup.org/download/uksm/beta/uksm-0.1.2.4-beta-for-linux-v4.0.patch

Да, сам.

попробуй rsync-ом. Копирую сотни гигов, никакого 12309 не наблюдал. Своп выключен, естественно.

а какое к этому отношение имеет своп?

те ядро пытается прикинуть что можно закэшировать а что высваписть, вместо того чтобы выполнять само io.
высвапить

выше уже всё сказали

ясно, ну, у меня 16 рамы, свопа нет, попробую рсинком, спс.

Зато там тиринг есть.

ТС, что за дистр, какое ядро? У меня нет такого.

4.4.1-gentoo.

в макоси - Зато там тиринг есть.

Как можно увидеть? Ни на тестах, ни в играх ни как не мог его найти. Хотя в линуксе - это обычное дело.

HDD2 (HFS+) --> HDD1 (exFAT).

А как система себя ведёт на нормальных ФС?

Тут на него макофилы жаловались на ЛОРе, поищи.

ЗЫ

Сам видел тиринг на маке на ютубе, правда давно было, лет 5 прошло.

А как система себя ведёт на нормальных ФС?

Не доводилось пока-что копировать большие объемы с ext4 на ext4.

Почитай в гугле про

/proc/sys/vm/dirty_background_bytes
/proc/sys/vm/dirty_bytes
/proc/sys/vm/dirty_expire_centisecs
/proc/sys/vm/dirty_writeback_centisecs
/proc/sys/vm/swappiness
/proc/sys/vm/vfs_cache_pressure

Оно лишь смягчает симптомы.

Разумеется, обычно у кукарекающих про 12309 что-то глючит или неоптимально настроено, но разбираться сложнее, чем кукарекать про 12309.

exFAT

Так оно ж через fuse, потому и тормозит

Почему в BSD оптимально из коробки?

Сначала плпробуй ядерный exfat. FUSE для дисковых устройств - это изврат.

Там еще при чтении с плохого CD/DVD все умирает, когда перебор скоростей начинается :)

Причём тут оптимальность, если у большинства страдальцев тупо глючные драйвера(видео например), нехватка памяти или убитый смарт?

12309 заключаетс в пониженной отзывчивости во время тяжелого дискового IO

Я единственный человек, который никогда не встречал 12309?

Походу да

Сначала плпробуй ядерный exfat

вот этот? Его в гента-поставке нет увы, придется накладывать, хз как оно совместимо с 4.4.1

Нет, ты один из многочисленных нарушителей 4.2.

нет

В бытность мою студентом, у товарища на Intel Pentium MMX + материнка на Intel-каком-то чипсете очень четкая прослеживалась связь: лампочка HDD на системнике моргнула — проигрывание MP3 «заикнулось», причем что на винде, что на пингвинятине. У меня на Cyrix 6x86MX + материнка на VIA такого и близко никогда не было. Ядро тогда было что-то или 2.2, или 2.4 (интернет был по диалапу, обновлений особо не накачаешься, что на дисках продавалось — тем и пользовались).

А вообще, ты на винду не гони! Там настоящая многозадачность! Щас скринкаст запишу в подтверждение... только дискетку доформатирую... ;)

Угу. Ты главное не вынимай сидюк во время чтения :)

Ага, только недавно садился за win xp c dvd-rw, когда вставляешь диск explorer(вся оболочка) встаёт раком. Диски чистые, не записанные, в логах ошибок нет.

Да-да-д. Жалко, проверить не на чем: пингвинообразное перестало биться в истерике падать, если у него неотмонтированную дискетку отобрать? :)

Собственно, возвращаясь теме: причина 12309 может быть и аппаратная, если еще в те лохматые годы MP3 у одних заикалось, а у других — нет.

А что, у тебя были кернелпаники при вытаскивании дискетки?

Это потому что у тебя Mint, там нет множества багов присущих другим дистрибутивам.

Пардон, паники вроде не было, но истерика была знатная: оно безостановочно трещало дисководом в безуспешных попытках вернуть «свою прелесть» и сыпало сообщениями об ошибках.

Где-то с 2000-го года с линуксом вожусь, тогда никаких минтов в природе не было.

Сначала плпробуй ядерный exfat.

Да, подтверждаю, хоть скорость на ядерном exfat и fuse — одинаковые, но теперь io нормальное! Торможений нет, чудеса!

Спасибо, ну тогда отмечаю решенным.

Почему «мертвая» FreeBSD на IDE 40 гиговом работает быстрее?

Потому, что код свопа, планировщика и т.п. на много ветвистее и сложнее.

Значит, не io, а контекст