Solution communautaire

Définir une limite de stockage pour les dossiers d’utilisateurs partagés sur ZimaOS

A ZimaOS+ user wanted one private folder per employee with a fixed storage cap and also noticed a newly created RAID1 felt unusually slow.

En bref : le partage de ZimaOS contrôle l’accès, mais l’interface actuelle ne documente pas de quota fixe de capacité par dossier

La demande était simple : attribuer à chaque employé un dossier privé et le limiter à 4 To. Les autorisations de compte et de partage de ZimaOS peuvent contrôler qui voit un dossier, mais la documentation publique actuelle ne présente pas de commande native permettant de limiter la consommation d’un dossier partagé à X To. Le contrôle des accès et le quota de stockage sont deux fonctions distinctes.

Pour appliquer des quotas stricts, utilisez une application qui gère le stockage des utilisateurs

Nextcloud est la solution la mieux adaptée à cette exigence multiutilisateur précise. Son manuel d’administration actuel prend en charge les quotas par utilisateur, y compris les valeurs personnalisées telles que 5 To. Consultez la documentation de Nextcloud sur les quotas utilisateur.

Le guide matériel de Nextcloud aide à dimensionner séparément le stockage de la base de données et de l’application, ainsi que l’espace réservé aux fichiers des employés. Le guide des autorisations SMB de ZimaOS est préférable lorsque vous avez uniquement besoin de gérer les autorisations des dossiers.

La lenteur de la grappe n’était pas due à un problème de quota

Tableau de bord système de ZimaOS affichant une utilisation très faible du processeur et de la mémoire vive pendant l’exécution d’une tâche de stockage
Le tableau de bord du système semblait presque inactif alors que la couche de stockage était encore en cours de reconstruction. C’est pourquoi la progression du RAID, et non l’utilisation du processeur, constituait l’indicateur utile.
Page de stockage de ZimaOS affichant une resynchronisation RAID1 à 3 %, avec plus de 27 heures restantes
La page de stockage a confirmé la véritable raison de la lenteur de la nouvelle grappe : le RAID1 était encore en cours de resynchronisation sur l’ensemble des disques.

Le RAID était simplement en cours de reconstruction. Même un RAID vide doit resynchroniser les blocs sur les disques membres ; une faible utilisation du processeur ne signifie donc pas que les opérations de stockage sont terminées. Le guide RAID actuel de ZimaOS précise que les opérations de parité et de reconstruction peuvent réduire les performances de stockage pendant l’initialisation de la grappe.

Vérifiez l’état de la reconstruction avant de mesurer les performances ou de migrer des données

cat /proc/mdstat
sudo mdadm --detail /dev/md0

Le manuel de mdadm constitue la référence en amont pour l’état de la grappe. Ne jugez pas la vitesse normale des transferts avant que la resynchronisation n’atteigne 100 %.

Organisation recommandée du stockage des employés

  • Vous avez uniquement besoin de dossiers privés : utilisateurs ZimaOS + autorisations SMB.
  • Vous avez besoin de plafonds de capacité par utilisateur : utilisateurs Nextcloud + quotas.
  • Vous avez besoin de quotas au niveau du système de fichiers : outils Linux avancés, mais ne supposez pas que l’interface de ZimaOS gère ou conserve cette configuration après les mises à jour.

Ainsi, le mécanisme de quota reste au niveau qui gère réellement le modèle de stockage des comptes utilisateur.