Это может случиться с различными программами, например, однажды у меня было такое поведение, когда я просто использовал cp file /dev/null
; вместо того, чтобы получить оценку скорости чтения моего диска, команда вернулась через несколько миллисекунд.
Насколько я помню, это было на Solaris или AIX, но принцип применим ко всем видам unix -y систем.
В прежние времена, когда программа куда-то копировала файл, она чередовалась между вызовами read
, получающими какие-то данные с диска (, или вызовами, на которые ссылается файловый дескриптор ), в память (. ] с гарантией все есть, когда read
возвращает )и write
вызывает (, которые берут кусок памяти и отправляют содержимое по назначению ).
Однако есть как минимум два более новых способа добиться того же самого:
Linux имеет системные вызовы copy_file_range
(, вообще не переносимые на другие Unix )иsendfile
(в некоторой степени переносимые; изначально предназначался для отправки файла в сеть, но теперь может использовать любое место назначения ). Они предназначены для оптимизации трансферов; если программа использует один из них, вполне возможно, что ядро распознает цель как /dev/null
и превращает системный вызов в операцию no -
Программы могут использовать mmap
для получения содержимого файла вместо read
, это в основном означает «убедиться, что данные есть, когда я пытаюсь получить доступ к этому фрагменту памяти» вместо «убедиться, что данные есть, когда системный вызов возвращается". Таким образом, программа может mmap
исходный файл, а затем вызвать write
для этого куска отображаемой памяти. Однако, поскольку запись /dev/null
не требует доступа к записанным данным, условие «убедитесь, что оно есть» никогда не срабатывает, в результате чего файл также не читается.
Не уверен, использует ли gnu tar какой-либо и какой из этих двух механизмов, когда он обнаруживает, что пишет в /dev/null
, но они являются причиной того, что любая программа, при использовании для проверки скорости чтения -,следует запускать с | cat > /dev/null
вместо> /dev/null
-и почему | cat > /dev/null
следует избегать во всех остальных случаях.
Нет. Это невозможно.
Ядро Linux решает с помощью различных алгоритмов об ОЗУ, пространствах подкачки, последнем использованном местоположении подкачки, отклике дискового кэша, подкачке и других вещах, когда и как использовать выделение памяти подкачки.
Система не может просто ждать, чтобы получить «коллекцию страниц 10 МБ>», поскольку управление памятью осуществляется -по запросу, чтобы избежать зависания системы и остановки процессов.
Тем не менее, в течение многих лет сообщалось о некоторых ошибках, связанных с ОЗУ и управлением подкачкой, из-за очень плохой производительности, когда система начинает подкачку.
Я могу сказать вам, что использование диска можно улучшить с помощью zswap, потому что самая большая проблема здесь заключается в экспоненциальном умножении страниц при поступлении подкачки (из-за связывания страниц памяти ).
zswap сжимает это умножение, уменьшая количество операций чтения/записи на диск и может оказать заметное влияние на использование вашего ЦП.
Zswap управляется -ядром, и у вас есть много полезных -низкоуровневых конфигураций, позволяющих адаптировать его к потребностям вашей системы.
https://www.maketecheasier.com/use-zswap-improve-old-linux-performance/
Хороший вопрос. это зависит от типа файловой системы, которую вы монтируете. Я думаю, что это связано с пространством ядра, но погуглив я обнаружил, что в файловой системе xfs вы можете отлаживать ее на уровне пользовательского пространства: