Bonjour tout le monde 
A bientôt !
Il y a une erreur dans le titre.
Il s’agit du Jeudi 02/10/2025.
A bientôt!
Gascogne
Nous avons essayé de progresser sur le projet d’entre-hébergement de grille garage (stockage S3 hébergé sur plusieurs nœuds répartis chez des membres).
De notre point de vue, nous considérons que le package YunoHost n’est pour l’instant pas assez qualitatif. En effet pour simplifier son installation et mettre en place un quota facilement, il utilise un fichier qcow2 formaté en ext4.
Après discussions sur les chats Deuxfleurs et lecture de la doc de garagehq, nous pensons qu’il serait souhaitable d’ajouter la possibilité d’utiliser des partitions directement.
gaut
are these Best practices still up-to-date with garage v2 ? https://garagehq.deuxfleurs.fr/documentation/cookbook/real-world/#best-practices Especially regaring filesystems, HDD/SSD, and types of DB for data and metadata.
Could a cluster work with 1 or all nodes shutdown at night ?
here is our start with garage https://forum.chatons.org/t/monter-un-cluster-garage-avec-yunohost-pour-heberger-des-backups/7606
En lisant la doc’ Deployment on a cluster | Garage HQ voilà ce que je commence en suivant XFS : la puissance Linux pour gros volumes | DevSecOps : Créer une partition /dev/sdX1 sudo fdisk /dev/sdX Command (m for help): n Partition number (1-128, default 1): First sector (34-15628053134, default 2048): Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-15628053134, default 15628053134): +7812500000 (4000000000000/512 bytes) Created a new partition 1 of type ‹ Linux filesystem › and of size 3…
I installed the v2 with https://github.com/YunoHost-Apps/garage_ynh/tree/testing
We are wondering why qcow with ext4 is used for data_dir https://github.com/YunoHost-Apps/garage_ynh/blob/testing/conf/mount_disk.sh which does not fit above mentioned Best Practices
ljf
(we are able to fix the ynh package if needed, but for that we need to understand in a better way garage logic and general usecases.
garder
gaut
are these Best practices still up-to-date with garage v2 ? https://garagehq.deuxfleurs.fr/documentation/cookbook/real-world/#best-practices Especially regaring filesystems, HDD/SSD, and types of DB for data and metadata.
As you seem french (like me) maybe :
#tech:deuxfleurs.fr could be better to discuss about garage ? 
trinity-1686a (it/its)
that channel is more meant for general discussion about tech and deuxfleurs’s own infra, than a q&a channel for garage in french. We may talk about garage in there, but usually related to our specific deployment
Max
ljf XFS is recommended, but there are no real reasons not to use EXT4
Not sure why the disk is wrapped in a qcow image, but I’m very unfamiliar with yunohost, so it might be a standard way to handle application data?
In any way, it’s a bit of an overhead, it would be better to have it directly on the host, but I don’t see why it would be a problem, and it allows for allocating a defined portion of disk I guess
Ensures that you don’t fill your disk
(garage itself doesn’t « limit » in any way the amount of data stored, what you put in the layout is simply indicative to balance data between hosts)
ljf
I think packagers have made that in order to make the setup working on all type of configuration. YunoHost is FS agnostic (for now) so it could be installed on a lot of distinct fs.
Max
Not sure why the disk is wrapped in a qcow image, but I’m very unfamiliar with yunohost, so it might be a standard way to handle application data?
I think packagers have made that in order to make the setup working on all type of configuration. YunoHost is FS agnostic (for now) so it could be installed on a lot of distinct fs.
Max
Well then they are misguided, to my knowledge there are very few downsides running garage on any FS really
As long as it is not NFS of course
(or CIFS)
ljf
That a good point, cause somebody asked me specifically this question (NFS…) I said i was thinking it was not a good idea.
Max
TBH for the data it should work?
don’t try to put the metadata on it though
ljf
And what abvout multi disk setup on one node with old SSD ? I guess it could cause some issues ?
Max
don’t try to put the metadata on it though
we have seen that ssd are better idea for metadata part
Max
You mean using multiple old SSDs for the data volumes? With the muti-disk feature?
ljf
Max
You mean using multiple old SSDs for the data volumes? With the muti-disk feature?
yes
Max
Sure why not, the data part doesn’t really move that much unless you delete and write your S3 objects constantly
Just be careful for the metadata part to use a SSD with solide flash (look at the TBW rating - number of TB you can write on the drive before the flash wears out)
the metadata part is very write-intensive
if you use an entry-level drive or an old drive, it can die in a couple of years or less depending on cluster activity
ljf
What happens if we have 3 nodes which 1 node has 8 data disks, and one of this datadisk crash (or made some errors).
Could this disk poisoning the cluster ? Could we replace this disk without rebuilding the node with several disks entirely ?
Max
There are many ways for a disk to die
But in most cases the disk will just be unreachable
and garage will be unable to read the blocks on it
the node will continue to work otheriwse, and garage will continue to serve requests for the blocks it can read on other disks
you can then stop garage, replace the disk and initiate a repare
garage will scan the local blocks, and download the missing blocks for the disk you replaced from other nodes
Concernant les noeuds envisagés:
On tente de monter un projet collectif avec d’autres chatons.
Il n’est pas encore très clairs si il doit s’agir d’un site de présentation tchatons.org qui amène vers des serveurs matrix OU si c’est directement un serveur matrix.
Un des problèmes c’est la complexité qu’engendre le fait de devoir lier le client avec le serveur. Il y a les mêmes difficultés avec le mail.
Il a été décidé de mettre la priorité sur les discussions sur le salon dédié pour se mettre d’accord sur le projet ET de creuser le sujet des configurations recommandées.
En attendant, il est aussi tout à fait possible d’expérimenter sur une VM différentes méthodes de maintenance (ansible etc).
Rappel le but du projet est de séparrer les bridges du serveur sans-nuage.fr . Il y aurait donc 2 instances matrix, mais les comptes sans-nuage.fr pourront continuer d’utiliser les bridges.
Le but de l’opération est de faciliter la maintenance et la montée de version.
2 points bloquants:
A dornbirn, on m’a demandé comment on travaillait (hardware, data centre, ASIN, peering) .
J’ai pas été capable de répondre plus que « cogent ».
Ce serait bien d’avoir un slide sur l’infra du data center, car c’est à mon avis un de nos Unique Selling Proposition. Qui 'sen occupe?
A Dornbirn, on a parlé pas mal du thème d’un possible embargo americain sur les servers (Sharpoint, Google-Drive, AMazon) en Europe, pour faire pression politique. A quel point serait ARN capable à continuer à fonctionner? Serait-ce un USP pour nos membres, pour nos membres à venir?
