Rafa Grimán escribió:
No estoy muy de acuerdo con esto. Nosotros tenemos clientes con más de 60 millones de ficheros en un filesystem y, concretamente, tenemos un cliente en España con más de 40 mil ficheros en un directorio y no hemos visto este tipo de limitaciones.
Un ejemplo más casero es el que hice anoche, borrar 22 GB con más de 130 mil ficheros repartidos en 5 directorios. Antes de borrarlo, pude usar el comando find concretamente un find /mnt/xfsdumps -type f -exec chmod 0640 {} \;
(recordemos que hablo de más de 130 mil ficheros) y no tuve problemas de shell, buffers, ... Es un AMD 1333 con 1.5 GB de RAM. También usé otros comandos: ls, rsync, ... y pude usar konqueror (desde KDE ;) y no tuve problemas.
Hay veces que el buffer se te puede llenar y hay comandos que no se ejecutan al 100%, para lo cual necesitarías usar:
comando largo | xargs comando2
Yo creo que es más bien un problema de velocidad de disco duro.
¿Qué filesystem estás usando? Algunos no pueden trabajar con muchos ficheros.
ReiserFS
Esta era la raz�n por la que el "konqueror" me hab�a bloqueado la maquina, queria acceder al "tmp" y tenia problemas para listar o escribir en el. La soluci�n fue borrar el directorio "tmp" y volver a crear otro con los mismos permisos.
Antes has dicho que no podías borrar el contenido, ahora dices que sí ... hacer un:
cd /tmp && rm -Rf YaST-*
es lo mismo (aunque menos peligroso) que:
rm -Rf /tmp
No. Digo que pude borrar el directorio. Me explico Y tanto que no es lo mismo. rm -rf YasT-* al poner asterisco al comando rm, la bash expande o cambia el asterisco por todo el conjunto de ficheros, el string resultante no lo acepta el comando rm. Hacer un rm /tmp lo unico que se elimina es la entrada de este directorio, fijate que es un momento en borrar-lo. Puedes provarlo si quieres y veras que tengo razon. create un directorio y ejecuta este escript for i in `seq -f%8g 1 14170|tr -t " " "0"`; do mkdir $i done esto te creara 14170 directorios de 8 caracteres dentro del directorio que has creado si ejecutas: echo * | wc -c veras que son 127530 bytes prueba desde dentro del directorio de hacer: rm -rf * y obtendras: -bash: /bin/rm: La lista de argumentos es demasiado larga Eso quiere decir que el comando rm -rf al subtituir el * por los nombres sobrepasa el limite Si tan solo borras un fichero rm -r 00014170/ veras que ya puedes ejecutar el rm -rf * Puedes provar de aumentar mas el numero de directorios, el rm no puede borrar-los pero si que puedes borrar el directorio principal Ya sabemos que con el find se puede hacer. Pero mira el error que lanza la hacer: find -type d -exec rm -rf {} \; find: ./00014167: No existe el fichero o el directorio find: ./00014168: No existe el fichero o el directorio find: ./00014169: No existe el fichero o el directorio find: ./00014170: No existe el fichero o el directorio Pero los borra todos.
Yo lo he probado en otra maquina y tambi�n estaba igual y esta ma�ana lo he vuelto a hacer y tambi�n. Sucede de esta forma.
1 - Desde las "X", abrir el "YasT" 2 - Seleccionar "Actualizaci�n en linea" 3 - Una vez abierta la ventana cerrad la anterior, la principal del "YasT". 4 - Comenzad una actualizaci�n y la cancel�is antes de que acabe. 5 - Id a ver vuestro /tmp, se van creando directorios del tipo "YaST2-08607-eXyBxe" Como matarlos: 6 - Como "root" moved el "tmp", el proceso que crea los directorios ya no podr� escribir en el. (ej: mv tmp tmpOLD) 7 - Buscad el proceso con: "ps axft" 8585 ? S 0:00 /bin/bash /sbin/yast2 online_update 8719 ? R 0:00 \_ /usr/lib/YaST2/bin/y2base online_update qt vereis que el hijo va cambiando de PID. Bien, matemos al padre (kill -9 8585) 8 - Borrad los directorios de "tmpOLD" que no se habr�n creado muchos y volved a mover "tmpOLD" a "tmp".
Hay una solución más sencilla, edita el fichero:
/etc/sysconfig/cron
Y pon lo siguiente:
MAX_DAYS_IN_TMP="1" MAX_DAYS_IN_LONG_TMP="1" TMP_DIRS_TO_CLEAR="/tmp /var/tmp" LONG_TMP_DIRS_TO_CLEAR="/tmp /var/tmp" CLEAR_TMP_DIRS_AT_BOOTUP="yes"
Y luego ejecuta:
SuSEconfig
Cada vez que reinicies el SUSE, se borrará el directorio /tmp y el /var/tmp.
A ver si alguien con la 10.1 puede probarlo y confirmar-me de este gran bug.!!!. Programas coma las "X" y otros, escriben ficheros y directorios en "tmp", si existe este colapso de directorios puede que el sistema o algunos programas se vuelvan inestables.
No, lo que puede ocurrir es que al mover el /tmp las X y OOo dejen de funcionar porque crean en /tmp sockets y symlinks que usan en tiempo de ejecución. Pero este problema se debe a que se ha movido /tmp, no a que YaST2 cree ficheros temporales.
El tmp lo movi solamente para poder matar el proceso padre ya que el hijo iba cambiando de PID