wismerhill a écrit 2598 commentaires

En SQL natif, tu fais ce que tu veux.
Ce n'est pas supporté en DQL de base, mais c'est relativement facile d'ajouter une fonction DQL sur mesure pour ça.

Je le trouve plutôt léger à l'usage, mais c'est vrai que je suis en bureau plasma.
Si tu préfère GTK, il y a gcstar dans le même genre.

Essaie tellico, c'est un gestionnaire de collections.
Il y a des types de collections pré-définis (livres, vins, jeux, …) auxquels on peut ajouter des champs personnalisés, vori vaire son type sur mesure.
On peut ensuite faire des recherches, ou des tris, sur base des différent champs.

De fait, c'est pour ça que la remarque que je pointe se trouve dans la section compatibility, c'est une déviation par rapport au standard SQL.
Ils indiquent que les contraintes déférées ont un impact sur les performances, je suppose que c'est pour ça qu'elles ne le sont pas par défaut.

Je dois dire qu'en une dizaine d'années à travailler avec PG, il ne m'est arrivé qu'une fois d'avoir l'usage pour des contraintes déférées (c'était une contrainte d'unicité).

C'est documenté, et il y a un contournement:
https://www.postgresql.org/docs/current/sql-createtable.html#id-1.9.3.85.9.4

Son problème d'origine est qu'il n'avait pas partitionné sdb, donc il n'y avait pas de partition d'origine et il ne pouvait pas en créer une nouvelle.

Sauf que …

Comme sont système de fichier est ext4, d'après https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Layout les 1024 premiers octets sont inutilisé.
Donc il aurait été également possible de créer une table de partition de type MBR (qui est placée dans les premiers 512 octets), pour ensuite créer une vrai partition au-delà de la zone où se trouve encore le FS, puis à coup de dd copier le FS dans la partition ainsi créée.
Ça évite de jouer avec losetup, mais c'est tout aussi tordu puisqu'on se retrouve avec un sdb "hybride" partitionné/non-partitionné.

Aurait-il été possible de faire la même opération sans table de partition ?

Il y a moyen, mais c'est tordu risqué.

pvcreate a une option --setphysicalvolumesize qui permet de forcer la taille utilisée.
On veut qu'il soit au début du volume, donc il faut décaler ton système de fichier à la fin.
Ça peut se faire à coup de dd (il y a peut-être des outils pour faire ça mieux/plus simplement), c'est la partie la plus risqué de l'opération.
Tu crée alors ton volume physique dans l'espace libéré, puis les goupes et volumes logiques normalement.
Après, tu as deux options.
Soit tu recopie ton FS qui traine encore à a fin de sdb dans un fichier, puis tu étends (avec pvresize) ton volume physique pour récupérer l'espace, et tu monte le fichier en loopback our recopier les fichiers (si tu n'a pas fait d'erreur avant).
Ou alors tu utilise losetup avec l'option --offset pour accéder directement à la fin de sdb en loopback, tu recopie les fichiers, et ensuite tu récupère l'espace avec pvresize.

Par contre, je ne comprend pas pourquoi tu te complique la vie à essayer de copier le système de fichier brut, ce sont les fichiers qui sont dedans qui sont importants, et ils prendront forcément moins de place que le FS complet.

Si c'est du bash, alors tu peux éviter la sous-commande:

for i in {1..3} ;do …

Non, ce n'est pas une récursion, ça s'apparente plutôt à une machine virtuelle (le programme s'exécute dans une machine virtuelle, qui est elle-même simulée par un programme qui s'exécute sur la machine réelle (ou elle-même virtuelle, pour continuer à imbriquer)).

En mode semi-graphique (ncurse dans le terminal), il y a ncdu qui est bien pratique.

(oups, déjà cité, j'aurais du lire jusqu'au bout avant de répondre)

Je ne vois pas ce que le firmware vient faire là-dedans, lire le système de fichier c'est le problème de l'OS que tu installe sur ta machine. Le firmware, au mieux (si c'est de l'UEFI), il cherchera une partition d'un type bien particulier et essaiera de la lire, donc il n'y a que celle-là qui doit bien correspondre au type défini. Et sinon (en mode MBR) il ne se soucie même pas des partitions.

Le type que l'on peut mettre au niveau de la table de partitions n'est qu'une indication (comme un plaque que tu accroche à ta porte d'entrée), elle ne contraint pas ce qu'on peut effectivement mettre dans la partition.

Rien ne t'empêche de définir une partition de type fat, puis de faire un mke2fs dessus.
Certains OS ne comprendront pas ce qui leur arrive si le système de fichiers ne correspond pas au type défini dans la table de partitions, mais un OS correct permettra au minimum de forcer le type de FS au montage, ou l'auto-détectera sur base du contenu réel de la partition.

Ça veut dire que si tu veux utiliser un nouveau type de système de fichier (par exemple btrfs), tu peux le mettre dans une partition au format MBR avec un type quelconque, du moment que tu fais le nécessaire pour qu'elle soit montée correctement.

Pourquoi les crevures et les mec qui n'ont pas un minimum de formation deviennent directeur ou responsable de service ?

Principe_de_Dilbert

Si ton objectif est seulement de pouvoir ré-utiliser l'espace, c'est plus simple de re-créer un groupe de volumes propre plutôt que d'essayer d'en réparer un qui est corrompu.

Si tu veux essayer de récupérer des données dont tu n'a pa de sauvegarde, il ne faut surtout pas modifier le VG actuel.
Utilise lvdisplay -m pour voir s'il y a des volumes encore complets.
Si oui, tu les monte en lecture seule et copie les donnes importantes ailleurs.
S'il y en a des partiels, ce n'est probablement pas la peine d'essayer de les monter, même en lecture seule. Tu peux tenter un photorec dessus, mais s'il manque beaucoup de blocs ça risque de ne pas donner grand chose d'utile.

Ça dépend de la façon dont tu avait organisé tes volumes logiques dans le groupe de volume qui contenait tes trois disques dur.
Les volumes qui sont entièrement sur les deux disques encore fonctionnels sont probablement récupérable, peut-être en forcer LVM à créer le groupe en mode dégradé.
Mais si certains des blocs d'un volume se trouvaient sur le disque mort, ce sera difficile d'y retrouver des choses cohérentes.

Si tu crées un lien dur avec ln (sans l’option -s) ou cp -l, c’est juste un deuxième inode, tout-à-fait similaire au premier, qui pointe vers les mêmes données.

Correction: il n'y a qu'un seul inode, c'est lui le point d'entrée vers les données (tu peux vérifier avec ls -i qui te donne le numéro de l'inode).
Ensuite, il peut y avoir un certain nombre de noms (dans n'importe quel répertoire du même système de fichier) qui pointent vers cet inode.
L'inode lui-même contient un compteur⁽¹⁾ du nombre de liens physique qui pointent vers lui.

Supprimer un fichier consiste en fait à supprimer le nom dans le répertoire correspondant et décrémenter le compteur de liens dans l'inode.
Si le compteur tombe à zéro (et que plus aucun programme n'utilise l'inode⁽²⁾), alors seulement l'inode, et toutes les donnés associées, sont libérés.

⁽¹⁾ c'est le champ "link count" dans la page de manuel "inode"
⁽²⁾ c'est pour ça que, dans certains cas (typiquement un fichier de log), l'espace du fichier n'est pas tout de suite rendu

À part pour le support de macOSX, systemd répond complètement à ton besoin.
Et si tu utilise déjà systemd au niveau du système, alors il y a déjà une instance utilisateur qui est lancée quand tu te connecte et tu peux en gérer les services dans ~/.config/systemd/user/ et avec la commande systemctl --user

Installe la version ESR, l'actuelle est la 68.

Java, depuis la version 11:
https://openjdk.java.net/jeps/330
ils ont prévu un cas particulier pour le shebang

Non, les window functions ("fonctions fenêtrées", ça fait bizarre, ou alors "fonctions sur une fenêtre") ont été introduites dans MySQL 8.0 (et MariaDB 10.2).

(PostgreSQL les a depuis déjà 10 ans, avec la version 8.4)

Argh!
Ce fil de discussion me fait découvrir plein de jeux de mots cachés que je n'avais jamais remarqué avant.
Si ça continue, il sera difficile de garder son sérieux dans les discussions techniques.

Ajoute l'option -vv pour que rsync te donne plus d'informations sur ce qui se passe et les erreurs rencontrées.

On ne peut pas éviter les blocs défectueux sur un SSD, car le controlleur fait du wear leveling, il redistribue en permanence les blocs physiques dans les blocs logiques qui sont présentés au système.
S'il y a vraiment des blocs défectueux visibles par le système (par exemple avec badblocks) alors le SSD est au-delà de sa fin de vie.

Mais il faudrait plutôt savoir ce que ce "bon état" signifie, je doute que ça corresponde à des blocs défectueux, c'est plus probablement une estimation du wear leveling.

Tant que les certificats seront payants, renouvelés manuellement

https://letsencrypt.org/

Let’s Encrypt is a free, automated, and open Certificate Authority.

En écriture il devrait avoir les mêmes performances qu'un disque seul, et en lecture il peut être nettement meilleur s'il y a des accès concurrents.