Tráfico del Núcleo #125 For 9 Jul 2001

El Proyecto de Pruebas Linux es un proyecto de código abierto originado por SGI y recientemente adoptado por IBM y OSDL para proveer una colección de herramientas para probar el núcleo Linux, y Linux en general. El proyecto consiste en cerca de 100 casos de prueba individuales y un controlador de pruebas para automatizar la ejecución de las pruebas. Esta versión incluye muchas pruebas nuevas y actualizaciones.

• Cerca de 20 pruebas de confiabilidad de la red para llamadas a procedimientos remotos, sistemas de ficheros de red, multicast, y varios comandos de red.
• Un conjunto de pruebas de robustez que cubren pthreads, memoria, sistemas de ficherios y E/S de disco
• Varias pruebas para comandos utilizados comúnmente en ambiente de desarrollo de aplicaciones.

Puede descargar el Proyecto de Prueba Linux de SourceForge en http://sourceforge.net/projects/ltp. Para más información acerca del Proyecto de Prueba Linux, visite nuestro sitio web en http://ltp.sf.net.

IBM se complace en anunciar la liberación de la v 1.0.0 del sistema de ficheros de código abierto Journaled File System (JFS), un sistema de ficheros escalable, y de alto rendimiento para Linux.

http://oss.software.ibm.com/jfs

JFS es ampliamente reconocido como un sistema de ficheros de alto rendimiento líder en la industria, que provee una rápida recuperación de un corte de energía o una caída del sistema y la habilidad de dar soporte a configuraciones de discos extremadamente grandes. El JFS de código abierto está basado en tecnología de sistema de ficheros de jornada probada que está disponible en una variedad de sistemas operativos tales como AIX y OS/2.

JFS fue puesto como código abierto bajo la Licencia Pública General GPL con la versión 0.0.1 el 2 de Febrero de 2000 y ha madurado con ayuda y soporte de la comunidad de código abierto y su liberación "lista para la Industria" de hoy se debe al trabajo conjunto del equipo de JFS y la comunidad. Siguiendo el estilo de desarrollo de "Libera Temprano, Libera Seguido" el proyecto de código abierto JFS ha visto 37 versiones intermedias como parte del proceso.

El JFS de código abierto para Linux v 1.0.0 es liberado para el núcleo Linux 2.4.x y ofrece las siguientes características avanzadas:

• Rápida recuperación después de una caída del sistema o un corte de energía
• Jornada para integridad del sistema de ficheros
• Jornada de sólo meta-datos
• Alojamiento basado en extensión
• Excelente rendimiento en general
• Sistema de ficheros de 64 bit
• Construido para escalar. Las estructuras de datos en memoria y en disco están diseñadas para escalar más allá del límite práctico
• Diseñado para operar en hardware SMP y también un gran sistema de fichero para su estación de trabajo
• Completamente libre de cambios al núcleo como prerrequisito (fácil ruta de integración al árbol del código del núcleo)
• Documento "Cómo" detallado para crear un sistema con JFS como el sistema de fichero de /boot y /root usando lilo
• Conjunto completo de utilidades de sistema de fichero
• Compatibilidad en disco con sistemas de ficheros JFS de OS/2

El Equipo JFS (Barry Arndt, Steve Best, Dave Kleikamp)

Por lo que yo entiendo del correo de Linus a lkml, hay una diferencia entre JFS y XFS:

JFS no requiere ninguna modificación al código existente, es solamente una adición.

XFS al contrario es mucho más intrusivo.

Entonces parece que aún si JFS es menos completo que XFS (sin ACL, cuotas de disco por ejemplo), y aún si es menos robusto (no sé si lo es, solamente he usado hasta ahora XFS y ext3 -con éxito), su inclusión en el núcleo actual es mucho más fácil y no veo ninguna razón (técnica) para no incluirlo.

No pienso que ext3 tendrá dificultades para ser incluido en el núcleo porque a) las gentes que trabajan en él son veteranos de lk y b) Redhat (VA también) ya lo está incluyendo en sus núcleos (rawhide Y la actualización 7.1).

Así que espero que los chicos listos en SGI encuentren una forma de preparar los parches en la forma que Linus ama porque haroa el fichero "patch-2.4.5-xfs-1.0.1-core" (el cual contiene las modificaciones al núcleo y no los nuevos ficheros) es cerca de 174090 que es mucho.

Tú quisieras.

Excepto que no fue así.

Sigue la lista, y lee los mensajes que te cc:opié a tí.

pre2 estaba bien, pre3 no.

ac12 estaba bien, ac13 no. pre3 con pre2 page_launder estaba bien.

No hay preguntas sobre eso. El parche que causó problemas fue el que fue revertido. Por favor dejen de confundir el asunto.

Dije que -ac13 estaba mal, pero ac13 estaba de hecho ok. Fue ac14 el que fue el punto del problema.

También noten cómo Alan mezcló los parches MM en el orden inverso de las series preX: en las series -ac, el parche de Rik de page_launder() está en -ac14, mientras mis cambios de MV están mezclados en -ac15. En mis series, están en la otra forma: los míos estuvieron en -pre2, mientras que el de Rik entró en -pre3. En ambos casos, es la cosa de page_launder() que lo activa.

Y en el árbol -ac, no había alguna interacción con otros parches después de todo, y ac14 tiene el parche de page_launder() "puro" que fue revertido en -pre7.

Y para estar doblementes seguro, Tim <tcm@nac.net> también probó varios pre-núcleos y combinaciones no oficiales. Gracias.

Yo quisiera que tú tomaras NWFS si lo deseas. He disuelto TRG como una Corporación de Utah y ahora estoy enfocado en una variedad de proyectos para varios clientes relacionados a desarrollo de Linux. Novell ha amenazado recientemente de tratar de tomar mi casa y bienes si publico más versiones de NWFS o MANOS.

Me está yendo muy bien con mis proyectos de consultoría, pero para ser honesto, mi familia ha sufrido horriblemente en el pasado cuatro años peleando con Novell cada semana, y hay una gran oportunidad de que mude la tienda a Nuevo México o Arizona, ya que ellos poseen las cortes locales aquí en Utah (todos los jueces son mormones en el Valle de Utah y pro-Novell).

Hay varias áreas que necesitan reestructura y trabajo, y estoy disponible para resolver preguntas, y asistir con consultoría técnica, pero ya no puedo publicar más versiones de NWFS en Linux. Mis niños necesitan una casa sobre sus cabezas, y yo creo lo que Novell dice acerca de tomarla y ponernos en la calle. Están heridos en el mercado , y son muy peligrosos ahora, así que estoy tratando firmemente de estar fuera de su camino. Si escoges declinar, está para que lo tome cualquiera más que lo quiera tomar, pero tú tienes la primera opción.

Si eliges tomarlo, haré que mis abogados preparen un acuerdo transfiriéndote la propiedad legal. Yo retendré M2FS y las versiones en cluster, ya que tengo un cliente en el extranjero que quiere esta tecnología, y no utiliza ninguna tecnología específica de NetWare. También quisiera retener derechos de PI (Propiedad Intelectual) sobre NWFS para usar futuras encarnaciones en productos que deberé instalar en otro estado.

No quiero ver a NWFS caer por la borda y no obtener soporte, así que realmente me gustaría si estás dispuesto a tomarlo y lograr que sea limpio para 2.4.

Actualmente bajo Linux cuando un contexto es reciclado porque se necesita un nuevo contexto pero todos están en uso, nosotros básicamente desechamos todos los segmentos MMU que el contexto poseía.

Esto es ambiguo porque si los contextos son el recurso limitado de los mismos segmentos MMU, tomamos muchos elementos de MMU falsos en cada cambio de contexto por ninguna razón.

La solución es vincular las estructuras de estado de software de segmento MMU dentro de mm_struct. Cuando un 'mm' readquiera un contexto hw, si cualquier segmento MMU permanece en la lista de mm, tan sólo traerlo de regreso al MMU.

Parecía como que estabas reportando de nuevo símbolos de configuración de los cuales no pueden preguntarse al usuario - porque sólo están ahí como dependencias o como ifdefs en el código, más que como opciones seleccionables.

Después de más investigación, parece que yo estaba equivocado. Me disculpo por mi tono.

De hecho, parece que hay mucho de código MIPS que ha sido mezclado en -pre9, y esas opciones _son_ ahora seleccionables, más que solamente estar ahí como dependencias de algo de mi código.