Portada
mis comunidades
otras secciones
#9:
Lástima que ni se tenga en cuenta a Reiser4. Tiene unos "killer features" muy buenos
#37:
En SLES 11 ni siquiera había soporte correcto para EXT4 y ahora van en el 12 y se saltan de cabeza a combinar XFS y BTRFS. Qué raros son, copón.
Yo estoy empezando a usar XFS en sistemas de ficheros grandes, sobre todo porque, aunque con ext4 esto ha mejorado mucho, en un reinicio con un sistema de muchos TBytes (de 10 para arriba), te podías morir del asco esperando a que el FSCK obligatorio terminara.
XFS precisamente nace en SGI con el objetivo de almacenar grandes ficheros de los servidores de streaming de video, y en este sentido funciona bastante bien.
#25 Yo creo que #18 se acuerda de un problema que tuvo XFS hace muchos años, en el que si había un apagado repentino, te podías encontar un montón de ficheros rellenos con ceros. Eso pasó a la historia hace mucho tiempo, y en mi caso no me afectaba porque en los servidores hay UPS, y RAIDs con batería y cosas así.
A btrfs le tengo muchas ganas, sobre todo porque tiene capacidad de snapshots, que para hacer backups rápidos es genial. Imaginad que antes de hacer cada actualización o instalación del sistema (con apt, o yum) hacéis un snapshot del disco (que es instantaneo) y al reiniciar, si falla, podéis volver al punto anterior de guardado instantaneamente y reiniciar de nuevo en el estao que teníais justo antes de actualizar.
Y como dice #5 , ZFS es la pera, pero el soporte en linux es regular, así que yo lo uso en mi servidor de almacenamiento local y en algunos clientes con FreeNAS, que es un inventazo para NAS cojonudo. Tiene snapshots, evita el bit rot con unos checksums muy grandes, compresión transparente del sistema de ficheros por zonas, tiene unos modos de RAID muy buenos, revisión online de fallos de disco (scrubs), discos de caché de escritura y lectura, deduplicación...
Yo estoy empezando a usar XFS en sistemas de ficheros grandes, sobre todo porque, aunque con ext4 esto ha mejorado mucho, en un reinicio con un sistema de muchos TBytes (de 10 para arriba), te podías morir del asco esperando a que el FSCK obligatorio terminara.
XFS precisamente nace en SGI con el objetivo de almacenar grandes ficheros de los servidores de streaming de video, y en este sentido funciona bastante bien.
#25 Yo creo que #18 se acuerda de un problema que tuvo XFS hace muchos años, en el que si había un apagado repentino, te podías encontar un montón de ficheros rellenos con ceros. Eso pasó a la historia hace mucho tiempo, y en mi caso no me afectaba porque en los servidores hay UPS, y RAIDs con batería y cosas así.
A btrfs le tengo muchas ganas, sobre todo porque tiene capacidad de snapshots, que para hacer backups rápidos es genial. Imaginad que antes de hacer cada actualización o instalación del sistema (con apt, o yum) hacéis un snapshot del disco (que es instantaneo) y al reiniciar, si falla, podéis volver al punto anterior de guardado instantaneamente y reiniciar de nuevo en el estao que teníais justo antes de actualizar.
Y como dice #5 , ZFS es la pera, pero el soporte en linux es regular, así que yo lo uso en mi servidor de almacenamiento local y en algunos clientes con FreeNAS, que es un inventazo para NAS cojonudo. Tiene snapshots, evita el bit rot con unos checksums muy grandes, compresión transparente del sistema de ficheros por zonas, tiene unos modos de RAID muy buenos, revisión online de fallos de disco (scrubs), discos de caché de escritura y lectura, deduplicación...
#48:
#43 El 29 de agosto de 2008, Reiser fue sentenciado a 15 años de prisión, de acuerdo con los cargos de asesinato en segundo grado.
http://es.wikipedia.org/wiki/Hans_Reiser
http://es.wikipedia.org/wiki/Hans_Reiser
Comentarios
Lástima que ni se tenga en cuenta a Reiser4. Tiene unos "killer features" muy buenos
#9 que cabrón!
#9 Hay que peinar canas para pillar este chiste
#22 no tantas canas.... No soy un abuelo
#44 no hará más de 4 años del fatídico suceso no?
#46 ¿sólo? juraría que de aquella yo aún estaba en la universidad... y eso fue hace ya la porra de años
#46 El 10 de octubre de 2006, fue acusado del asesinato de su esposa, Nina Reiser, y fue encontrado culpable el 28 de abril de 2008 por un jurado popular. Cumple condena de 15 años en Mule Creek State Prison, Ione, California.
#44 Bueno, yo tengo canas desde los 30... este trabajo de picateclas, que nos trae muchos disgustos
#9 Qué bueno. Creo que el mantenimiento del sistema va en fascículos...
#9 Me has hecho sentir muuuuuuuuy viejo.
#9 jeje. No, ahora en serio, ¿Alguien me lo explica?
#43 El 29 de agosto de 2008, Reiser fue sentenciado a 15 años de prisión, de acuerdo con los cargos de asesinato en segundo grado.
http://es.wikipedia.org/wiki/Hans_Reiser
#43 Tiene que ver con lo que dice #38.
#13 Un gif animado en 4k de su primera comunión, cuando fue chuck quien le dio la hostia al cura y no al revés.
#14 Antes de esa Hostia los gifs no eran animados
ZFS sí que mola
En SLES 11 ni siquiera había soporte correcto para EXT4 y ahora van en el 12 y se saltan de cabeza a combinar XFS y BTRFS. Qué raros son, copón.
Yo estoy empezando a usar XFS en sistemas de ficheros grandes, sobre todo porque, aunque con ext4 esto ha mejorado mucho, en un reinicio con un sistema de muchos TBytes (de 10 para arriba), te podías morir del asco esperando a que el FSCK obligatorio terminara.
XFS precisamente nace en SGI con el objetivo de almacenar grandes ficheros de los servidores de streaming de video, y en este sentido funciona bastante bien.
#25 Yo creo que #18 se acuerda de un problema que tuvo XFS hace muchos años, en el que si había un apagado repentino, te podías encontar un montón de ficheros rellenos con ceros. Eso pasó a la historia hace mucho tiempo, y en mi caso no me afectaba porque en los servidores hay UPS, y RAIDs con batería y cosas así.
A btrfs le tengo muchas ganas, sobre todo porque tiene capacidad de snapshots, que para hacer backups rápidos es genial. Imaginad que antes de hacer cada actualización o instalación del sistema (con apt, o yum) hacéis un snapshot del disco (que es instantaneo) y al reiniciar, si falla, podéis volver al punto anterior de guardado instantaneamente y reiniciar de nuevo en el estao que teníais justo antes de actualizar.
Y como dice #5 , ZFS es la pera, pero el soporte en linux es regular, así que yo lo uso en mi servidor de almacenamiento local y en algunos clientes con FreeNAS, que es un inventazo para NAS cojonudo. Tiene snapshots, evita el bit rot con unos checksums muy grandes, compresión transparente del sistema de ficheros por zonas, tiene unos modos de RAID muy buenos, revisión online de fallos de disco (scrubs), discos de caché de escritura y lectura, deduplicación...
#37 Interesante, esperaba un comentario como el tuyo. Gracias
#37 gracias por el comentario.
Yo lo de los snapshots lo he visto en ONTAP y sé que son muy rápidos, pero no sé qué sistema de ficheros utiliza ONTAP por defecto.
Sin embargo, supongo que solo son rápidos cuando ya tienes uno previo y hace una copia incremental. Supongo que si es desde cero es lento porque tiene que volcar todo. Me equivoco?
#76 Los snapshots son siempre instantaneos. Simplificando, lo que hacen es marcar un punto en el tiempo, y después almacenar las diferencias.
De manera normal tienes que parar el sistema para hacer una copia completa, ya que si no van cambiando los ficheros mientras los vas copiando (Imagina un Ghost o imagen del sistema). De esta manera puedes hacer un snapshot, que el sistema de ficheros siga usando el sistema de ficheros sin problemas, y hacer una de dos cosas:
- Mantener el snapshot en ese almacenamiento para poder volver atrás a un punto en el tiempo instantaneamente.
- Copiar o reenviar el snapshot a otro sistema remoto, de backup o réplica, para tener una copia exacta del sistema sin tener que parar su funcionamiento.
Tanto ZFS como btrfs tienen esa capacidad.
#89 gracias por la explicación.
¿Si lo mandas a otro sistema lo que haces es copiar toda la información a lo bruto o solo un fichero con diferencias que luego es recuperable a no ser que el sistema de ficheros se corrompa?
#90 Depende del sistema de ficheros. Con el que tengo experiencia en eso, que es ZFS en FreeNAS, la primera vez lo manda completo y después sólo las diferencias. De esta manera puedes tener un duplicado del sistema remoto que se actualice, digamos, cada hora (o cada 10 minutos). Para la replicación inicial, si son muchos datos, puedes tener las máquinas juntas, en la misma red, y luego llevártelo al sitio remoto.
Aparte, los snapshots más antiguos se pueden ir eliminando con el tiempo. Por ejemplo, una regla como en mi caso podría ser: "Guarda snapshots cada hora durante un día, y después de un día guarda sólo cada 24h durante una semana. Después de una semana, ninguno.". Así puedes recuperar versiones de los ficheros de todos esos snapshots anteriores (similar a Time Machine). Aparte, en el sistema que se reenvían estos snapshots, también se guardan todas esas versiones, no las pierdes. http://doc.freenas.org/9.3/freenas_storage.html#replication-tasks
La verdad es que un FreeNAS bien configurado es la leche.
#91 conozco un poquito FreeNAS, pero apenas lo utilicé porque lo gestionaba un compannero, pero sí tiene buena pinta. ONTAP también hace esas cosas.
#92 La diferencia principal con ONTAP es el precio y que ONTAP, si no recuerdo mal, sólo correo en el hardware de NetApp , ¿no?.
Por lo que pone por ahí, ONTAP lleva un sistema de ficheros con nombre gracioso, WAFL.
http://web.archive.org/web/20140715102135/https://communities.netapp.com/community/netapp-blogs/dave/blog/2008/12/08/is-wafl-a-filesystem
#93 ONTAP es el sistema propietario de NetApp. ONTAP no vale nada, lo que cuesta un rinnón y parte del otro es el cacharro.
FreeNAS es libre y está genial como software, pero no sé si se puede utilizar para grandes infraestructuras.
De todos modos, creo que ONTAP tiene más opciones: puedes crear aggregates (no sé la traducción, creo que agregados) y ahora tiene modo cluster. Una virguería, vamos.
#94 No he leído muy bien lo que hacen los aggregates, pero creo que en FreeNAS hay algo parecido. En Freenas tienes uno (o varios) discos, que unes en RAID (vdevs), que unes en pools de almacenamiento (zpool). Normalmente, en un almacenamiento pequeño o mediano, sólo tendrás un vdev en un único pool. Pero cuando tienes muchos discos no puedes soltar un RAID de 25 discos, porque te puede fallar en un despiste (que te voy a contar si manejas NetApp).
Abreviando: Puedes agregar vdevs a tu pool existente para ampliarla, con cuidado de que tengan al menos igual seguridad de RAID que el que ya tienes.
Hay un tipo en el foro de FreeNAS que tiene una "guía para newbies" de FreeNAS que te deja algunos conceptos claros y mola. Es un powerpoint, vaya...
https://forums.freenas.org/index.php?threads/slideshow-explaining-vdev-zpool-zil-and-l2arc-for-noobs.7775/
#95 parece algo parecido.
El aggregate es como una especie de partición rígida (no se puede redimensionar), seguramente similar a lo del "pool" que me cuentas, y dentro de ella están los volúmenes, que se pueden redimensionar al antojo sin riesgo (eso está genial porque sin necesitas 20 GB creas un volumen de 22 GB, por ejemplo, y si luego te falta espacio lo redimensionas enseguida, con lo que optimizas el espacio). Y debajo de los volúmenes están los llamados qtrees, que son directorios pero con más opciones de configuración (puedes poner cuotas e historias).
Todo esto se ha complicado con la nueva versión de ONTAP que soporta modo clúster. Ahora puedes mover los aggregates de una máquina a otra del clúster y están los llamados servidores virtuales (vservers), que son como otro nivel jerárquico por encima, pero ahí empiezo a perderme un poco.
Yo he cacharreado un poco con NetApp, pero no tengo conocimientos avanzados. Estoy en ello porque me gusta el tema, lo que pasa es que tengo otras cosas que hacer, pero estoy intentando aprender.
#37 Espero que estés usando ECC...
#86 En servidores, sí, siempre.
#5
A mí me gusta. Lo que no me mola nada es su actual dueño.
Tendremos ext4 para rato, y lo mismo hasta ext5
XFS no permite reducir los sistemas de archivos.
#1 Explícate. ¿Te refieres a comprimir?
#63 A cambiar el tamaño de la partición. No puedes reducirla, solo puedes agrandarla.
#65 reducirla es arriesgado en cualquier caso. Yo no soy partidario de hacerlo y casi nunca es necesario.
Joder... Pues al leer el título del artículo me ha parecido que eran los comentarios que aparecían en Mortadelo y Filemón cuando se comían algo mu gordo y no podían hablar, o les habían dado tal piña que no tenían dientes para vocalizar.
Me estoy haciendo mu viejuno en informática....
"pero está bajo su paraguas en la actualidad. Más info."
El hecho de que en ese "Más info" no haya ningún enlace es muestra evidente de que el artículo es un Copia/Pega de otra página. Y no veo que en ningún sitio se cite a la fuente original. Así que voto errónea por copia/plagio.
Yo no uso sistemas de archivos creados por alguien que no haya matado a su mujer. ¡Larga vida a Reiser!
#25 yo use XFS durante un tiempo para guardar archivos multimedia, y todo genial, pero un día se fue la luz y todo a tomar por culo, imposible recuperar nada de ahy. Es ma fácil recuperar dato de un sistema de ficheros cifrado que de un XFS corrupto.
XFS Nunca más.
#41 Yo uso XFS para casi todas las particiones (y unidades) de datos, incluido el /home en las computadoras de escritorio, desde 2009 y hasta el momento, cero problemas.
Lo que si es aconsejable es leerse bien los manuales y conocer todas las aplicaciones de las que dispone XFS para la gestión de archivos (incluida la recuperación de particiones que hayan sufrido en algún apagón).
xfs_admin xfs_check
xfs_db xfs_freeze
xfs_growfs xfs_info
xfs_logprint xfs_metadump
xfs_ncheck xfs_repair
xfs_bmap xfs_copy
xfs_estimate xfs_fsr
xfsinfo xfs_io
xfs_mdrestore xfs_mkfile
xfs_quota xfs_rtcp
Creo que ya hace tiempo que es seguro utilizar XFS para particiones /boot; de todas formas yo sigo usando ext4 para particiones "del sistema"; aunque en ocasiones use JFS para algunas como /var y eso si, siempre particiones independientes para /boot, /home, /var.
#56 Yo separo / de /home
¿Qué ventaja tiene separar también boot y var? Hasta ahora no he tenido mucho problema
#66 Separar /boot es recomendable, siempre!!
La ventaja de separar /var se aprecia más si esa máquina corre un servidor web.
Lo cierto es que para una computadora de escritorio (doméstica) hago siempre las mismas particiones: /swap, /boot, /, /home. A la hora de usar varios núcleos, poder recuperar/restablecer los datos de /home; es más práctico. También es más práctico en el caso de que, por las razones que sean, necesites aumentar el tamaño de /swap y /home.
#56 es un portátil verdad? Algo con batería si se va luz... Te recomiendo que no apagues el equipo de golpe, puede que tengas suerte o puede que no...
#69 El portátil es el que uso como PC de escritorio; las otras computadoras son de sobremesa y casi ninguna tiene respaldo energético. Como dije antes, hasta ahora, ningún problema con XFS, ni con JFS.
#41 a mí un disco duro externo se me jodió (tropecientos sectores dañados, y que no montaba, vamos), y después de copiar la imagen de lo que se podía leer, usé una herramienta que viene con XFS (xfs_repair? ya no recuerdo) con la cual, si no recuperé todo, sí recuperé todo lo que me hacía falta.
#71 Normalmente con xfs_check, xfs_ncheck y xfs_mdrestore se recupera de cualquier desmontaje inesperado. Es evidente que ni con XFS ni con ningún FS se puede prescindir de los backups...
#41 Yo llevo años usando XFS y nunca he tenido esos problemas que dices, a pesar de haber sufrido apagones y reinicios a lo bruto. Si que me ha pasado de quedarse un fichero vacío, el fichero seguía ahí pero sus datos no estaban (esto ocurre porque XFS usa journaling de metadatos, pero no de los datos en sí). Jamás he sufrido una corrupción completa del sistema de ficheros.
De todas maneras, si quieres evitar estos problemas, uses el sistema que uses lo mejor es tener un SAI, que no son tan caros.
En este pobre "análisis" no se tiene en cuenta las necesidades de los SSD (como no usar varias veces el mismo sector). En esto XFS esta en bragas porque no tiene un soporte muy brillante y no supera a ext4 en velocidad, Brfs es aún nuevo y no se sabe si es lo suficientemente estable pero estan haciéndolo bastante bien con las ssd, y ext4 es bastante rápido con ssd y se le ha dado un soporte excelente, pero tiene las limitaciones con las convencionales.
#23 una cosa que tampoco tiene en cuenta es que el planificador de disco influye igualmente en el rendimiento de la lectura/escritura. Por ejemplo, para SSD se recomienda NOOP o Deadline, pero hasta hace muy poco CFQ era el planificador por defecto para cualquier tipo de disco.
#30 Siempre hablando de entornos muy exigentes, se recomienda NOOP... Deadline la mayoría de las veces es tan malo como CFQ.
De todas formas el planificador no tiene tanta importancia como el sistema de archivos, pues cambiarlo no supone ningún problema comparado con tener que formatear los discos duros, preparar herramientas para la recuperación, mantenimiento, etc y tener que lidiar con las incompatibilidades.
Trisquel GNU/Linux usa por defecto mucho antes que RedHat y SuSe el sistema de archivos XFS. Y es una distro enfocada a usuarios domésticos, PYMES y centros educativos.
https://trisquel.info/
#68 BTRFS para / con compress, ext4 para boot. Mucho mejor.
#21 azul
#24 Da igual cual me hubieses dicho, te iba a recomendar Xubuntu de todas formas.
#32 pero eso corre en mi reloj casio?
#35 Solo si es de más de 100 metros water resistant.
No voy a hablar del sistema de ficheros para particiones del sistema si no para particiones de almacén y pendrives. Señores, tenemos un sistema que cumple lo siguiente:
-Estándar ISO, abierto y libre de royalties.
-Compatibilidad: lectura desde Windows 95, AmigaOS... lectura y escritura: desde Vista, Linux 2.6, Mac OS 9, *BSD, Solaris, BeOS...
-Utilización cíclica de los clústers: lo que hacen los SSD modernos para evitar sobregastar una zona del chip y dejar otras intactas. Ideal para pendrives y unidades flash (hoy en día los SSD ya lo incluyen pero seguro que los usb barateros aún siguen muriendo prematuramente por el modelo FAT).
-Soporte para permisos unix.
-Journaling (al menos en el estándar, luego implementarlo es cosa de cada sistema).
Es decir, puedes tener un pendrive con permisos de usuario y ejecutables desde un Unix y a la vez puedes prestárselo a un conocido con Windows o usarlo para para pasar archivos a prácticamente cualquier sistema operativo de menos de 15 años de antigüedad y varios más viejos.
Pero antes de que vayáis ilusionados a formatear vuestro pendrive o la partición de datos compartidos, la mala noticia: me cansé de que Linux (si, lees bien, Linux está más verde que otros sistemas en soporte UDF) me corrompiese las particiones UDF periódicamente (perdiendo montón de archivos y sin herramientas de checkeo, acababa encendiendo Windows solo para pasarle el testdisk y con suerte poder volver a montarla), adiós a mi partición común al dual boot y mi pendrive, seguimos teniendo que elegir: quedarnos sin ese espacio accesible con windows o conformarnos con un fs mejorable como NTFS.
Ya tenéis una crítica real que hacerle a Linux en los flames
Ojalá alguien me pagara por arreglarlo, para poder gastar algo de tiempo laboral en ello (que igual no consigo nada, pero ya que parece no interesar a nadie quisiera intentarlo), la verdad que mientras no se corrompían las particiones era la leche de cómodo y bastante rápido y con ntfs-3g el uso de CPU es excesivo.
PD: Si alguien está tentado a echarle la culpa a Windows de mis particiones corruptas, hice la prueba sin arrancar Windows en ningún momento y la partición acabó igual. También probé todas las versiones de UDF soportadas por Linux que, por cierto, solo llega hasta UDF 2.01 mientras otros sistemas actuales soportan versiones más modernas.
Anexo: http://en.wikipedia.org/wiki/Universal_Disk_Format
#50 " y con ntfs-3g el uso de CPU es excesivo."
Ya no. No se usa ntfs-3g además, creo.
Aún así... tienes un driver EXT para Windows.
#52 Hasta donde se seguimos con ntfs-3g.
Dime de que driver para Windows me hablas y te diré porque no vale (no he probado versiones de pago).
Además, que es muy simple, UDF tiene soporte nativo en todos los sistemas actuales, una opción multiplataforma promovido por ISO. Linux debería espabilar en ese tema o dar explicaciones técnicas si las hay. Reinventar la rueda con drivers en Windows, implementaciones con problemas de patentes, etc. es un esfuerzo tonto habiendo una opción tan sencilla. Hablamos de que la propia Microsoft y Apple estarían dando soporte a ser plenamente compatibles con Linux pero nadie se molesta en hacer la parte desde el propio Linux.
#57 "Hablamos de que la propia Microsoft y Apple estarían dando soporte a ser plenamente compatibles con Linux pero nadie se molesta en hacer la parte desde el propio Linux. "
No, es MS y Apple donde deben espabilar.
Linux soporta una cantidad ingente de sistemas de ficheros. Incluso Haiku lee BTRFS, ZFS, ext4, UDF, NTFS y UDF.
OSX y Windows sin embargo, no tanto.
No les costaba a ellos nada implementar EXT4.
#58 No señor, primero: es un estándar de ISO y Linux esta fallando en soportarlo. Que no es que no lo quieran soportar (elección respetable), es que tienen una implementación defectuosa que corrompe particiones.
Segundo: si una empresa como elección comercial o técnica no quiere gastar recursos en soportar soluciones ajenas es lo que hay. Además MS tiene motivos, los permisos Unix no tienen sentido en NT. Eso de volcar las responsabilidades propias en otros es muy inmaduro. Es la comunidad Linux la que quiere interoperar con Windows y NTFS-3G es la prueba.
De bonus: me dices que linux soporta UDF (en tu lista) y es precisamente la carencia de la que me estoy quejando... ¿Me estas leyendo o estás enfocando esto en defender Linux?
#59 " Además MS tiene motivos, los permisos Unix no tienen sentido en NT. "
Interoperabilidad. Linux ya soporta bastantes FS. Es la de hora de que NT se mueva. Por su bien.
Repito, hasta Haiku, una recreación libre y mejorada de BeOS, tiene más soporte de lectura de más sistemas de ficheros que Windows .
#60 Estoy de acuerdo, pero ellos no quieren así que nos aguantamos. Por eso Linux, BSD y compañía son tan buenos sistemas en comparación.
Pero lo de UDF en Linux esta mal, o lo corrigen o quitan el soporte de escritura y son honestos con lo que soportan.
#62 Eh, OpenBSD sí soporta UDF, es harina de otro costal.
Sobre la escritura, la soporta pero hasta la versión 2.01
#57 "Hablamos de que la propia Microsoft y Apple estarían dando soporte a ser plenamente compatibles con Linux pero nadie se molesta en hacer la parte desde el propio Linux."
Una mierda. Todavía no he visto nada similar a Wine en Windows.
Ni soporte de ext4, ni ext3 ni 2 siquiera. Es que ni XFS.
POSIX, cutremente. OSX vale, viene con la casa.
¿De qué compatibildad me hablas? En Windows solo existe su ecosistema y ya.
#61 No me malinterpretes, no digo que MS ni Apple hayan echo un movimiento por acercarse o interoperar con otros. Es una consecuencia secundaria de su soporte al estándar UDF, que abre una opción fácil para el usuario que quiere tener una partición compartida. Pero por parte de Linux no se esta aprovechando cuando se debería, para eso están los estándares de la ISO.
Es un caso concreto en el que hay que criticar a linux. Sin quitar que otros lo hagan peor en general.
#52 creo que sí se sigue usando NTFS-3G, aunque estas cosas cambian tanto que vete a saber.
#52 Crees mal, todavía se usa, aunque no sea la única implementación. La implementación del kernel no tiene posibilidad de escribir, y tanto ntfsprogs como ntfs-3g usan "fuse", por lo que el rendimiento no es su fuerte.
Cuál es el mejor para Escritorios?
#3 Pues el sistema de archivos ese de tres o más pisos apilable, de plástico.
#3 Depende, cual es tu signo del horoscopo chino?
Chuck Reynolds usa ext3
#2 Chuk Norris usa FAT y consigue grabar en él ficheros de 1TB.
#7 Dices bien,chuck nunca usa ficheros menores de un tera
#7 ... en floppies de 1.44 Mb
#20 Usando solo un disquete.
#20 nahh todavía usa tarjetas perforadas
http://www.esacademic.com/pictures/eswiki/70/FortranCardPROJ039.agr.jpg
#7 Que coño, Chuck no usa sistemas de ficheros, eso es de nenazas. Un fichero tras otro y el índice en su cabeza. Y ay de aquel fichero que ose fragmentarse...
#2 Y Chuck Norris no utiliza sistemas de ficheros, el disco duro envía al bus los datos que el necesita cuando el los necesita.
Btrfs pienso es el que debería sustituir a los Ext.
#19 eso lo llevo oyendo desde hace ya bastantes annos y nunca pasa. Cada vez tengo más dudas.
Es hora de hacerse una liposución?
yo uso btrfs, pero cuidado, que puede dejar fácilmente el árbol binario no balanceado y entonces no tendrá espacio ni para ejecutar el propio desfragmentador. Las distribuciones deben de pulir eso para hacerlo automáticamente.
Alguien que me explique por qué esto es mejor que ext4 + LUKS
Es hora de dejar de actualizarse ¡qué pereza, pardiez!
Ni XFS ni Btrfs, el mejor es ZFS de lejos, se come a los dos juntos.
Ni uno ni otro sino todo lo contrario.
Ext4 hasta que el infierno se congele. O tenga que formatear...
XFS? NI DE COÑA.
#18, ¿por?
Las herramientas de recuperación de btrfs están todavía muy verdes.
Pese a que por alguna razón concluye cerca de como concluiría yo... si nos ceñimos al articulo, es niñolevel. A ver si algún día escriben uno para mayores.
joder justo la semana pasada hablamos de esto en clase y me interesé en buscar algo para pasarlo todo a algo mejor que no fuera ext4 ni ntfs
Yo llevo años usando XFS y siempre me ha dado un rendimiento excelente, creo que debería haber sustituido a extN hace años. En cuanto a Btrfs, lo probé hace poco y aunque al principio iba muy bien, de repente un día se saturó y empezó a fallar todo. Intenté liberar espacio (trim, defragmentación, etc.), pero nada, al final tuve que reinstalar... esta vez con XFS
Es un error conocido, y hasta que no esté resuelto no se podrá usar a gran escala.
Hay que escoger el que mejor le venga a Android, por supuesto. Las demás distribuciones son irrelevantes ahora mismo.
#6 Precisamente Android usa un sistema de archivos que ya no se usa en la mayoría de distribuciones que es el EXT3...