Cet article présente un problème classique de mauvais montage de certains File Systems (FS) au démarrage d’un serveur AIX.
Le problème rencontré se traduit par un mauvais montage de certains File Systems (FS) au démarrage d’un serveur AIX. Une partie des FS sont montés sur un LV qui n’est pas celui défini sous /etc/filesystems.
Exemple :
Avec un fichier /etc/filesystems paramétré avec les FS dans l’ordre du tableau précédant on va avoir les montages suivants :
/root -> lvroot : OK
/home -> lvhome : OK
/app/apache -> lvapp : KO (il devrait être monté sur lvapache)
/app/oracle -> lvoracle : KO (il devrait être monté sur lvoracle)
/app -> lvapp : OK
Dans l’exemple précédent c’est l’ordre de déclaration des FS dans le fichier « filesystems » qui pose problème. En effet on va monter une sous-arboresence (/app/oracle et /app/apache) avant de monter le FS parent (/app). Donc le system va bien monter les FS dans l’ordre indiqué et ainsi les montages /app/oracle -> lvoracle et /app/apache -> lvapache vont être écrasés par le montage de /app -> lvapp.
Il suffit de modifier l’ordre de déclaration des FS dans le fichier « /etc/filesystems » de manière à ce que les FS des répertoires « parents » soient montés avant les FS des répertoires fils.
Ce qui donne donc l’ordre suivant dans notre exemple :
Découvrez la planche #57 !
Dans une base de données relationnelle, la plupart des tables possèdent une clé primaire appliquée sur un seul champ. Cependant, une clé primaire peut s’appliquer à plusieurs d’entre eux : on parle de clé primaire composée.
Est-ce que le futur développeur sera prompt engineer ? Le métier de développeur a toujours évolué avec ses outils. De la simple chaise et du clavier à l'émergence des IDE, chaque génération d'outillage a redéfini la façon de coder. Aujourd'hui, c'est l'IA qui s'invite dans l'équation, et elle ne se contente pas d'ajouter un outil de plus dans la boîte. Ce qui change vraiment, c'est la manière d'interagir avec son code.