XFS – Empty files after a crash

Another major bug in XFS :

After a power failure, server was back but shows some files with size 0 (when I was sure this cannot be possible).
using ‘du -sh’ on this folder shows that total size was > 0 …

The bug was already reported on XFS mailing list here :

http://oss.sgi.com/archives/xfs/2012-02/msg00517.html

If you have many files to recover, procedure is really a pain. That’s why I created a small PHP file that do the trick.

https://github.com/odoucet/xfsrepair

i’m not responsible if you destroy your data 😉 But this script worked well for me.

No space left with XFS

Today I hit a limit on XFS.
A task creating thousands of files was failing with this error :

No space left on device

Even if I still have plenty of disk space :

Filesystem               Size Used Avail Use% Mounted on
/dev/mapper/backup-logs  2.0T 1.6T 485G 77% /srv/logs

Filesystem used is XFS.

If you also have this bug, fix is very easy : you need to remount the filesystem with « inode64 » option. This is because XFS, by default, only use the first terabyte of data to store inodes. If you create many files, this limit is reached. By adding the mount option ‘inode64’, you give XFS permission to use the whole device to create inodes.

Only drawback is bugs with very old softwares, especially over NFS. This is really a rare situation.

 

 

Migrer de PHP 5.3 à PHP 5.4

Les développeurs de PHP ont choisis de se focaliser sur les performances plutôt que sur les nouvelles fonctionnalités sur la version 5.4 ; mais cette version est également un grand saut sur beaucoup de fonctions dépréciées, qui sont maintenant totalement supprimées.

La migration de la version 5.3 vers la 5.4 est donc une étape délicate (bien plus que de 5.2 vers 5.3), et de nombreux points sont à vérifier avant de se lancer dans l’opération.

Continuer la lecture de Migrer de PHP 5.3 à PHP 5.4

Migrer de PHP 5.2 à PHP 5.3

PHP 5.2 n’est plus maintenu depuis janvier 2011, il devient donc tant de migrer sur la version 5.3 (surtout que dorénavant, la 5.4 est sortie en stable …).

Mais une migration doit toujours se préparer, afin qu’elle se passe le mieux possible sans grosse interruption de service. Voici donc une présentation des incompatibilités entre ces deux versions.

Continuer la lecture de Migrer de PHP 5.2 à PHP 5.3

Customer case : finding an unusual cause of max_user_connections

The last few days were very busy dealing with a problem on the MySQL server of a customer. My company is offering fully managed hosting services, so it was up to us to investigate the troubles. I’ll try to explain some of the checks I’ve done ; maybe this can give you some ideas when you also deal with mysql troubleshooting.

Continuer la lecture de Customer case : finding an unusual cause of max_user_connections

« Certains de mes champs POST sont ignorés par PHP ! »

J’ai eu ce genre de message plusieurs fois de la part de clients ces derniers temps, et je pense que cela peut concerner beaucoup de monde donc je vous donne les explications.

Le symptôme est simple : « Les X premiers champs envoyés en POST sont bien lus par PHP, mais à partir d’une certaine limite ceux-ci ne sont plus disponibles. » Ou formulé autrement : « il me manque une partie des champs POST ».

Le plus curieux dans cette histoire, c’est que votre code PHP fonctionnait très bien il y a quelques semaines, et là d’un seul coup, plus rien. Que s’est-il passé ?

Vous n’êtes pas en tord, et pourtant il va vous falloir faire des modifications sur la config de PHP 🙂 Le coupable ? Un trou de sécurité dans PHP assez sérieux, qu’il a fallu corriger rapidement et donc … de manière un peu abrupte. Les curieux pourront lire le rapport de sécurité ici :  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4885

 Pour résumer en quelques mots : il s’agit d’une attaque par amplification. Une personne avec de mauvaises intentions peux envoyer un formulaire avec un certain formatage à votre serveur web, et PHP va mettre plusieurs minutes à la traiter … Multipliez ça par quelques centaines, et voilà votre hébergement dans les choux pour plusieurs heures. Je ne vous expliquerais pas dans cet article comment exploiter cette faille 😉

Pour limiter le champs de l’attaque, l’équipe de développement PHP a mis en place une limite simple : A partir de 1000 champs POST (d’ailleurs, c’est la même limite sur des cookies ou GET), PHP ignore tous les champs suivants. Donc si vous avez un très grand formulaire avec des milliers de champs, il va vous en manquer un bout.

Normalement, PHP vous prévient qu’il a dû tailler dans le vif avec ce message d’erreur : Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini.

Cela vous explicite donc le correctif : il suffit de modifier (ou plutôt ajouter, car je doute que vous l’ayez déjà) la variable max_input_vars dans votre fichier de configuration php.ini (qui se trouve généralement dans /etc sous Linux) et de lui mettre une grande valeur qui permettra à votre formulaire de fonctionner.

Et c’est tout ?

Oui, mais prenez garde : cette limitation était une limite de sécurité. Donc augmenter la limite vous expose à l’attaque initiale. D’expérience, vous pouvez monter à 5000 ou 10000 si vous avez des configurations relativement récentes. Au delà, c’est à vos risques et périls.

Comprendre les statistiques NFSD sous Linux

Les statistiques du serveur NFS sont accessibles dans le fichier /proc/net/rpc/nfsd ; c’est ce fichier qu’il faut lire si vous avez votre propre programme de monitoring et qu’il vous faut les valeurs « brutes ». Si c’est pour une lecture par un humain, l’utilitaire nfsstat est là pour ça. Petit tour d’aperçu des deux outils

Continuer la lecture de Comprendre les statistiques NFSD sous Linux