¿Por qué el comando Ls tarda en interrumpirse en el directorio Nfs con muchos archivos?

Lo noté en directorios con muchos archivos en NFS si lo hago

ls *

luego presione Ctrl-C, puede tomar un tiempo (digamos 20 segundos) antes de que ls regrese.

¿Por qué? ¿Se puede arreglar el comando ls para que responda mejor?

Respuesta aceptada:

Cuando ejecutas ls * , lo primero que sucede es que el shell obtiene un listado del directorio actual. Si el directorio es enorme y el servidor es lento, esto podría llevar un tiempo.

Una vez que el shell ha obtenido la lista de nombres de archivos en el directorio actual, ordena esa lista (que es muy rápido en comparación con cualquier interacción de red), luego llama a ls . Los ls El comando busca cada archivo por turno y recupera sus metadatos (stat call) para comprobar si se trata de un directorio; si un archivo es un directorio, ls enumera su contenido en lugar del directorio en sí.

Cuando presiona Ctrl +C , esto no interrumpirá la operación NFS actual. No puede interrumpir una operación del sistema de archivos en cualquier lugar, ya que esto podría dejar el sistema en un estado inconsistente. Incluso leer un archivo puede actualizar su tiempo de acceso. La mayoría de las veces, una operación elemental de lectura o escritura en un archivo es instantánea según los estándares humanos, pero NFS es una excepción, especialmente con grandes cantidades de datos en una red lenta.

Así presionando Ctrl +C solo surtirá efecto:

• si el shell está generando actualmente la lista de nombres de archivo, cuando esa lista se recupere por completo;
• si ls se ha iniciado y actualmente está obteniendo metadatos sobre un archivo, cuando el servidor proporciona los metadatos;
• si ls se ha iniciado y actualmente está enumerando un directorio, cuando la lista se recupera por completo, o al menos después de una parte de ella.

No es culpa de los ls comando (que puede que ni siquiera se haya iniciado todavía). Ni siquiera es culpa del shell:es culpa de NFS. NFS es bastante lento.