Я анализирую влияние планирования запуска cron duдля нескольких больших папок (всего 10–20 ТБ файлов, количество файлов менее 100 000) каждый час.
Насколько я понимаю, duиспользует stats, который считывает информацию об инодах, которая кэшируется в оперативной памяти. Это правильно? Или это кэш диска? Или и то, и другое?
Если вышеизложенное верно, могу ли я предположить, что duчастые занятия бегом:
- не повлияет отрицательно на производительность моей системы и
- не вызывать ненужный износ шпинделей?это может быть спорным вопросом, но просто пошутите надо мной
Я читал о нескольких инструментах, которые предлагают своего рода кэширование duвыходных данных, но моя цель — выявить различия, поэтому не уверен, что они имеют отношение к обсуждению.
Большое спасибо!
решение1
Насколько я понимаю, du использует stats, который считывает информацию об inodes, которая кэшируется в RAM. Это правильно? Или это кэш диска? Или и то, и другое?
"кэшируется в ОЗУ": да, в какой-то степени. Не полностью, так как буферы файловой системы также потребляют ОЗУ, и 100000 списков инодов/экстентов также нуждаются в ОЗУ, так что "и то, и другое". ("дисковый кэш" не имеет особого смысла: структура данных находится на диске, так что это не кэш, это базовые данные).
Если вышеизложенное верно, могу ли я предположить, что частое использование du приведет к:
- не повлияет отрицательно на производительность моей системы и
Вы не можете этого предполагать. Даже если бы вся файловая система находилась в ОЗУ, это все равно была бы операция с интенсивным использованием данных, и она будет использовать как ЦП, так и ОЗУ и пропускную способность интерфейса диска.
не подвергать шпиндели ненужному износу? это может быть спорным вопросом, но просто пошутите надо мной
Я никогда не видел износа шпинделя, так что, эм, нет? Кроме того, пока ваш жесткий диск используется, он вращается - так что не совсем уверен, что этот вопрос хорошо продуман!
Я читал о нескольких инструментах, которые предлагают своего рода кэширование выходных данных du, но моя цель — выявить различия, поэтому не уверен, что они имеют отношение к обсуждению.
Если вы ищете перемен, то, вероятно, вы подходите к этому вопросу с другой стороны du.неттогда это инструмент по выбору!
- на самом деле вы могли бы использовать inotify для получения уведомлений об изменениях в свойствах файлов. Это меньше нагрузки, чем обход всей файловой системы, чтобы получить несколько изменений!
duна btrfsобманет вас относительно используемого хранилища. Btrfs умна — скопированные файлы не нуждаются в дополнительном хранилище, пока вы не запишете в них, разреженные области файлов тоже не нуждаются, а понятие снимков и подтомов делает все это немного сложным с концептуальной точки зрения.duпросто суммирует все размеры файлов. Не то же самое, чтоиспользование диска!
Я бы предложил вам задать новый вопрос (новый пост, а не в комментариях), в котором вы подробно описываете проблему, которую пытаетесь решить du, и описываете свой текущий подход. Ваш вопрос здесь, кажется, касается небольшого аспекта очень специфического подхода, и я не уверен, что этот подход решает вашу реальную проблему!