Если хотите, можете поместить файлы в каталог
/opt/location/source
/0001g.log
/0002g.log
/0003g.log
Затем в своем сценарии bash вы можете попробовать следующий
#!/bin/bash
# store path to files
SOURCE="/opt/location/source/"
# loop through files
for FILE in `ls $SOURCE*g.log`; do
# do what you want to specific file
echo $FILE
done
/proc
io
отслеживает только «явный» ввод-вывод, , то есть ввод-вывод, выполняемый с использованием небольшого количества системных вызовов. Для чтения это read
, readv
, preadv
, sendfile
и copy_file_range
; вы можете увидеть статистику, накопленную с помощьюadd_rchar
в fs/read_write.c
.
Ввод-вывод для отображаемых файлов памяти -совершенно другой; при чтении используется обработка ошибок страницы -с рядом оптимизаций для повышения производительности (опережающее чтение -и т. д. )Вы можете отследить это до некоторой степени, просмотрев ошибки страницы в/proc/${pid}/stat
(поля 10 и 12 ). Трудная часть — выяснить, сколько данных считывается при каждой ошибке страницы; мои эксперименты предполагают 64 КБ на ошибку, но я не нашел достоверных данных, подтверждающих это (, и, вероятно, это зависит от обстоятельств ).
Я не знаю ни одного готового ---способа отслеживания отображенного ввода-вывода с точки зрения процесса (, т.е. байтов, считанных в процесс, независимо от того, любой блочный ввод-вывод действительно имел место ).
Учет точного -отображенного чтения памяти оказывается довольно сложной проблемой,главным образом из-за того, как бухгалтерский учет должен отражать намерение. io
подсчитывает байты, которые программа явно попросила прочитать или записать; но когда процесс отображает файл в свою память, чтение происходит с точностью, определяемой ядром, а не процессом чтения. Вы можете прочитать только один байт каждые 4 КБ, а ядро прочитает за вас весь файл — что должен отражать учет? Он не может легко отражать байты, действительно прочитанные в памяти процессом, что оказало бы огромное влияние на производительность (помимо того, что его невозможно реализовать во всех архитектурах ).