SkyMinds ~ by Matt | Formateur et Développeur WordPress

Linux et MacOS : lister tous les répertoires de plus de 500 Mo

Publié le 28 mai 2026 by Matt Biscay · Lecture: 4 minutes

De temps en temps, il faut faire un peu de ménage sur son disque dur. Et, très souvent, le plus difficile n’est pas de supprimer les fichiers inutiles. Le plus difficile, c’est de trouver où ils se cachent.

Entre le dossier Downloads, les archives oubliées, les exports vidéo, les sauvegardes temporaires et les vieux projets jamais rangés, l’espace disque peut fondre très vite. Heureusement, sous Linux et macOS, une simple commande permet de repérer les répertoires les plus lourds.

Lister tous les répertoires de plus de 500 Mo

Voici la commande que j’utilise pour lister tous les dossiers de plus de 500 Mo dans le dossier Downloads, en les classant du plus gros au plus petit :

du -m ~/Downloads/* | awk '$1 > 500' | sort -nrCode language: JavaScript (javascript)

La sortie ressemble généralement à ceci :

8450    /Users/matt/Downloads/export-video
3210    /Users/matt/Downloads/archive-client
1275    /Users/matt/Downloads/site-backup
642     /Users/matt/Downloads/photosCode language: JavaScript (javascript)

En quelques secondes, vous obtenez donc une liste claire des dossiers qui méritent votre attention. C’est brutal, efficace, et ça évite de cliquer partout dans le Finder ou dans un gestionnaire de fichiers en espérant tomber sur le bon coupable.

Postfix : corriger l’erreur verify_cache.db “possible Berkeley DB bug”

Publié le 27 mai 2026 by Matt Biscay · Lecture: 4 minutes

En consultant les logs d’un serveur mail Postfix, je suis tombé sur un message qui revenait régulièrement :

close database /var/lib/postfix/verify_cache.db: No such file or directory (possible Berkeley DB bug)Code language: JavaScript (javascript)

À première vue, le message fait un peu peur. On lit Berkeley DB bug, on pense base de données corrompue, puis on commence à imaginer le serveur mail en train de mâcher ses propres fichiers. Bonne nouvelle : dans la plupart des cas, ce n’est pas dramatique.

Cette erreur concerne le cache de vérification d’adresses de Postfix. Lorsque Postfix utilise la vérification d’adresses, il peut stocker les résultats dans une base persistante. Ainsi, il évite de refaire les mêmes vérifications après un postfix reload ou un redémarrage du service.

Le problème survient généralement lorsque Postfix tente d’utiliser le fichier verify_cache.db, mais que la configuration de la map de vérification n’est pas assez explicite. Le démon verify essaye alors de manipuler un cache qui n’existe pas encore, ou auquel le service n’accède pas correctement via proxymap.

À quoi sert verify_cache.db dans Postfix ?

Postfix peut vérifier une adresse expéditeur ou destinataire avant d’accepter définitivement un message. Il effectue alors une sorte de test SMTP, sans livrer réellement le courrier. Le résultat de cette vérification peut ensuite être conservé en cache.

Ce cache évite de solliciter inutilement les mêmes serveurs distants. Il accélère aussi les décisions de Postfix lorsqu’une adresse a déjà été testée récemment.

La documentation Postfix indique que le paramètre address_verify_map définit la base de données persistante utilisée pour ces résultats de vérification. Sans ce paramètre, les informations de vérification sont perdues après un postfix reload ou un arrêt du service.

En clair : le fichier verify_cache.db n’est pas une boîte mail. Ce n’est pas non plus un fichier vital contenant vos messages. C’est un cache technique utilisé par Postfix pour garder en mémoire les résultats des vérifications d’adresses.

PHP : remplacer APC par OPcache et APCu sur un serveur Linux

Publié le 27 mai 2026 by Matt Biscay · Lecture: 7 minutes

À une époque, installer APC depuis SVN sur un serveur dédié pouvait avoir du sens. APC, pour Alternative PHP Cache, servait alors à accélérer PHP en mettant en cache le code compilé, mais aussi à stocker des données applicatives en mémoire.

Ce temps est terminé. Aujourd’hui, il ne faut plus installer APC. Et encore moins depuis SVN, à la main, sur un serveur de production. Là, on n’optimise plus PHP : on invoque l’archéologie système.

La pile moderne est simple : utilisez OPcache pour le cache d’opcode PHP, puis ajoutez APCu uniquement si votre application a besoin d’un cache utilisateur local.