Barrapunto

Me he sorprendido al ver esto:
$ uname -rs

Linux 2.4.15-greased-turkey

A ver si mejora algo del Swap, aunque tal y como iba la pre7... :(.

A ver si hacen ya los tunning... :).

Salu2.

 

Veo en el README que el encargado de mantener la rama 2.4 es Marcelo Tosatti. ¿Significa esto un distanciamiento de Alan Cox en el desarrollo del kernel? ¿Seguirá desarrollando el kernel 2.4 siguiendo de cerca la batuta de Red Hat sin importarle lo que pueda diverger el kernel Cox/RH del stock kernel de Linus?

Pues supongo que según la gente se pase a 2.4.15 comenzará la migración masiva de ext2 a ext3 :)

Por suerte, podemos decidirlo nosotros mismos. :)
Aunque yo no crea que sea de esos. Prefiero la velocidad aunque suponga un poco de riesgo. ;)

prefiero xfs mucho mas fiable

Y eso que arboles si que hay.

Perdón por el chiste fácil...

Por +1 moderacion(cuando funcione): ¿Nombre de pila de Chaos 5º jinete del apocalipsis?

Menuda chorrada :-) Todo el mundo sabe que se llama Ronnie, o, si quieres más detalles, Ronald Soak, Lechero Higiénico (fundado).

¿Creías que eras el único que lee a Terry Pratchett? ;-)

Por cierto, alguna URL con documentación sobre como hacer la migración?

Saludos

En cuanto he compilado el kernel nuevo con soporte ext3, he cambiado mis particiones a ext3, siguiendo este mini-Howto.

Ningún problema, aumento del rendimiento, y además me olvido del molesto chequeo del disco que dura más que un día sin pan. Aunque todavía no es usable para servidores, por razones obvias, todavía le falta el sistema de quotas de disco y no está acabado ni mucho menos. Pero puedo adelantar que las primeras sensaciones son muy buenas.

¿Qué problema tiene el swap?

Solución larga y correcta: man tune2fs. Solución corta e incorrecta: tune2fs -j /dev/hdaX. Descripciones detalladas del proceso, en Internet.
 

La cosa es si es seguro. Tan sólo tengo que recordar las malas impresiones que me llevé con el reiser cuando propugnaban a voces que era ya definitivamente seguro (ya incluído en el kernel), el sistema de ficheros corrupto, etc... tan sólo tengo que recordarlo -un escalofrío- para que se me quiten las ganas de seguir pruebas caprichosas.

¿Qué opinión me das al respecto? ¿Se puede confiar? Hombre, viendo lo visto, pasar de ext2 a ext3 parece fácil, y si la ganancia de rendimiento la merece nada... pero claro, sólo me queda tender claro eso de la estabilidad.

Pero pasar a ext3 es trivial, y esto es una gran ventaja si quieres darle bitácora a 300 sistemas de ficheros :)

Perdona mi ignoraca ¿ pero que es ext ? ¿ que cambios hay que hacer para cambiarse a ext3 ? ¿ es algo obligatorio, esta en fase beta ? muchas gracias :)

Lo de Marcelo lo decidió Linus...

Alan ha dicho que va a estar un tiempo dedicandole más tiempo a cosas de Red Hat, que no dejará su trabajo en el Kernel pero que estará menos activo..

Yo parcheé el kernel 2.4.14 para meterle ext3 en cuanto me enteré de que se incluiría de forma oficial en el 2.4.15, me fiaba de él (sobre todo por lo de ser compatible con el ext2, hasta cierto punto era una garantía de que si pasaba algo se podría arreglar). He tenido la máquina funcionando tanto con ese kernel como con los 2.4.15 pre6 y pre8 (necesitaba el loopback, y el .14 no lo compilaba bien), y he tenido tantos problemas de corrupción y similares como con el ext2, o sea, ninguno ;-) En cuanto a rendimiento... no he hecho pruebas de ningún tipo, pero me parece que es más o menos similar, aunque ya digo que no tengo datos para afirmarlo.

ext3 es mas fiables que ext2,xfs,reiserfs y jfs.
hay un muy articulo en
IBM que lo explica muy clarito.
   

Toda la que quieras enext3 -2.4
Tambien hay una comparativa bastante real entre ext3 vs. reiserfs. Miradla y sorprendeos :-)

Bueno, eso seria entonces, las versiones actuales funcionan bastante bien, yo estoy usando una version parcheada de un 2.2.17 y no me falla en absoluto (estoy bajandome ya el 2.5.0 jejeje).

Ya he pasado mis discos a ext3 con 2.4.15 ;)

Problema: "Subject: 2.4.15 problem: deleted inodes still present in ext2 directories after shutdown"

Razón: "Sigh... Supposed fix to problems with stale inodes was completely broken (2.4.15-pre9 y 2.4.15)

Solución:

Subject: Re: 2.4.15 + fs corruption.

From: Alexander Viro

Date: Fri, 23 Nov 2001 17:56:43 -0500 (EST)

Return-Path:

Delivered-To: jdomingo@localhost

Delivered-To: jldomingo@softhome.net

X-Authentication-Warning: weyl.math.psu.edu: viro owned process doing -bs

To: war

cc: linux-kernel@vger.kernel.org

In-Reply-To:

Sender: linux-kernel-owner@vger.kernel.org

Precedence: bulk

X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 23 Nov 2001, war wrote:

> Is 2.4.15 ok to use?

> Many people are experiencing filesystem corruption?

>

> As long as you patch the kernel with Al Viro's patch it should be ok,

> right?

In theory. Again, as a workaround - sync before umount (and don't boot

unpatched 2.4.15/2.4.15-pre9 again, obviously).

Breakage happens when you umount filesystem (_any_ local filesystem, be

it ext2, reiserfs, whatever) that still has dirty inodes.

IOW, if you are running 2.4.15 - build a patched kernel, install it and

do the following:

                * switch to single-user

                * sync

                * umount everything non-buys

                * remount the rest read-only

                * turn the thing off

                * boot with patched kernel or with anything before 2.4.15-pre9

-

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at http://vger.kernel.org/majordomo-info.html

Please read the FAQ at http://www.tux.org/lkml/

 

Ver el correo con el parche propuesto, de momento (01:00 AM hora peninsular española) nadie se ha quejado de él (no les ha dado tiempo ;).
 

Finalmente me he decidido: la transición, limpia, no traumática y feliz. Estoy comprobando ahora el rendidimiento (habrá que meterle algo de caña) y tras unos días, comprobar que todo no se ha ido al garete... Gracias a todos.

En mi caso ya es tarde: lo he instalado y me ha sucedido lo indicado. Tampoco ha sido muy grave, con el mc me he cepillado un fichero que supuestamente se había borrado y al transformar la partición ext2 a ext3 se han borrado más inodos de esos.

Lo que encuentro grave es que el fsck no detecte nada raro. Esperemos que saquen un pre rápido que arregle el bug, pero entonces me queda una duda con los parches del kernel. Cuando aplico el parche para pasar de una versión a la siguiente ¿pueden haberse aplicado los parches pre1 pre2...? ¿o debe estar el kernel limpio de porlvo y paja? es más ¿si aplico el parche propuesto para solucionar el bug podré luego aplicar el parche para pasar al 2.4.16 sin problemas? ¿hay algún problema al desaplicar un parche del kernel (pach -p0 -R)?

Pero hasta que no pase un tiempo ext3 lo tendre considerado como 'preproduccion' , xfs ha demostrado empiricamente en mis servidores que va muy bien solo porque ext3 se haga estable y parezca mejor hay que lanzarse sobre el a instalarlo.

OT: mcocoa +1 adjudicado, pero debe merecerlo.