Linux :Замена большими кусками
Это может случиться с различными программами, например, однажды у меня было такое поведение, когда я просто использовал 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 вы можете отлаживать ее на уровне пользовательского пространства: