ls -l, но не ls --color = никогда не замедляется в смонтированном nfs каталоге, если одновременно выполняется запись в этот каталог

Question

когда я записываю данные в каталог, смонтированный по NFS, режимы чтения файлов (например, ls -l) на несколько порядков медленнее, чем простой список файлов (например, ls --color=never). Я хотел бы понять почему.

Если в этот каталог ничего не записывается, ls -l вернется почти сразу. Тем не менее, если я затем создам некоторый ввод-вывод с помощью, например, dd if=/dev/zero of=dd.img count=100M && rm dd.img , ls -l будет зависать до получаса , но ls --color=never или getdents возвращаются почти сразу. Другими словами, как только считываются режимы файлов, ls останавливается, но только если я одновременно пишу в один и тот же каталог. Я вижу это поведение в нескольких каталогах, смонтированных с различными параметрами NFS.

На клиенте запущен клиент CentOS 6.1 (версия ядра 2.6.32-358.2.1.el6.x86_64). Я не знаю, на каком сервере работает (какая-то частная высокопроизводительная система), и у меня нет прав администратора. Мой вопрос заключается в том, ожидается ли подобное поведение в определенных сценариях, и если да, то какие?

Большое спасибо,

Andreas

Answer 1

getdents и ls --color=never требуют только чтения каталога.  ls -l и ls --color=auto требуют чтения каталога и инодов, соответствующих всем записям каталога.  (ls -l , потому что он должен получить режим, количество ссылок, владельца, размер и дату изменения, потому что он отображает эти поля, и ls --color=auto , потому что ему нужно получить режим (и, возможно, количество ссылок и размер), поскольку он определяет цвет частично из типа файла (обычный файл, каталог, fifo, символическая ссылка и т. д.), возможности записи, исполняемости, setuid, setgid и фиксированного бита (и, возможно, количества и размера ссылки).)

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

Если в каталог ничего не записывается, ls -l вернется почти сразу.

Я подозреваю, что клиент NFS (часть вашей системы CentOS) спрашивает сервер NFS: «Что случилось?», А сервер отвечает: «Мне скучно.  Некоторое время здесь ничего не происходило.  Таким образом, клиент знает, что безопасно показывать вам кэшированную информацию.

Однако, если я создам (... файл ...), ls -l будет зависать до полминуты, ...

Клиент спрашивает: «Что случилось?», А сервер отвечает: «Здесь все изменилось».  Таким образом, клиент знает, что его кеш недействителен, и поэтому ему необходимо перечитать каталог и все inode (через сервер).  Это также будет верно для ls --color=auto .

... но ls --color=never или getdents возвращаются почти сразу. 

Поскольку этим командам не требуется информация о inode, единственное, что нужно перечитать, - это сам каталог, который занимает гораздо меньше времени.