Как вы предотвращаете кеширование find, du, ls -R?

Question

В настоящее время я копирую большое количество файлов по сети. Чтобы следить за прогрессом, я пробовал запустить watch du . Однако вывод никогда не менялся (или не сильно, не уверен). find . -type f | wc -l всегда дает мне то же количество файлов, что и ls -R .

Кажется, что эти программы используют кеширование, что, в общем, хорошо. Кто-нибудь знает, однако, как можно контролировать использование кэша?

Я работаю в системе Archlinux и работаю над ext4 fs на зашифрованном жестком диске.

Спасибо

Answer 1

Ls и друзья не кешируют свои результаты. Вместо этого я подозреваю, что вывод du просто медленно меняется. (Из-за того, как ваше программное обеспечение для передачи воспроизводится с открытыми дескрипторами файлов) Вы также можете попробовать полностью удалить кеш файловой системы, хотя я не думаю, что здесь это имеет большой смысл: echo 1 | sudo tee /proc/sys/vm/drop_caches

Чтобы лучше отслеживать ход выполнения, вы должны использовать rsync для передачи и установить для него флаг -P, что позволяет печатать прогресс в стандартном выводе.

Answer 2

Кэширование, на которое вы ссылаетесь, находится не в пользовательском пространстве; это индекс ядра Linux и кэш-память. Вы можете контролировать скорость, с которой ядро освобождает память, используемую в этом кэше, изменяя параметр sysctl vm.vfs_cache_pressure . Эта статья предложила значение 10000. Что касается самого кеша Linux, я не могу дать вам однозначного ответа, но, скорее всего, это не проблема.

Кроме того, unbuffer предназначен для буферизации (небуферизованной, блочной или строковой буферизации) стандартных потоков. Скорее всего (но не обязательно) здесь не уместно, если только вы не передаете тарболы по сети и не распаковываете их локально, или перенаправляете выходные данные процесса, подключенного к сети, в файловую систему. Тем не менее, это не должно иметь значения, если эти программы не используют блочную буферизацию с огромным размером или строковую буферизацию для двоичных данных, и вам не повезло, что в ваших данных не было ни одного 0x0d или 0x0a для сколь угодно большого количества данных. Кроме того, это кэширование является библиотечной функцией, а не функцией ядра или программы. Последний может устанавливать параметры.

Netstat также просто перечислит выдающиеся сетевые соединения, а не то, что там происходит.

Вы можете попробовать strace -e trace=file fileing процесса, чтобы увидеть, что он делает.

Answer 3

Вы можете попробовать скрипт unbuffer который идет с expect.

Вот CVS-представление самого сценария отмены буфера . Обманчиво просто.

Еще одна опция для мониторинга передачи данных - pv.

Answer 4

Не уверен насчет кеширования.

Но я уверен, что вы не получите неправильные данные в любое время. Пожалуйста, перепроверьте, что вы делаете. Во всех случаях эти find и ls дали мне очень правильные данные, даже при передаче тонны файлов.

Answer 5

(Контекст) Я использую среду Docker / SilverStripe и часто сталкиваюсь с этим исключением, когда пытаюсь вызвать http://example.com/dev/build/?flush=all (который перестраивает базу данных и очищает кэш).

rm: cannot remove '.nfs00000001004173880000002c': Device or resource busy

Я узнал, что могу перейти к этому каталогу в терминале (вне Docker) и удалить файл вручную. Но повторное выполнение этого приводит меня к той же самой проблеме кэширования, где ls -hal покажет мне пустой каталог, даже если файл существует (и не может быть удален).

Короче говоря: в моем случае я могу использовать cd . обновить терминал… или удалить его кеш или что-то еще.

Answer 6

Для мониторинга активности вы можете использовать iotop в сочетании с bwm-ng. iotop, как следует из названия, контролирует ввод / вывод. bwm-ng контролирует сетевые интерфейсы.

Если вы хотите более «сырой» подход, просто посмотрите на цифры в /proc /net /dev

Оба вышеупомянутых инструмента доступны на AUR, так как вы упомянули, что являетесь пользователем ArchLinux.