Solicitação de teste!
Gostaria que alguns de vocês testassem uma nova opção que muda a maneira como a UML escreve em 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 isso é que ele duplica dados no cache de páginas do host, e tem impacto sobre todo o desempenho i/o do disco. A nova opção mapeia o arquivo do sistema de arquivos diretamente para o cache de páginas, eliminando assim cópias duplicadas de páginas e o cache de páginas desperdiçadas...
Você notará uma nova "Opção Experimental" na página Editar Perfil de Configuração. Para ativá-la, Habilitar ubd=mmap, salvar e reiniciar. Você deve notar isso no dmesg sob as opções do kernel. (dmesg | grep mmap)
Uma vez que tivermos um monte de relatórios bem sucedidos, considerarei a possibilidade de permitir isso para todos.
[color=vermelho escuro][b]AVISO:[/b][/color][/tamanho] Eu NÃO recomendo a ninguém que ligue isto ainda. Há sempre uma chance 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 arquivos acima de 4GB (de modo que seria um bom teste), portanto use esta opção com cautela. Não houve relatos de falhas relacionadas ao mmap nas listas de correio UML, mas esta não é uma opção amplamente conhecida.
A versão atual (nos kernels 2.4.24) funcionou bem para mim com o mmap habilitado, mas 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