Pedido de teste!
Eu gostaria que alguns de vocês testassem uma nova opção que muda a maneira como UML escreve nos seus arquivos de sistema de arquivos, e publicassem suas experiências aqui.
Normalmente, a UML utiliza as chamadas padrão de biblioteca de leitura/escrita aberta/fechada. O problema com isto é que duplica dados na cache da página do anfitrião, e tem impacto sobre todo o desempenho i/o do disco. A nova opção mapeia o ficheiro do sistema de ficheiros directamente para a cache de páginas, pelo que elimina cópias duplicadas de páginas e a cache de páginas desperdiçadas...
Vai notar uma nova "Opção Experimental" na página Editar Config Perfil. Para a ligar, activar ubd=mmap, guardar, e reiniciar. Deverá reparar no dmesg nas opções do kernel. (dmesg | grep mmap)
Assim que tivermos um monte de relatórios bem sucedidos, considerarei a possibilidade de permitir isto para todos.
[color=vermelho escuro][b]AVISO:[/b][/color][/tamanho] NÃO recomendo a ninguém que ligue isto ainda. Há sempre uma hipótese de perda de dados com uma característica de maturação como esta. Jeff Dike corrigiu o último bug conhecido em ubd=mmap no mês passado que comia sistemas de ficheiros com mais de 4GB (de modo que seria um bom teste), por isso use esta opção com cautela. Não houve quaisquer relatos de falhas relacionadas com o mmap nas listas de correio UML, mas esta não é uma opção amplamente conhecida.
A versão actual (nos kernels 2.4.24) funcionou bem para mim com o mmap activado, mas a sua quilometragem pode variar.
Obrigado,
-Chris
Comentários (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