Производительность и влияние частого использования du в btrfs
Я не думаю, что то, что я пытался сделать, возможно, если я свяжу вместе 2 grepкоманды (, поскольку строки контекста относятся к каждой отдельной grepкоманде ).
Мне пришло в голову, что мне нужен негативный просмотр вперед. Тогда все это можно было бы сделать с помощью одной команды grep.
К моему удивлению, похоже, что GNU grepдействительно поддерживает regex lookbehind/lookahead, но только если вы используете опцию --perl-regex.
Вот команда grep, которая дает мне то, что я искал:
⟫ grep --perl-regexp 'created_at(?!(.*precision:))' schema.rb -B3
create_table "things", id: :serial, force: :cascade do |t|
t.string "other_column"
#...
t.datetime "created_at"
From what I understand du uses stats which reads inodes infos which get cached in RAM. Is this correct? Or is it disk cache? Or both?
"кэшируется в оперативной памяти" :да, в некоторой степени. Не полностью, так как буферы файловой системы также потребляют оперативную память, а 100000 списков инодов/экстентов также нуждаются в оперативной памяти, поэтому «оба». («дисковый кеш» не имеет большого смысла :структура данных находится на -диске, так что это не кеш, это лежащие в основе данные ).
If the above is correct can I assume that running du frequently will:
- not affect negatively my system performance wise and
Вы не можете этого предположить. Даже если вся файловая система находится в ОЗУ, это все еще операция с интенсивным использованием данных, которая будет использовать как ЦП, так и ОЗУ и плохую ширину интерфейса диска.
not put unnecessary wear on the spindles? this might be a moot point but just humor me
Я никогда не видел износ шпинделя, так что, эм, нет? Кроме того, пока ваш жесткий диск используется, он вращается -, так что не совсем уверен, что этот вопрос хорошо продуман -!
I read of several tools which offer some kind of caching for du output but my objective is to catch differences so not sure they are relevant to the discussion.
Если вам нужны изменения, вы, вероятно, подходите к этому задом наперед. Тогда duвероятно не предпочтительный инструмент!
- вы могли бы использовать inotify, чтобы получать уведомления об изменениях в свойствах файла. Это меньше нагрузки, чем обход всей файловой системы только для того, чтобы внести несколько изменений!
duна btrfs обманет вас по поводу используемого хранилища . Btrfs умен — скопированные файлы не нуждаются в дополнительном хранилище, пока вы не запишете их, разреженные файловые области тоже не нуждаются, а понятие моментальных снимков и подтомов делает все это немного концептуально сложным.duпросто суммирует все размеры файлов. Не то же самое, что использование диска -!
Я предлагаю вам задать новый вопрос (в новом посте, а не в комментариях ), в котором вы подробно описываете проблему, которую пытаетесь решить с помощью du, и описываете свой текущий подход. Кажется, ваш вопрос здесь касается небольшого аспекта очень специфического подхода, и я не уверен, что этот подход решает вашу настоящую проблему!