Barrapunto

mientras me pongan todos los tipos de FileSystem que existen actualmente en el Kernel (JFS, ReiserFS, XFS, ext3, ext2, etc... ) y una opcion en el installer de la distro sobre cual filesystem quieres instalar por defecto, estoy la mar de contento. Creo que en la eleccion esta el exito, ya que dependiendo de a que tipo de servicio vas a hacer uso de tu ordenador (Workstation, Servidor de alto rendimiento, servidor de tipo medio-bajo, home PC, etc... ) cada filesystem rinde mejor o peor.

Solo pediria comparativas reales y oficiales sobre en que entornos son mejores cada filesystem y colgarlo como doc en el kernel para que el adm o usuario pueda saber cual instalar.

Una pregunta ... ¿Que creeis que le falta a nuestro Kernel para competir a pleno rendimiento? A parte de la revision del VM , claro esta ... :-)

Daniel

La gente de Microsoft puede decir lo que quiera, pero día a día se está convirtiendo en el sistema operativo con el abanico más amplio de opciones en muchos aspectos:

Sistemas de ficheros:
-JFS,Reiser,XFS,Ext2 (y si tienes ganas de aventura pues FAT) como locales
-NFS, SAMBA (algo hay de Novell ¿no?) para servidores de ficheros.

Escritorios:
-Gnome, Kde, WindowMaker, ICE (que cada cual ponga su preferido)

Y también en cuanto a servidores de web, ftp, correo electrónico.... Y sin atarnos (y pagando) a nadie; para mí: esos es libertad!!

El SMP en la serie 2.2 es probablemente el culpable, no JFS. La implementación de SMP en la serie 2.2 siempre tuvo sus problemas, y es una de las razones por las que se reescribieron bastantes cosas en la 2.4. Por otra parte, bienvenido sea JFS. Larga vida a la diversidad. Pero de momento seguiré con ext2, a pesar de sus deficiencias. Es uno de los motivos por los que linux ha llegado a ser lo que es.

En primer lugar, no lo he probado, eso por delante, lo que se es por segundas personas (que seguramente tampoco lo habían probado :P). Por lo que decían, las versiones anteriores a la 1.0.0 (0.3.5, etc, creo) eran mucho más lentas que RFS y XFS. Suponía que esto era porque faltaban muchas cosas por hacer, etc, por eso me ha sorprendido bastante ver la versión 1.0 hoy.
Cosas muy jodidas en JFS: no soporta RAID, al igual que ext3. Están en ello y tal, pero a día de hoy no sirve. Tampoco soporta LVM, más que nada porque IBM tiene su propia implementación de LVM (que hace poco liberó bajo GPL también).
Sobre todo por la segunda razón, para mí JFS no es una opción todavía. Y de todas maneras, con lo contentísimo que estoy con XFS, ya me tienen que pasar catástrofes para que cambie de FS. ReiserFS tampoco es una opción para mí (y ya se que la gente me contestará diciendo que "a mí no me ha pasado nada y tal) por la de veces que he presenciado a gente horrorizada porque se les había corrompido / y cosas así. ReiserFS está en pañales todavía, en cambio XFS tiene muchísimos años a sus espaldas en IRIX. En un servidor de la universidad usamos ext3 desde ni se sabe cuando sin ningún problema tampoco, sin duda es la opción para ya si quieres journaling y pasas de particionar y eso. Simplemente metes el journal y a correr.

Cuanta razon tienes! En realidad pienso que esa falta de seriedad no es solo para con Linux sino para cualquier cosa. En Informatica es muy facil ganar mucha pasta montando un chiringuito...

---

Ya he visto que hay gente externa trabajando, pero ¿alguien se atreve a estimar qué parte del trabajo se ha ahorrado IBM por haber abierto el código en vez de dejarlo solo a sus trabajadores?

Sobre lo que mencionas con reiserfs, puedo comentarte que lo he usado desde el kernel 2.4.2 (mas los parches correspondientes) sobre un raid 1 en Debian y no he tenido ningun problema. En algun comentario se menciona que ya se considera "estable" reiserfs en la 2.4.4.
Aunque si hubo problemas en la version 2.4.1

Una pregunta: ¿Estas usando xfs con el kernel mas reciente?

Sí, decía que los que tenían problemas con RAIDs eran JFS y ext3. Reiserfs siempre ha funcionado, no?
Uso el parche oficial, no el de CVS. Aparte de que 2.4.5 sucks a saco :)
Linux nubol 2.4.3-xfs #1 Thu May 24 13:52:48 CEST 2001 i686 unknown