Hace 4 años | Por --605881-- a genbeta.com
Publicado hace 4 años por --605881-- a genbeta.com

Si eres de los que usa Linux por cualquier razón y además todavía manejas dispositivos con sistemas de archivo FAT16 o FAT32, hay buenas noticias para ti: la velocidad de transferencia de datos acaba de recibir un enorme empujón gracias a nuevo código que se incluirá en el kernel de Linux.

Comentarios

box3d

#4 Luego llega el médico y te dice que o te pones ex-FAT o mueres.

mierdeame

#1 Your mama's so FAT she can't save files bigger than 4GB

squanchy

#24 Realmente el problema no era de índices, si no de hacer demasiadas consultas con agrupaciones en una tabla con varios millones de registros. Es una empresa de telefonía, y guarda cada llamada y cada conexión a internet de cada teléfono. Imagina la burrada que es trabajar con eso. Y luego este cliente quiere la factura detallada a su gusto: llamadas dentro de bono (agrupadas), listado de las que se salen del bono, megas dentro de bono (agrupado), listado de los que se salen de bono, listado de sms, primera página con el resumen...

La solución fue recorrerla una vez para sacar los registros de la factura y meterlos en una tabla temporal, y luego operar con sólo esa tabla temporal. Y repetir esta acción por cada factura.
La alternativa era leer los registros y hacer yo los cáculos "a mano" con código y mira, como que no me apetecía mucho tener que echarle a eso 10 ó 12 horas.

squanchy

La semana pasada, después de un lustro con el cliente cagándose en mis parientes más queridos, hice un cambio que hizo que las facturas pasaran de tardar 9 segundos en generarse cada una, a tan sólo 0.8 segundos.

D

#20 Esos índices en la base de datos

vaiano

Me quedo con la entradilla "Si eres de los que usa Linux por cualquier razón..."
Ya no leí mas lol

W

#19 Bueno si tienes Android y quieres leer una microSD antigua...

noexisto

Ya no hay que comprar discos SSDs extraibles a 50 pavillos? Mira que me he vuelto loco comprando USBs de todas las marcas (pero es que con wx pasa igual: son más lentos que el cabello del malo)

Sinfonico

#5 Se habla de memorias sd, no de discos SSD

Nova6K0

#9 No se donde ves tú lo de los 50 pavillos, eso es lo que te descuentan.

Salu2

noexisto

#10 no es ese modelo. Espera...

noexisto

#10 Cuando me lo compré costaba eso. Funciona bien, algo lentillo (sobre 100-120, pero para mi uso va perfecto: si mueves muchos gigas ya Ralentiza. Hay que ir con cuidado, pero frente a los típicos Kingston de 8-16-32-64, etc ha descubierto el cielo en la tierra. Andaba ya desesperado)
Ah, olvidaba que eras tú: uso en Linux

Sinfonico

#9 Vale, pero formatear en fat32 un disco SSD me parece algo sin sentido, simplemente porque no soporta archivos de más de 4.2 gigas

D

#5 Algunos SSD extraibles pueden ir lentos por usarlos en puertos USB que no son 3.0/3.1, por no tener una controladora decente, o por no tener memoria cache. Los últimos dos apartados ocurren también en los que van enchufados a la placa base, y en general, estas carencias aparecen en los SSDs baratillos.

noexisto

#31 créeme que tengo una placa de más de 300€ y los usbs que he comprado son de toda marca y condición (las más marcas reconocidas). Es que habré comprado como 15 diferentes a ver si acertaba con la tecla.
Ojalá, como dices, la info que describes (como los discos duros) apareciera en las páginas de venta o, al menos, el nombre exacto del producto para irme a Kingston y mirarlo.
Salu2!

comadrejo

#c-27" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3289841/order/27">#27 Hace mucho tiempo revise este tema con profundidad, crtime no esta contemplado en posix por lo que muchas distribuciones no activan las opciones en el kernel para exponer crtime al espacio de usuario. Siempre hablando de ext4.

Como ejemplo comparativo de equipos que tengo a mano.
-> Ubuntu 20.04 (kernel 5.4.x):
# stat /var/log/dmesg
Fichero: /var/log/dmesg
Tamaño: 91135  Bloques: 184 Bloque E/S: 4096 fichero regular
Dispositivo: 10302h/66306d Nodo-i: 27918751 Enlaces: 1
Acceso: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 4/ adm)
Acceso: 2020-04-14 08:28:40.572920500 +0200
Modificación: 2020-04-14 08:28:40.596920499 +0200
Cambio: 2020-04-14 08:28:40.596920499 +0200
Creación: -

-> Gentoo con kernel 5.4.x compilado "a mano":
# stat /var/log/messages
Fichero: /var/log/messages
Tamaño: 5671558  Bloques: 11080 Bloque E/S: 4096 fichero regular
Dispositivo: 10301h/66305d Nodo-i: 3018055 Enlaces: 1
Acceso: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)
Acceso: 2020-01-05 08:22:20.435984704 +0100
Modificación: 2020-04-14 19:09:12.509882876 +0200
Cambio: 2020-04-14 19:09:12.509882876 +0200
Creación: 2020-01-05 08:22:20.435984704 +0100

Lo que si creo funciona siempre como root es el método que expongo en el comentario 14

noexisto

#30 Gracias!

B

Lo que yo realmente echo en falta en el kernel de linux es que se pueda consultar la fecha de creación de un fichero, es de traca que ese dato no exista en linux.

D

#8

Falso

stat(1) y stat(2)

touch hello
stat hello
ls -l hello


HISTORY
The stat() and fstat() system calls first appeared in Version 1 AT&T
UNIX. The header file and the struct stat were introduced
in Version 7 AT&T UNIX.

D

#16 Pero si stat hace eso desde Unix v7. Es mas, es un struct en mount que debes retocar por cada OS porque cada uno lo implementa com le sale de los cojones.

editado:
vale, acces time, dependera del sistema de ficheros. FFS y FFSv2 en el que uso no creo que tenga eso. HammerFS si ya que tiene hasta rollback. De ext4 ni idea.

D

#16 En OpenBSD:

a, m, c, B
The time file was last accessed or modified, or when the
inode was last changed, or the birth time of the inode
(st_atime, st_mtime, st_ctime, st_birthtime). If the
file system does not support birth time, the value is
undefined.

FFSv1 (el que hay por defecto) no lo soporta, pero puede que si FFSv2, que sera el FS por defecto en la 6.7, que esta por salir en breve, literalmente. Probare si eso.

D

#16 El stat de GNU deberia soportarlo en ext4. Depende de la implementacion y el FS.

selina_kyle

#11 Perdona pero de falso nada, que yo mas de una vez me he vuelto loca con eso.

He hecho eso que dices:

$ touch hello
$ stat hello
File: ‘hello’
Size: 0  Blocks: 0 IO Block: 4096 regular empty file
Device: 10306h/66310d Inode: 4603088 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ pr) Gid: ( 1000/ pr)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2020-04-14 18:36:39.017236740 +0200
Modify: 2020-04-14 18:36:39.017236740 +0200
Change: 2020-04-14 18:36:39.017236740 +0200
Birth: -

a las 18:36, bien.

$ gedit hello >> edito el archivo y lo guardo a las 18:37
$ stat hello
File: ‘hello’
Size: 7  Blocks: 8 IO Block: 4096 regular file
Device: 10306h/66310d Inode: 4603094 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ pr) Gid: ( 1000/ pr)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2020-04-14 18:37:12.409457376 +0200
Modify: 2020-04-14 18:37:12.411457389 +0200
Change: 2020-04-14 18:37:12.423457468 +0200
Birth: -

Ahora lo de las 18:36 se ha perdido para siempre.

Supongo que la creacion del archivo deberia guardarse en Birth, pero como puedes comprobar, sale vacio. En windows viene activado por defecto y es muy facil de ver. Sin comandos ni nada.

SemosOsos

#27 prueba con debugfs #14

frg

#27 Creo que te falta alguna opción en el montaje. La opción existe, pero se suele desactivar por temas de rendimiento. Si necesitas dicha opción, la activas y ya está.

bikooo2

#8 Al menos en Dolphin en KDE en el archivo que quieras clic derecho > propiedades > General y si lo quieres más detallado te vas a la pestaña Detalles y si no lo pones que los archivos de la carpeta te los muestre en vista detallada y le pones para que te muestre fecha de creación y como ya te ha mostrado #11 por comandos también se puede y supongo que en Gnome y en el resto de entornos de escritorio se podrá también de forma gráfica como en KDE

comadrejo

#c-8" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3289841/order/8">#8 crtime en ext4.

# debugfs -R 'stat /var/log/faillog' /dev/nvme0n1p2
Inode: 27929447 Type: regular Mode: 0644 Flags: 0x80000
Generation: 2209329449 Version: 0x00000000:00000001
User: 0 Group: 0 Project: 0 Size: 2049792
File ACL: 0
Links: 1 Blockcount: 24
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x5e8be830:8882e2d0 -- Tue Apr 7 04:40:48 2020
atime: 0x5e7aba85:00000000 -- Wed Mar 25 02:57:25 2020
mtime: 0x5e8be830:8882e2d0 -- Tue Apr 7 04:40:48 2020
crtime: 0x5e7c0e73:552217a8 -- Thu Mar 26 03:07:47 2020
Size of extra inode fields: 32
Inode checksum: 0xd3582a54
EXTENTS:
(0):111738164, (7):111706694, (500):111580218

D

Pues habrá que volver a formatear los USB pequeños en FAT16/32 de nuevo en vez de exFAT.

D

Eso no es de Windows, es por sistema de ficheros como digo.

PD: Yo no uso fedora, ni RHEL.

FreeBSD y NetBSD lo soportan, OpenBSD y DragonflyBSD no, pero con FFSv2 puede que lo implementen.

bikooo2

La verdad esta bien eso de que mejoren y tal la velocidad, pero lo que molaría es que los paratos nuevos que fuesen saliendo aceptaran otros sistemas de archivos más nuevos no solo exfat sino yo que se ese que creo samsumg (F2FS) que parece que también es libre o yo que se ext4 o ext3, pero bueno yo de eso no se mucho