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

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

Если ничего не пишется в этот каталог ls -l вернется почти сразу. Тем не менее, если я тогда создаю некоторые IO с, например, 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

Источник

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, единственное, что нужно перечитать, - это сам каталог, который занимает гораздо меньше времени.

Источник
Другие вопросы по тегам