Le PC dans mon téléphone

Précédemment, j'ai évoqué l'ordinateur de demain. J'ai fait un test grandeur nature façon corporate. Comprendre : vous aurez du mal à faire pareil chez vous. J'utilise en effet quelques artifices comme un accès VPN au réseau de mon employeur, et au travers de cet accès une machine virtuelle VMware View.
Au final, j'ai le bureau d'une machine Windows 7 affiché sur la TV du salon, j'ai un clavier et une souris bluetooth, le tout servi par mon téléphone malin, via un tunnel VPN dans une connexion WIFI. La connexion avec la machine virtuelle se fait via le client officiel View, de VMware (donc en PCoIP).

Windows dans ma TV sur mon téléphone

Ci dessus une photo de la TV affichant le bureau de la VM dans laquelle est lancé le client VSphere (outil d'administration de datacenter VMware).

À 2m50, le texte dans l'interface n'est pas hyper lisible sur l"écran 80cm, donc pour le PC dans le canapé, on repassera, ou alors on fera des réglages spéciaux sur la machine virtuelle.

Le client View se comporte relativement bien, néanmoins, il y a comme un petit souci avec le clavier. Ce dernier fonctionne parfaitement en azerty partout, sauf à l'intérieur du Windows, où il fonctionne en qwerty. Le client View dispose d'un champs de saisie qui permet de taper du texte à l'extérieur de la VM et de l'envoyer ensuite vers cette dernière. À cet endroit, c'est bien de l'azerty. Mais le même texte tapé directement dans la VM passe en qwerty. C'est peut être du à mon téléphone, qui est paramétré tout en anglais.

Aussi, suite à un blocage logiciel sur ma VM, j'ai tenté un ctrl-alt-suppr via mon clavier bluetooth. Le programme n'a pas rendu la main, la VM n'a pas rebooté. Non. C'est le téléphone qui a rebooté. Ça m'a fait rire.

ZFS primarycache: all versus metadata

In my previous post, I wrote about tuning a ZFS storage for MySQL. For InnoDB storage engine, I've tuned the primarycache property so that only metadata would get cached by ZFS. It makes sense for this particular use, but in most cases you'll want to keep the default primarycache setting (all).
Here is a real world example showing how a non-MySQL workload is affected by this setting.

On a virtual server, 2 vCPU, 8 GB RAM, running FreeBSD 9.1-RELEASE-p7, I have a huge zpool of about 4 TB. It uses gzip compression, and stores 1.8TB of emails (compressratio 1.61x) and 1TB documents (compressratio 1.15x). Documents and emails have their own dataset, on the same zpool.
As it's a secondary backup server, isolated from production, I can easily make some tests.

I've launched clamscan (the binary part of ClamAV virus scanner) against a small branch of the email storage tree (about 1/1000 of total emails) and measured the zpool IOs, CPU usage and total runtime of the scan.
Before each run, I've rebooted the server to clear cache.
clamscan is set up so that every temporary files are written into a UFS2 filesystem (/tmp).

One run was made with property primarycache set to all, the other run was made with primarycache set to metadata.

Total runtime with default settings primarycache=all is less than 15 minutes, for 20518 files:

Scanned directories: 1
Scanned files: 20518
Infected files: 2
Data scanned: 7229.92 MB
Data read: 2664.59 MB (ratio 2.71:1)
Time: 892.431 sec (14 m 52 s)

Total runtime with default settings primarycache=metadata is more than 33 minutes:

Scanned directories: 1
Scanned files: 20518
Infected files: 2
Data scanned: 7229.92 MB
Data read: 2664.59 MB (ratio 2.71:1)
Time: 2029.921 sec (33 m 49 s)

zpool iostat every 5 seconds, with different primarycache settings, ~10 minutes range.

zpool IO stats

CPU usage for clamscan process, and for kernel{zio_read_intr_0} kernel thread. 5 seconds sampling, with different primarycache settings, ~10 minutes range.

CPU stats

In both tests, the server is freshly rebooted, cache is empty. Nevertheless, when primarycache=all the kernel{zio_read_intr_0} thread consumes very few CPU cycles, and the clamscan process run's more than twice as fast as the same process with primarycache=metadata.
More importantly, clamscan manages to read the exact same amount of data in both tests, using 10 times less IO throughput when primarycache is set to all.

There is something weird. Let's make another test:

I create 2 brand new datasets, both with primarycache=none and compression=lz4, and I copy in each one a 4.8GB file (2.05x compressratio). Then I set primarycache=all on the first one, and primarycache=metadata on the second one.
I cat the first file into /dev/null with zpool iostat running in another terminal. And finally, I cat the second file the same way.

The sum of read bandwidth column is (almost) exactly the physical size of the file on the disk (du output) for the dataset with primarycache=all: 2.44GB.
For the other dataset, with primarycache=metadata, the sum of the read bandwidth column is ...wait for it... 77.95GB.

There is some sort of voodoo under the hood that I can't explain. Feel free to comment if you have any idea on the subject.

A FreeBSD user has posted an interesting explanation to this puzzling behavior in FreeBSD forums:

clamscan reads a file, gets 4k (pagesize?) of data and processes it, then it reads the next 4k, etc.

ZFS, however, cannot read just 4k. It reads 128k (recordsize) by default. Since there is no cache (you've turned it off) the rest of the data is thrown away.

128k / 4k = 32
32 x 2.44GB = 78.08GB

Damnit.

MySQL on ZFS (on FreeBSD)

logofreebsdLots on FreeBSD users are coming to ZFS since the release of FreeBSD 10, as it's so easy to install the system on top of that powerful filesystem. ZFS default behavior and settings are perfect for a wide range of workloads and uses, but it's not exactly what you need for databases hosting.
I'm running a FreeBSD 9.x server hosting http, php, mysql, mail, and many other things, so a databases-only optimization would be counterproductive. After a good dive into experts do's & don't's here are few steps I've taken to tune my server.

Datasets

If like me you've started hosting MySQL databases a long time ago (say ~15 years ago) you might have some DB using the old MyISAM engine, and some newer ones using InnoDB. Guess what. They use different block sizes, and they use different caching mechanisms.
On top of that, the block size for InnoDB is not the same when you deal with data files, and when you deal with log files.
In order to get the best block size and cache tuning possible, I've created 3 datasets: one for InnoDB data files, one for innodb logs, and one for everything else, including MyISAM databases.

Block size

The block size is engine dependent. MyISAM uses a 8k block size, InnoDB uses a 16k block size for data and 128k for logs. It's easy to setup datasets for a particular block size at creation with -o option, or after creation with zfs set. You must set the proper block size before putting any data on the dataset, otherwise pre-existing data won't use the desired block size.

Caching

MyISAM engine relies on the underlying filesystem caching mechanism, so you must ensure ZFS will cache both data and metadata (that's the default behavior). On the other hand, InnoDB uses an internal cache, so it would be a waste on memory to cache the same data into ZFS and InnoDB. On a dedicated MySQL server, the proper tuning would require to limit ARC size, and to disable data caching in ZFS. On a general-purpose server, ARC size should not be tweaked, but on InnoDB dedicated datasets it's easy to disable ZFS cache for data by setting the property primarycache to "metadata".

On MySQL's side

You must of course tell mysqld where to find data files and logs. I've set those values in my /var/db/mysql/my.cnf file:

innodb_data_home_dir = /var/db/mysql-innodb
innodb_log_group_home_dir = /var/db/mysql-innodb-logs

where /var/db/mysql-innodb and /var/db/mysql-innodb-logs are mount points for the dataset dedicated to InnoDB data files, and the dataset dedicated to InnoDB log files.

As my zpool is a mirror, I've added this setting too:

skip-innodb_doublewrite

Step by step

I've followed this course of action:

1st step: mailing to users, "MySQL will be unavailable for about 5 minutes, hang on."
2nd step: backup /var/db/mysql and edit your my.cnf
3rd step: shutdown your mysql server

sudo service mysql-server stop

4th step: move /var/db/mysql to /var/db/mysql-origin
5th step: create appropriate datasets:

zfs create -o recordsize=16k -o primarycache=metadata zmirror/var/db/mysql-innodb
zfs create -o recordsize=128k -o primarycache=metadata zmirror/var/db/mysql-innodb-logs
zfs create -o recordsize=8k zmirror/var/db/mysql

6th step: move data from /var/db/mysql-origin to your new datasets

cd /var/db/
sudo mv mysql-origin/ib_logfile* mysql-innodb-logs/
sudo mv mysql-origin/ibdata1 mysql-innodb/
sudo mv mysql-origin/* mysql/

and set proper rights:

sudo chown mysql:mysql mysql-innodb-logs mysql-innodb mysql
sudo chmod o= mysql mysql-innodb-logs mysql-innodb

7th step: restart your mysql server

sudo service mysql-server start & tail -f mysql/${HOSTNAME}.err

8th step: mailing to users, "MySQL's back online maintenance duration 5 min 14 sec."

Further reading & references

MySQL Innodb ZFS Best Practices
A look at MySQL on ZFS
Optimizing MySQL performance with ZFS
ZFS for Databases

L’ordinateur de demain

N'en déplaise aux "power users" de l'informatique, l'ordinateur de demain c'est vraisemblablement votre téléphone malin. C'est forcément une idée qui me révulse, puisque ce sont des dispositifs fermés et - de mon point de vue - liberticides. Mais il ne s'agit pas de débattre ici du bien-fondé de mes réticences, il s'agit plutôt de faire un simple constat. En effet, on a pu constater ces dernières années que les utilisateurs sont prêts à sacrifier pas mal de choses pour gagner en mobilité : de la puissance, du stockage, de l'ergonomie, etc. En retour ils sont prêts à investir du temps et de l'argent dans leur smartphone, quitte à s'en servir comme outils de travail en dépit des contraintes énormes que cela représente.
L'ordinateur de demain c'est votre smartphone, et il y a quelques raisons pour cela :

  • La puissance des terminaux mobiles augmente très vite, permettant à des applications de plus en plus sophistiquées de voir le jour sur ces plateformes ;
  • Leur connectivité est très forte, sur des protocoles variés ;
  • On peut déjà transformer un smartphone en PC via quelques accessoires ;

slimportJe suis l'heureux détenteur d'un téléphone malin Nexus 4 (so 2012) qui dispose d'un port USB équipé de la technologie "SlimPort". C'est un détail important, car les téléphones qui disposent d'un tel port ne sont pas légion. Ce connecteur permet de brancher le smartphone à un moniteur ou à une télévision via un adaptateur DisplayPort USB vers HDMI.
Déjà, c'est sympa puisque cela me permet de regarder une vidéo HD stockée sur (ou "streamée" à partir de) mon téléphone directement sur la TV du salon. L'HDMI est ici utilisé en plein, puisque le signal sonore transite avec la vidéo et sort bien sûr des enceintes de la TV. Comme un câble HDMI n'est pas bien long, il faut bien sûr se déplacer pour interagir avec l'écran, ce qui est fastidieux.
C'est ici qu'entre en scène ce vieux protocole du début des années 2000 : Bluetooth. Il est en effet assez facile de trouver un clavier et une souris Bluetooth de nos jours : c'est ce que j'ai fait, et ça marche du tonnerre.
Ainsi, avec un Nexus 4, un clavier Bluetooth (Perixx PERIBOARD-804), une souris Bluetooth (Apple Magic Mouse qui trainait dans un carton) et le fameux adaptateur SlimPort, j'ai pu construire un petit PC de salon. Bien évidement, ce n'est pas un poste bureautique. Même si le clavier rend des tâches rédactionnelles tout à fait aisées, les applications ne sont pas forcément à la hauteur. Pour le tout-venant c'est très simple : écrire avec un vrai clavier physique (email, sms, document…), utiliser l'interface avec la souris, surfer sur internet, passer d'une application à l'autre, etc. Presque tout fonctionne parfaitement. Il n'y a que deux limites actuellement à ce que je peux faire dans cette configuration. Je ne peux pas dire au téléphone de basculer en mode paysage, je suis obligé d'aller incliner le téléphone à la main. C'est un peu pénible car si on revient sur le "bureau" du téléphone, il repasse immédiatement en orientation portrait, ce qui n'est pas la meilleure façon de tirer partie d'une TV 16/9ème. Seconde limitation : il n'est pas possible de zoomer en avant ou en arrière car la souris ne permet pas de simuler ce mouvement des doigts (bien que la souris Apple soit multitouch).

Il me semble important de faire quelques remarques sur le matériel. Le clavier Perixx PERIBOARD-804 est simple, léger, relativement petit et confortable à la frappe. Il est parfaitement compatible avec Android en français, et c'est un des rares claviers Bluetooth disponible nativement en version AZERTY, pour un prix raisonnable (nous l'avons acheté à moins de 30 euros). Si vous vous intéressez à ce matériel, vous constaterez que de nombreux acheteurs rapportent que la prise s'est enfoncée dans le clavier quand ils ont voulu brancher le câble USB fourni pour le recharger. Mon conseil : n'utilisez pas le câble fourni. Je pense que la prise femelle est quelques dixièmes de millimètres trop petite. Utilisez un autre câble pour recharger le clavier (j'utilise le câble de mon Nexus qui entre parfaitement sans forcer).
L'adaptateur SlimPort d'Analogix est de bonne facture, mais il reste fragile. SlimPort est une technologie qui permet le passage du flux HDMI sur une simple paire de câbles torsadée : le câble est donc très fin comparé à un câble HDMI. Évitez de tordre l'adaptateur, n'abusez pas de sa souplesse, et gardez-le autant que possible bien droit sans lui imposer de rotation sous peine de subir pas moment des pertes de signal.

English video review pour le clavier Perixx PERIBOARD-804

Trajets et itinéraires de la mémoire

Trajets_et-_itineraires_de-_la_memoireSerge Brussolo est un auteur intéressant. Je l'ai découvert il y a plus de 10 ans, en dévorant Le Syndrome du scaphandrier. Son univers, un peu Science Fiction mais pas trop, est riche, étrange, sur-réaliste et surtout très centré sur l'humain. C'est particulièrement sensible dans le recueil de nouvelles Trajets et itinéraires de la mémoire qui regroupe des textes du début de sa carrière. Des textes dont certains préfigurent d'ailleurs très fortement des romans ultérieurs comme Le Syndrome du scaphandrier.

Ce recueil de nouvelles fait plonger le lecteur dans des mondes durs, des mondes impitoyables où les protagonistes sont perpétuellement en position de faiblesse. La vulnérabilité est la règle, la nudité un uniforme, celle des corps bien sûr, mais celle des esprits aussi. La pitié n'existe pas, et l'humain est maltraité au fil des pages par des régimes autoritaires absurdes. La où certains voient une déshumanisation je vois plutôt une vision tourmentée de la condition humaine. Serge Brussolo plonge le lecteur dans une version noire, extrêmement fataliste de notre monde soumis à un autoritarisme déviant. La folie est partout dans cette prose mais elle n'est pas gratuite et j'aime à penser que l'auteur y dénonce une sorte d'impuissance face à la bêtise.

Les nouvelles de Trajets et itinéraires de la mémoire ne se valent pas toutes, malheureusement, et j'ai trouvé que les dernières du recueil étaient un peu en dessous des autres. Néanmoins la lecture reste très agréable, et les amoureux de l'étrange, de la folie, y trouveront leur compte. C'est délicieusement dérangeant, ça perturbe et vient titiller certaines peurs ataviques. C'est finalement profondément humain.

Collecte en aveugle

Elle est belle celle-là :

213.61.149.100 […20:00:26 +0100] "GET / HTTP/1.0" 301 235 
213.61.149.100 […20:00:27 +0100] "GET /blog/ HTTP/1.0" 200 63772 
213.61.149.100 […20:00:28 +0100] "GET /www.patpro.net.tar.gz HTTP/1.0" 404 493 
213.61.149.100 […20:00:28 +0100] "GET /www.patpro.net.tgz HTTP/1.0" 404 493 
213.61.149.100 […20:00:29 +0100] "GET /www.patpro.net.zip HTTP/1.0" 404 493 
213.61.149.100 […20:00:29 +0100] "GET /www.patpro.net.sql HTTP/1.0" 404 493 
213.61.149.100 […20:00:30 +0100] "GET /patpro.tar.gz HTTP/1.0" 404 493 
213.61.149.100 […20:00:30 +0100] "GET /patpro.tgz HTTP/1.0" 404 493 
213.61.149.100 […20:00:31 +0100] "GET /patpro.zip HTTP/1.0" 404 493 
213.61.149.100 […20:00:31 +0100] "GET /patpro.sql HTTP/1.0" 404 493 

Et particulièrement astucieuse, je suis persuadé qu'elle permet de ramasser des tonnes de trucs très intéressants.

La SF et le temps qui passe

zodiac_couvertureMes lectures récentes me font m'interroger sur la manière dont la SF prend parfois la poussière. Non pas que je me pose la question pour la première fois. C'est simplement que je me livre ces derniers temps à quelques acrobaties temporelles, enchaînant Zodiac de Neal Stephenson publié en 1988, Les enfants d'Icare d'Arthur C. Clarke publié en 1953, et Histoire Zéro de William Gibson publié en 2010.
Le contraste entre ces trois ouvrages est saisissant. Le premier, Zodiac, est une sorte de thriller scientifico-fictionnaire écrit dans un style presque familier. Pour un lecteur de mon âge, il fait l'effet d'être ancré dans un passé proche, et seuls quelques détails datent réellement la prose : quelques références à des modèles de voitures, l'absence de téléphone portable, le recours à une bibliothécaire là où nous utiliserions internet. Mais finalement, impossible de forcer mon esprit à plaquer sur le récit des images tirées de mes souvenirs, ou des films des années 80. La prose résolument moderne, dynamique, familière impose presque au lecteur une représentation mentale contemporaine. Je recommande d'ailleurs ce roman à tous ceux qui voudraient lire un thriller sympathique, rempli de protagonistes décalés. Je suis un peu partial dans mon jugement, puisque le héros est chimiste. Quoi qu'il en soit, je me suis bien amusé en lisant cet ouvrage. C'est drôle, c'est fluide et bien mené.
Le second par contre est d'un tout autre genre. On met ici les pieds dans de la SF pure et dure. N'oubliez pas qu'on doit à son auteur un monument comme 2001 l'Odyssée de l'Espace. Néanmoins, sur le plus pur plan stylistique, la marche est sacrément haute entre Les enfants d'Icare et Zodiac. D'une sorte de scène rock-grunge-jean-converse on bascule dans un univers de costumes années 50 avec chapeaux de feutre et vouvoiement entre mari et femme. Clarke a beau essayer de nous vendre une vision de l'an 2050, la sauce ne prend pas vraiment, en tout cas au début. Les anachronismes sont malheureusement trop nombreux. Même si il n'est donné à personne - pas même au plus brillant des écrivains - de prédire le futur, Clarke s'est fait piégé en donnant trop de détails qui enferment sa prose dans la technologie des années 50. J'ai vu il y a quelques années la version originale (1951) de The day the earth stood still, et je peux affirmer que ma représentation mentale du roman de Clarke est assez proche de ce vieux film de SF. Bref c'est poussiéreux, mais fort heureusement, Arthur C. Clarke ne démérite pas, puisqu'il parvient in extremis à terminer son roman sur un dénouement aussi intéressant qu'inespéré, posant les bases de réflexions que développeront plus tard des auteurs plus ou moins trans-humanistes.
J'ai hésité à parler d'Histoire Zéro, puisque je suis à peine au tiers de l'ouvrage. Quoi qu'il en soit, ayant lu la quasi-totalité de l'œuvre de William Gibson, je trouve qu'il a bien sa place dans cet article. En effet, Gibson a démarré sa carrière littéraire sur la scène Cyberpunk, avec des ouvrages très engagés dans la technologie et l'anticipation : futurs à la Blade Runner, implants homme-machine décrits en détail, etc. Il a progressivement orienté son écriture vers quelque chose de plus dépouillé. C'est un processus à la fois extrêmement facile à déceler et très intéressant pour qui prendra la peine de lire ses romans dans l'ordre chronologique de leur parution. Bref. Histoire Zéro ce n'est plus vraiment de la SF, on est à la limite du roman d'espionnage industriel. Même si le goût pour la technologie est toujours là, Gibson a clairement tourné le dos à la SF d'anticipation. Alors bien sûr, rien d'anachronique dans ce roman technophile de 2010 décrivant l'année 2010. Qu'en sera-t-il dans 5 ou 10 ans ? Je doute que les péripéties des protagonistes accrochés à leur iPhone ou à leur compte Twitter vieillissent aussi bien que Les enfants d'Icare, ou même que Zodiac. Néanmoins, sur le plan du simple plaisir de lecteur je m'avoue bien plus conquis par Gibson que par Clarke.
Si c'était à refaire, je pense que je lirais Les enfants d'Icare en premier, puis Zodiac, et enfin Histoire Zéro.

Work in progress

Je m'attaque à un petit projet photo, dans ma tête depuis un moment, et dans le monde réel depuis quelques jours. C'est assez banal somme-toute, et d'innombrables photographes s'y sont frottés avant moi : la reproduction de peintures classiques. Il ne s'agira pas pour moi, dans un premier temps, de reproduire fidèlement une œuvre existante. Je souhaite plutôt m'attaquer à l'imitation des ambiances, des lumières, des compositions classiques.
J'attaque donc ce projet sans tambour ni trompette par l'entrée de service : la nature morte. Non pas que la nature morte soit l'entrée de service - et donc de basse extraction - de la peinture classique. C'est plutôt que l'entrée en question donnait autrefois sur la cuisine ou pas loin, et que cette dernière est propice à la mise en scène de nature morte. Bref, voici un peu de ce que j'ai fait ces derniers jours, après avoir chiné quelques dentelles et un verre qui n'a jamais contenu de pâte à tartiner.

Quelques essais...

travail en cours

Pour un résultat tout à fait préliminaire plutôt plaisant :

IMG_4296_1

Je dois encore investir dans quelques accessoires (vieille vaisselle, nouvelle grappe de raisin, etc.) pour parfaire la composition, mais la lumière me plait déjà bien en l'état (et oui, le bout de sopalin est temporaire, c'est pour protéger le raisin que j'ai avalé après qu'il a fini de poser pour moi).