Почему процесс копирования файлов занимает 100% CPU?

Попробуйте скопировать несколько больших файлов одновременно

Недавно копировал фильмы, около Тб, с одного ntfs-хдд на другой с exfat, ничего подобного не заметил, одновременно смотрел видосики на ютуб. Долго и нудно, скорее это так.

12309 ещё не починили?

Нет

Какая файловая система? Старый драйвер ntfs в линуксе может кушать 100% CPU.

А как его воспроизвести?

ext4\btrfs

Просмотр видосика на YT не очень требователен к ресурсам (зависит от разрешения и кодека ofc). Система-то работает более менее, но если открыть мониторнг, то в простое, допустим 5% CPU нагружен, а во время копирования стабильно 70-90%.

Так ты посмотри в мониторинг внимательнее. Что за процессы нагружают процессор, чем именно нагружают (i/o wait, sys, user)

Так как характеристик техники нет, то вангую что делаешь это на процессоре типа intel Atom, в двухъядерной компоновке. У меня тоже нагружает процессор, но в основном это одно ядро на ~50%(6% от максимальной нагрузки. А вот ответ на вопрос «почему нагружается процессор», ну, судьба у него такая)). Предполагаю что процесс копирования это не аппаратная штука, а сугубо программная с множеством однотипных операций, вот на это и расходуется вся «мощь» конвеера твоего CPU.

покажи # hdparm -i /dev/ на котором ты проверяшь копирование

Там есть строки с доступными режимами работы с диском (PIO/DMA/UDMA) и «звездой» отмеченный текущий режим. Если умолчательный режим один из PIO то тебе «свезло».

Если сильно интересно, расскажу, что такое PIO/DMA/UDMA

А товарищу майору слить через либастрал?

Каккое нахрен PIO в 2024-м году? Его 30 лет назад уже не было.

Афтар нам не сообщил используемое железо.

Насчет 30 лет назад, ты конечно преувеличиваешь. Я лично это видел и использовал примерно во второй половине 90-х.

Потому что контроллер-диск работают без DMA?

Ах, как давно это было... Бывало, DMA слетало и мы вертали. Руками.

Попробуйте скопировать несколько больших файлов одновременно

Пробовал, у меня никаких значимых нагрузок на CPU и тем более подивсаний нет.

Похоже и правда поймал полумифический 12309.

Ты ещё спроси как тёмную материю зарегистрировать :)

Если бы его было влегко гарантированно воспроизвести, давно бы пофиксили.

Летит самолет. Командир штурману:

• Штурман, приборы.
• Что 16?
• А что приборы?

Что за железо, ОС и fs

Бывало, DMA слетало и мы вертали. Руками.

Угу. CD/DVD, PATA, винда…

hdparm -i /dev/sdh

/dev/sdh:

 Model=Samsung SSD 860 EVO 1TB, FwRev=RVT01B6Q, SerialNo=S3Z8NB0JC02422N
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=unknown, MaxMultSect=1, MultSect=1
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1953525168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7

 * signifies the current active mode

пока писал - увидел *udma6

Вторая половина 90—х и была 30 лет назад.

Если бы его было влегко гарантированно воспроизвести, давно бы пофиксили.

Я про него столько лет читаю, а сам так ни разу и не видел. Обидно даже.

Та же хрень. Но, видимо, он при каком-то особом сочетании железа, версий дров и с особенности ФС проявляется. Только что общего у тех, кто его ловил — сложно сказать. ТСу бы свой комп какому-нибудь заинтересованному разработчику ядра задонатить, хотя бы временно. Самые противные баги как раз именно такие — которые никто из разработчиков не знает, как поймать, чтобы в итоге пофиксить.

[зануда-mode]30 лет назад было 1994 год — это первая половина 90-х, а не вторая.[/зануда-mode]

Я знаю. Ты сказал, что тогда его уже не было, а я утверждаю, что был. Только и всего.

УМВР
Винда кстати так от проблемы с IO и не избавилась со времён 98-й, сейчас это не так заметно потому что носители стали быстрые, но стоит поставить медленный ХДД и при каждом обращении винды к диску, а делает она это где то раз в 30 секунд хз зачем, будут подвисания

Я правильно плнял, что на оффтопике тоже 100%

Да нет, там всё очевидно, и как воспроизвести, тоже плюс-минус очевидно. Это вариация проблемы bufferbloat по отношению к локальному I/O. Просто всем пофиг, потому что на серверах гугла/фейсбука таких проблем нет.

Скопировал 100 GB файл из /dev/random, это заняло 2 минуты. нагрузка на CPU была в пределах 20%, система виснуть и подлагивать не начала, проседание мощности не почувствовал. Скопировал этот файл, это заняло полминуты, нагрузка на CPU была в пределах 10%, система виснуть и подлагивать не начала, проседание мощности не почувствовал. Когда файл скопировался, нагрузка на CPU осталась в пределах 10%, это, походу, ютуб грузил… Кажется на CPU заметной нагрузки при копировании вообще не было.

Это макось.

Объясните, пожалуйста, почему, копирование файлов на он\офф-топике занимает 100% CPU?

Железо? ОС? Вы же о них ничего не сказали.

Экстремиста ответ.

Ну да, на макоси нет 12309. Я по секрету скажу, раньше и на линуксе его не было, это регрессия.

На каких ядрах появилось? 2.6? 3?

Предполагаю что процесс копирования это не аппаратная штука, а сугубо программная с множеством однотипных операций, вот на это и расходуется вся «мощь» конвеера твоего CPU.

Мне казалось, что ещё во времена первых пентиумов изобрели DMA.

Что касается темы, то - не замечал. Возможно потому что 12 ядер, 24 потока и если одно нагружено даже на 70 будет, то не заметно. Попозже попробую какой нибудь io бенчмарк запустить и глянуть.

Если бы его было влегко гарантированно воспроизвести, давно бы пофиксили.

Лет 10 назад мог воспроизвести. У меня был архив с очень большим количеством мелких файлов, так вот если я его открывал в mc и пытался всё это копировать(распаковывать) на диск, то сначала начинала лагать мышь, потом клавиатура, а через минуту и вся система даже на REIUSB переставала реагировать.

btrfs

Ну всё понятно, это вот это вот это.

И попробуй копировать чере другой ФМ, хохмы ради.

С версии ядра 2.6 какого-то.

The bisect done by thomas.pi points yields a first bad commit dating from february 2007, while these symptoms first surfaced in 2.6.18, which dates from end 2006.

https://bugzilla.kernel.org/show_bug.cgi?id=12309#attach_19906

Мне казалось, что ещё во времена первых пентиумов изобрели DMA.

???
Чего? На Микроше с К580ВМ80А уже был прямой доступ к памяти. А это аналог Intel 8080A.

Ну я не говорю именно о изобретении, но на 486 системах сплошь и рядом IDE висело на PIO.

Вангую что это юзерспейс драйвер NTFS-3G, помню его, блин этож было 100 лет назад 15 лет назад. Ядро полностью утилизировал, и это при работе с обычным HDD с его скоростями, а теперь SSD тык что.

вот недавно копировал здоровенные файлы на оффтопике, видел только загрузку IO, процессор вообще ниче не делал