Utilisant depuis peu un serveur sous proxmox pour la virtualisation, avec du ZFS pour la gestion du raid soft et des "partitions" des VM, j'ai eu la surprise de voir une utilisation complètement folle de la RAM d'après les outils classiques (top/free/htop).
Il s'agit apparemment d'un cache ARC utilisé par ZFS qui est supposé être meilleur dans le cadre d'un serveur de fichiers (ce qui du coup n'est pas le cas mais est un cas fréquent).
D'après https://superuser.com/questions/1137416/how-can-i-determine-the-current-size-of-the-arc-in-zfs-and-how-does-the-arc-rel :
Because of how ZFS on Linux is implemented, the ARC memory behaves like cache memory (for example, it is evicted if the system comes under memory pressure), but is aggregated by the kernel as ordinary memory allocations.

Pour regarder :
arcstat, /proc/spl/kstat/zfs/arcstats, arc_summary

Pour jouer un peu :
https://www.svennd.be/tuning-of-zfs-module/
pour le désactiver :
zfs set zfs set secondarycache=none rpool
zfs set secondarycache=none rpool
cela réagit bien à un drop des caches (mais pas complètement, moi il restait dans les 400 méga) :
echo 3 > /proc/sys/vm/drop_caches

Pour l'instant j'ai remis, c'est supposé être capable de réagir en cas de demande de mémoire (mais pas toujours : some applications will require a certain amount of memory to start, or request memory on a rate that is quicker then ARC size can lower, resulting in a crash/swapping). Je verrai bien mais il vaut mieux être prévenu…

Un gros disque formaté en ext4 et de l'activité lente bizarre une fois monté ? C'est juste une étape d'initialisation qui se fait en arrière-plan : ext4lazyinit.

Je voulais faire un miroir chiffré de mes photos à distance qui soit simple, et sans trop de configuration à refaire en cas de problème. Pas de sauvegarde, pas d'incrémental ou quoi que ce soit, juste une copie de sécurité (cas où y'a l'feu quoi).
Là de base, on pense à rsync et ssh. Restait à trouver la partie chiffrement, avant transfert de préférence. J'ai déjà touché à ecrypts mais pas toujours très bien compris comment ça fonctionne et comment refaire le montage sur une autre machine (on y arrive mais des clefs sont dans un keyring lié à la session etc.). On trouve rsyncrypto qui chiffre d'une manière compatible avec la synchronisation des modifications (comme par rsync). Mais il faut donc une copie des données chiffrées avant de lancer le rsync. Pas le bon plan si on a des données qui peuvent potentiellement devenir volumineuses.
Encfs est une solution : entièrement userspace, simple à initialiser et utiliser.

On peut donc imaginer : données ⇒ rsync ⇒ encfs ⇒ sshfs vers le serveur distant.

Facile à mettre en place pour un administrateur système :
sshfs serveur:stockage montage-sshfs
encfs montage-sshfs montage-encfs
rsync -vriit données montage-encfs

Lorsque le dossier source d'encfs n'est pas encore initialisé, on nous demande ce qu'on veut comme option et un mot de passe. Les options sont enregistrées par défaut dans .encfs6.xml à la racine du dossier chiffré, donc sur le serveur distant. C'est pas forcément le plus malin mais au moins tout est au même endroit.

À noter :

• L'arboresence est recréée côté chiffrement, mais les noms sont masqués (hashage/chiffrement) ;
• Si on supprime un fichier chiffré ou si on démonte le sshfs (sauvagement, parce qu'il y a un problème réseau, …) l'encfs n'affiche juste plus les fichiers qu'il n'atteint pas, sans erreur. Si on remet en place, tout repart immédiatement.
• Avec les paramètres dans un fichier côté serveur distant, on n'a besoin que du mot de passe pour retrouver les données depuis n'importe où.
• Monter le sshfs avec -o idmap=user si on a des UID différents entre utilisateur local et distant.

Je me suis fait un petit script pour ne pas avoir besoin de reconstruire à chaque fois l'assemblage, et qui permet donc de faire un miroir de n'importe quoi n'importe où facilement (tant qu'il y a ssh sur le serveur distant et les 3 outils en local).

Envie d'accéder à un disque externe / clef USB / stockage quelconque de manière permanente sur un serveur sans se poser de question type fstab / autofs ?
Ce script tout simple qui se fait lancer par une règle udev est peut-être une solution. En tous cas quand ça fonctionne c'est tout simple et pratique : on a un mount.d / umount.d pour balancer des scripts si besoin et un lien est créé pour nous donner un point de montage fixe (pas comme un dev ou autre qui peut varier).

Tips :

• Pour voir si usbmount serait bien lancé par udev (et plein d'autre choses par rapport à l'événement déclencheur) : udevadm test --action=add /sys/class/block/sdxn
• Pour trouver le nom donné au système de fichiers trouvé sur le support : mettre en verbeux dans la conf puis lire syslog
• Pour déclencher l'événement udev d'ajout de stockage sans avoir à le faire physiquement : echo add | sudo tee /sys/block/sdx/sdxn/uevent
• Si on veut aussi le label de la partition en lien dans /var/run/usbmount, ajouter le bout de script qui nous arrange ; on peut obtenir ce label avec : /sbin/blkid -p "$UM_DEVICE" -s LABEL -o value

Attention : ne fonctionne pas si on a un système de fichier monté en userspace (ntfs/exfat ou tout autre FS qui passe par FUSE). Voir https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774149 (assez long, en gros udev utiliise les cgroup et clean tout à la fin de la gestion de l'événement). Pour l'instant j'ai contourné de manière crade en éditant le script et en passant par at pour sortir du cgroup : echo mount […] | at now
Voir : http://unix.stackexchange.com/questions/28548/how-to-run-custom-scripts-upon-usb-device-plug-in/28711#28711

Bref ce n'est pas si simple au final même s'il y a quasiment rien dans ce script…
On ne peut pas trop éviter le petit tour par la doc avant de commencer : zless /usr/share/doc/usbmount/README.gz

Une table de partitions GPT est écrite au début de l'espace partitionné, mais aussi en backup au bout (voir schéma sur la page). Il y a donc une certaine symétrie. Et évidemment, on ne peut pas définir de partition après la table secondaire. Donc dans certains cas (agrandissement de disque virtuel, boîtier externe qui coupe artificiellement à 2To, …) on risque d'avoir un problème (pour moi, avec gdisk, ça s'est manifesté par le "last usable sector").
Comme il n'y avait rien sur le disque, j'ai juste recréé une table de partitions vide.
Apparemment, pour remettre la table secondaire à la fin, on peut utiliser sgdisk -e (je n'ai pas testé).

Un outil que j'utilise de temps en temps pour faire du ménage en terme de place disque, c'est baobab (en GTK, de GNOME). Je me suis déjà dit que ça serait cool pareil mais en terminal, même si baobab permet de travailler à distance (gvfs powa).
Je viens de voir passer "ncdu", un "du" en ncurses et j'ai testé vite fait ; c'est pas mal, ça remplace bien, a l'air pratique et tout. Petit outil que je sens va me servir de temps en temps. Packagé dans Debian :)

Via #tuxfamily

Un système de fichier basé sur FUSE, qui produit une vue rassemblée de N systèmes de fichiers, par exemple plusieurs disques durs. On a donc toujours accès aux différents systèmes de fichiers normaux sous-jacents, le module se débrouille juste pour unifier les accès et répartir les fichiers.
Par défaut il remplit dans l'ordre un système de fichier après l'autre, en laissant 4Go libres avant de passer au suivant. On peut modifier cela, en mettant par exemple un seuil à 25% de libre (pour éviter la fragmentation etc.). J'ai testé et à partir de 1.4To remplis (sur un disque de 2) il est passé sur le suivant.
Beaucoup moins bancal que d'agréger via LVM où on n'a alors qu'un seul système de fichier qui est à cheval sur les disques, et donc on perd potentiellement tout si un seul tombe en panne. Et j'aime bien le côté rassurant de voir ses fichiers directement sur les disques, contrairement à du RAID.

Besoin de faire un dd pour par exemple remplacer en recopiant entièrement un disque qui est en train de tomber ? ddrescue peut faire ça mieux qu'un bête dd, dans la mesure où il est prévu pour les erreurs.
Merci lg pour m'avoir remis ça sous le nez au bon moment :D

Donc procédure complète de resize (agrandissement) de VM sans rebooter, avec ou sans LVM et avec ext4 (qui supporte l'agrandissement à chaud) :

• le faire au niveau hyperviseur (block_resize sous qemu)
• si c'est pas auto, faire détecter la nouvelle taille par Linux (echo 1 > /sys/class/scsi_device/1\:0\:0\:0/device/rescan en changeant le 1 si nécessaire), avec virtio c'est immédiat, sous vmware il faut le faire
• utiliser resizepart de parted pour redimensionner les partitions, c'est plus simple que détruire/recréer avec fdisk donc moins de risque d'erreur
• si LVM, pvresize du volume physique et lvextend -l +100%FREE du LV
• resize2fs

… et du coup j'ai repéré de la place libre derrière une de mes partitions trop pleines, et j'ai eu le courage de faire la manip pour l'utiliser. Par contre, j'ai eu le même truc bizarre de bornes/intervalle et dû faire le +1 aussi.

Principe de passage d'une topologie 2×2 à 3×2 avec glusterfs. Attention : le replace-brick existe plus (voir : http://review.gluster.org/#/c/8503/2/doc/admin-guide/en-US/markdown/admin_replace_brick.md).
Attention aussi (version 3.4.2, ça a pu passer dans un bugfix entretemps…) : à l'ajout des nouvelles briques, la topologie change mais les briques n'ont pas encore les arborescences ni les liens vers les vraies données qui elles sont encore sur les autres briques. Il faut faire un rebalance. Cette opération peut être très longue donc, en attendant, on peut faire un rebalance fix-layout (long mais beaucoup moins) qui met uniquement à jour les informations de layout des fichiers/dossiers etc.
En tous cas c'est un moment de grand stress quand on voit les messages d'erreur qui pleuvent dans les logs…

Sur cette page, un peu de doc sur CTDB, que je découvre (avec un certain intérêt, je dois avouer). Pour l'instant, après les deux/trois problèmes de mise, ça marche plutôt bien.
Avec ça, samba et glusterfs, et un DNS avec round-robin, ça devrait finir par être une solution de stockage pratique, facile à faire évoluer, et avec des implémentations entièrement libres ! (Oui il y a du CIFS, protocole Microsoft etc. mais on peut pas encore complètement ignorer windows, et c'est le seul qui a des ACL par utilisateur que je connaisse.)

Ma doc sur glusterfs. Au final on a décidé de l'utiliser au boulot, donc j'ai un peu joué avec… il y a de quoi se faire une idée du soft je pense.

Mes notes au taff sur samba, avec du LDAP derrière et qui pompe directement dans glusterfs (sans le montage FUSE alakon). Ça juste marche.