Demande de test !
J'apprécierais que certains d'entre vous testent une nouvelle option qui modifie la façon dont UML écrit dans les fichiers du système de fichiers, et qu'ils fassent part de leurs expériences ici.
Normalement, l'UML utilise les appels de la bibliothèque de lecture/écriture ouverte/fermée standard. Le problème est que cela duplique les données dans le cache de page de l'hôte et a un impact sur les performances d'entrée/sortie du disque. La nouvelle option permet de mapper le fichier du système de fichiers directement dans le cache de pages, ce qui élimine les copies en double des pages et le gaspillage du cache de pages...
Vous remarquerez une nouvelle "Option expérimentale" dans la page Edit Config Profile. Pour l'activer, activez ubd=mmap, sauvegardez et redémarrez. Vous devriez le remarquer dans dmesg sous kernel options. (dmesg | grep mmap)
Une fois que nous aurons reçu un certain nombre de rapports fructueux, j'envisagerai d'activer cette fonction pour tout le monde.
[color=darkred][b]WARNING :[/b][/color][/size] Je ne recommande PAS à quiconque d'activer cette fonction pour l'instant. Il y a toujours un risque de perte de données avec une fonctionnalité en cours de maturation comme celle-ci. Jeff Dike a corrigé le dernier bogue connu de ubd=mmap le mois dernier qui mangeait les systèmes de fichiers de plus de 4GB (ce serait donc un bon test), donc utilisez cette option avec prudence. Il n'y a pas eu de rapport d'échec lié à mmap sur les listes de diffusion UML, mais ce n'est pas une option très connue.
La version actuelle (dans les noyaux 2.4.24) a bien fonctionné pour moi avec mmap activé, mais votre kilométrage peut varier.
Merci,
-Chris
Commentaires (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