Linux Mejor filesystem para....

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.872
Raro. Una vez tuve un problema de archivos chicos que hizo que llegase al límite de inodes, pero me bastó poner un cronetab para borrar archivos antiguos y problema solucionado.
Puta, lo más bakán del mundo para mi es ext4, pero se ve que no es suficiente para ti. Sorry por mi post de no-ayuda.
 

BestRoV3r

[BestRoVer]
Se incorporó
23 Marzo 2009
Mensajes
190
[OT] la wea bkn.... todas las leyendas posteando :'D esto si es Chw weonohhh

Enviado desde mi HUAWEI Y300-0151 usando Tapatalk 2
 
Upvote 0

Miguelwill

I am online
Miembro del Equipo
MOD
Se incorporó
23 Febrero 2004
Mensajes
12.403
en mi caso probaria primero, despues de haber probado con ext4, con XFS, tiene el almacenamiento de bloques dividido por grupos, por lo que una lectura en una parte del FS no le afectara a los otros, junto con eso permite multiproceso en el acceso al FS, y creo que tambien tenia ventajas al usar muchos archivos chicos o varios archivos exageradamente grandes
lo uso como FS principal en almacenamientos con miles de archivos y nunca me dio mayores problemas.
XFS - Wikipedia, la enciclopedia libre

saludos
 
Upvote 0

Amenadiel

Ille qui nos omnes servabit
Fundador
OVERLORD
REPORTERO
Se incorporó
15 Enero 2004
Mensajes
18.398
Vikingo: cuando inicializas un disco o partición con

Código:
mkfs.ext4

Existe el parámetro -i para definir la tasa de bytes por inode. Por defecto son 16384. Eso puedes verlo en /etc/mke2fs.conf

Código:
[defaults]
        base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr
        default_mntopts = acl,user_xattr
        enable_periodic_fsck = 0
        blocksize = 4096
        inode_size = 256
        inode_ratio = 16384

si usas un valor menor (con un mínimo de 4096, que es el blocksize) tendrás espacio para más inodes.

Deduzco que no tienes cómo cambiar el disco en forma rápida o añadir un segundo disco para paralelizar el problema. Pero eso sí, no hay cómo cambiar el inode_ratio sin reparticionar. Sorry :dalomismo

PD1: ¿Ese Jenkins es el robot de integración continua?

PD2: ¿Cómo estás haciendo para borrar archivos? En mi experiencia, para borrar archivos de más de 10 días podrías usar el comando

Código:
find -mtime +10 -exec rm {}\;

Pero esto es muy ineficiente. Pipear la salida a xargs es varios órdenes de magnitud más rápido

Código:
find -mtime +10 | xargs rm


PD: me apesta este editor, estaba acostumbrado a escribir en markdown.
 
Upvote 0

Kensho

Buscando el norte
Se incorporó
16 Agosto 2006
Mensajes
1.475
busca un fs con asignación automática de inodos y estrésalo

un cron de eliminacion de temporales también ayudaría.

El jenkins maldito que manejo crea muchos temporales al hacer polling a un control de versiones, me llena 400mb de "nada" (muchos archivos que sumados no pesan ni 100k) en 2 días. (pasamos de cvs a git, y como con github se hace callback, el problema desapareció solo)


si además tienes uso excesivo de cpu en construciones de jenkins puedes evaluar distribuirlo.
 
Upvote 0

unreal4u

I solve problems.
Miembro del Equipo
ADMIN
Se incorporó
2 Octubre 2005
Mensajes
13.601
busca un fs con asignación automática de inodos y estrésalo

un cron de eliminacion de temporales también ayudaría.

El jenkins maldito que manejo crea muchos temporales al hacer polling a un control de versiones, me llena 400mb de "nada" (muchos archivos que sumados no pesan ni 100k) en 2 días. (pasamos de cvs a git, y como con github se hace callback, el problema desapareció solo)


si además tienes uso excesivo de cpu en construciones de jenkins puedes evaluar distribuirlo.

ah cresta jajajaj

nosotros ya ocupamos git (con gitolite), y con el hook post-push (no es ese, pero es cuando lo hace) así que con eso le avisamos a Jenkins de que tiene que hacer los tests, que no es nada más que un wget -q jenkins-url:repository . Con eso empieza un nuevo job.

Creo que todavía tenemos unos cuantos gigas de disco dando vueltas en el hosting, así que voi a montarlo e ir probando distintas configuraciones, symlinks FTW! xD
 
Upvote 0

yakko

pingüino mal genio
Se incorporó
24 Agosto 2004
Mensajes
16.883
wifekillerFS anda bien con hartos inodos, pero está un poco abandonado me parece, igual podrías probarlo.

si ext4 te anda bien puedes hacer lo que dice amenadiel y cambiar la cantidad de ínodos al momento del formateo, afecta un poquito el performance, pero nada significativo.
 
Upvote 0

Amenadiel

Ille qui nos omnes servabit
Fundador
OVERLORD
REPORTERO
Se incorporó
15 Enero 2004
Mensajes
18.398
WifeKillerFS por el puro nombre creo que voy a probarlo.
 
Upvote 0

bighead

Cabro Cooleao
Se incorporó
25 Noviembre 2006
Mensajes
3.088
ReiserFS. El otro es UFS2, la escritura inicial es rápida, pero Linux "out of the box" no lo soporta, eso si, la consolidación (el cierre) es más lento que la ctm (pero eso a nadie le importa si es que la máquina no la apagas nunca). Aún así, va haciendo un "soft-update" que sincroniza parcialmente para que el riesgo de pérdida sea menor, y el sync se hace sin sacrificar rendimiento. También tiene "block reallocation" que es hecho por el mismo sistema del soft update y hace que la fragmentación sea casi inexistente (por experiencia, tiende a "fallar" con escritura de archivos MUY grandes). De forma nativa lo ocupan actualmente la mayoría de los unices, FreeBSD y solaris incluido.
 
Última modificación:
Upvote 0

unreal4u

I solve problems.
Miembro del Equipo
ADMIN
Se incorporó
2 Octubre 2005
Mensajes
13.601
wifekillerFS anda bien con hartos inodos, pero está un poco abandonado me parece, igual podrías probarlo.

si ext4 te anda bien puedes hacer lo que dice amenadiel y cambiar la cantidad de ínodos al momento del formateo, afecta un poquito el performance, pero nada significativo.

xDD había leído algo hace un tiempo atrás, pero no tenía idea que le decían así

ReiserFS. El otro es UFS2, la escritura inicial es rápida, pero Linux "out of the box" no lo soporta, eso si, la consolidación (el cierre) es más lento que la ctm (pero eso a nadie le importa si es que la máquina no la apagas nunca). Aún así, va haciendo un "soft-update" que sincroniza parcialmente para que el riesgo de pérdida sea menor, y el sync se hace sin sacrificar rendimiento. También tiene "block reallocation" que es hecho por el mismo sistema del soft update y hace que la fragmentación sea casi inexistente (por experiencia, tiende a "fallar" con escritura de archivos MUY grandes). De forma nativa lo ocupan actualmente la mayoría de los unices, FreeBSD y solaris incluido.

Tb lo evaluaré, gracias!

Saludos.
 
Upvote 0

Amenadiel

Ille qui nos omnes servabit
Fundador
OVERLORD
REPORTERO
Se incorporó
15 Enero 2004
Mensajes
18.398
es reiserFS, se le dice así porque el creador y mantenedor mató a su señora y ahora está precioso.
ahora tiene sólo soporte "interno" :zippy

Aah, puta que soy lento, no había caído.

Conozco ReiserFS. Lindo en el papel, pero ya no fue.
 
Upvote 0

unreal4u

I solve problems.
Miembro del Equipo
ADMIN
Se incorporó
2 Octubre 2005
Mensajes
13.601
Ya cabros, les cuento el final de la historia:

Al final arrendamos un server chancho en otro lado, así que serán 2 nodos no más. El master actual quedará como esclavo en caso de emergencia.

El nuevo master guardará todo en una partición dedicada (80GB para empezar) con btrfs, lo probamos y es LA RAJA de rápido! Un "du -sh" en el ext4 se demora tanto que ni siquiera he esperado a que termine. En el btrfs es casi instantáneo :inlove

ReiserFS no se quiso instalar pq está demasiado viejo ya. Había que instalar muchas weas para echarlo a andar y además btrfs es más nuevo, ya viene listo e incorporado con Centos 7, y además, la primera regla de Barney Stinson dice que "Todo lo nuevo es mejor" :p

También habíamos visto la posibilidad de que guardara todo en base de datos, pero no existe ningún plugin que haga la pega de forma bbb, así que volvimos a ver filesystem.

Mañana hacemos el traspaso oficial :zippyuy

Saludos.
 
Upvote 0

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.872
Que buen experiencia.
Entonces btrfs es la evolución natural de ext4 para todo uso? O es solo para cosas específicas?
 
Upvote 0

unreal4u

I solve problems.
Miembro del Equipo
ADMIN
Se incorporó
2 Octubre 2005
Mensajes
13.601
Por alguna razón, CentOS 7 instala XFS como FS predeterminado en vez de ext4. Sin embargo, es sabido que XFS no trabaja de forma muy rápida cuando son muchos archivos chicos, así que por esa razón me quería cambiar. Fuera de ese caso extremo, XFS debería trabajar de forma más robusta que ext4.

Por lo que he podido investigar, XFS que es de SUN y que apareció aprox. en 1994 es más sólido y robusto que ext4, siendo este último más rápido eso sí. btrFS viene a ser un FS nuevo, orientado desde el principio a weas cabronas y no como ext3+ que en realidad "hackeó" el concepto de journaling en su sistema, ya que no estaba presente en ext2 si mal no me acuerdo.

Por eso mismo, se supone que es mucho más rápido ya que muchas cosas ya vienen listas desde el core mismo. A su vez, tb debería ser mucho más confiable que cualquier otro sistema, lo que creo que están logrando ya que de lo contrario no vendría el driver de forma predeterminada en el setup mínimo de CentOS (Y probablemente Red Hat tb).

Veamos en unos 2 meses más cuando tenga por lo bajo unos 4 millones de archivos cómo se porta.

Saludos.
 
Upvote 0

unreal4u

I solve problems.
Miembro del Equipo
ADMIN
Se incorporó
2 Octubre 2005
Mensajes
13.601
PD: Ahora que estoy sincronizando todo, puedo dar mejores estadísticas.

Con aprox. 663869 archivos copiados
Código:
ls -1R | wc -l
(y sumando, ya que estoy ejecutando el rsync en otra ventana) se demora 19 segundos en calcular el peso total de esa carpeta (du -sh) que es de (hasta el momento) 3.8GiB.

Por cachativa, la carpeta debería pesar unos 10GiB, mañana vamos a ver.

Saludos.
 
Upvote 0

Miguelwill

I am online
Miembro del Equipo
MOD
Se incorporó
23 Febrero 2004
Mensajes
12.403
a esa velocidad de copia ya debería de haber terminado hace rato xD

sobre lo que comentabas , por eso prefiero xfs por lo menos en almacenamiento común , y ahora que estoy usando imágenes raw para quemu/kvm se siente que el rendimiento es bastante mejor que manejar miles de archivos chicos (correos, paginas web, so's completos )

cuando me toco ver directorios con varios teras de archivos PDF, por lo menos con find pide leer rápidamente la lista de archivos ,ya que en los FS comunes siempre se suele marear ls o du cuando la cantidad de archivos es de varios miles .

sobre robustez, en xfs nunca e tenido problemas de particiones con errores o que me pida correr el checkeo manual al arrancar (eso por sus funciones de recuperación automática y almacenamiento en grupos )

saludos

Enviado desde mi Moto [XXX ] con KK
 
Upvote 0
Subir