Solicitud de pruebas!
Me gustaría que algunos de ustedes probaran una nueva opción que cambia la forma en que UML escribe en sus archivos del sistema de archivos, y que publicaran sus experiencias aquí.
Normalmente, UML utiliza las llamadas estándar de lectura/escritura de la biblioteca open/close. El problema con esto es que duplica los datos en la caché de páginas del host, y afecta a todo el rendimiento de i/o del disco. La nueva opción asigna el archivo del sistema de archivos directamente a la caché de páginas, por lo que elimina las copias duplicadas de páginas y el desperdicio de la caché de páginas...
Notarás una nueva "Opción Experimental" en la página de Editar Perfil de Configuración. Para activarla, active ubd=mmap, guarde y reinicie. Debería notarlo en dmesg bajo las opciones del kernel. (dmesg | grep mmap)
Una vez que hayamos tenido un montón de informes exitosos, consideraré habilitar esto para todos.
[color=darkred][b]ADVERTENCIA:[/b][/color][/size] NO recomiendo a nadie activar esto todavía. Siempre hay una posibilidad de pérdida de datos con una característica de maduración como esta. Jeff Dike corrigió el último error conocido en ubd=mmap el mes pasado que se comía los sistemas de archivos de más de 4GB (así que esa sería una buena prueba), así que use esta opción con precaución. No ha habido ningún informe de fallos relacionados con mmap en las listas de correo de UML, pero esta no es una opción ampliamente conocida.
La versión actual (en los kernels 2.4.24) ha funcionado bien para mí con mmap activado, pero su kilometraje puede variar.
Gracias,
-Chris
Comentarios (7)
I’m game. 🙂
I just rebooted my linode with it enabled. I do nightly backups, so I am not overly concerned. Here’s hoping for the best..
That went badly.
From dmesg:
EXT3-fs error (device ubd(98,32)) in ext3_reserve_inode_write: IO failure
EXT3-fs error (device ubd(98,32)) in ext3_orphan_add: IO failure
attempt to access beyond end of device
62:20: rw=0, want=1086378492, limit=525312
EXT3-fs error (device ubd(98,32)): ext3_get_inode_loc: unable to read inode block – inode=2507, block=808465534
EXT3-fs error (device ubd(98,32)) in ext3_reserve_inode_write: IO failure
attempt to access beyond end of device
62:20: rw=0, want=1086378492, limit=525312
EXT3-fs error (device ubd(98,32)): ext3_get_inode_loc: unable to read inode block – inode=2507, block=808465534
EXT3-fs error (device ubd(98,32)) in ext3_reserve_inode_write: IO failure
attempt to access beyond end of device
62:20: rw=0, want=1086378492, limit=525312
EXT3-fs error (device ubd(98,32)): ext3_get_inode_loc: unable to read inode block – inode=2507, block=808465534
EXT3-fs error (device ubd(98,32)) in ext3_reserve_inode_write: IO failure
Over and over and over, and I/O failures on files. I’m turning it back off..
Well then. Let me gather the info and send that along to the list.
-Chris
My var filesystem was pretty goofed up, but I managed to fix it, and am up and running again without mmap.
Thanks for giving it a try. Glad it wasn’t too hosed… I guess there is our answer about mmap. It’s hungry for filesystems!
I’ve posted a msg to uml-user, so we’ll see what comes of it. I also removed the option from the config edit page…
Thanks,
-Chris
Not a problem, I was prepared if it had gone worse. I saw your email, I’ll be interested to see if they can track down the problem.. It’s an interesting option that I’d like to use on my non-linode UML’s as well.
Sounds like Jeff knows what to look for (from #uml)…
[code]13:05 < caker> jdike: anything else I can provide on the ubd=mmap corruption issue?
13:33 < jdike> caker: I’ve seen problems, so I’ve got something to chase
13:33 < jdike> caker: namely pages of zeros which shouldn’t be[/code]
-Chris