Réponses confuses

Bonjour les Linuxiens,

Je m’apprête à passer une certification Linux : la LPIC-1 (www.lpi.org) Pour m’y entrainer, j’ai trouvé sur le net des PDF d’un organisme “Testking”. Mais voilà, dans leur différents documents, ils ne mettent pas la même réponse à certaines de leur questions. Pire, c’est truffé d’erreur mais bon, je me suis fait une raison et les vieilles versions sont offertes gracieusements …

Par exemple, à la question

J’ai eu le droits aux réponses B ou D en fonction de la version du PDF. Mais du coup, laquelle est la bonne ? Les deux hyppothèses peuvent ne pas prendre bcp d’espace disque mais pomper une inode à chaque fois … même si j’ai un petit penchant pour la D.

Votre avis ?


C'est quoi ce binz, je peux pas ajouter de thème à mon sujet comme "[Certification LPI] Réponses confuses" ? :-(: Edité le 20/01/2009 à 16:00

Hum… moi j’aurais penche pour A et B… je crois pas que les symlinks utilisent une inode…

Quoiqu’il en soit, mefie toi des pseudo-annales pour ce genre de certifs… deja pour les “grandes” certifs (cisco, MS, etc), on trouve
enormement d’annales pourries alors j’ose pas imaginer ce qu’on peut obtenir pour une certif aussi jeune et peu repandue que la LPI.

Sisi regarde :


[16:12:32][tom@host:/tmp (0 M)]$ touch file1

[16:12:38][tom@host:/tmp (0 M)]$ stat file1
  File: `file1'
  Size: 0               Blocks: 0          IO Block: 4096   fichier régulier vide
Device: 302h/770d       Inode: 629621      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/     tom)   Gid: ( 1000/     tom)
Access: 2009-01-20 16:12:38.000000000 +0100
Modify: 2009-01-20 16:12:38.000000000 +0100
Change: 2009-01-20 16:12:38.000000000 +0100

[16:12:41][tom@host:/tmp (0 M)]$ ln file1 file2

[16:12:48][tom@host:/tmp (0 M)]$ stat file2
  File: `file2'
  Size: 0               Blocks: 0          IO Block: 4096   fichier régulier vide
Device: 302h/770d       Inode: 629621      Links: 2
Access: (0644/-rw-r--r--)  Uid: ( 1000/     tom)   Gid: ( 1000/     tom)
Access: 2009-01-20 16:12:38.000000000 +0100
Modify: 2009-01-20 16:12:38.000000000 +0100
Change: 2009-01-20 16:12:48.000000000 +0100

Avec un lien hard, il ont la même inode.


[16:12:51][tom@host:/tmp (0 M)]$ ln -s file1 file3

[16:14:19][tom@host:/tmp (0 M)]$ stat file3
  File: `file3' -> `file1'
  Size: 5               Blocks: 0          IO Block: 4096   lien symbolique
Device: 302h/770d       Inode: 629625      Links: 1
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/     tom)   Gid: ( 1000/     tom)
Access: 2009-01-20 16:14:19.000000000 +0100
Modify: 2009-01-20 16:14:19.000000000 +0100
Change: 2009-01-20 16:14:19.000000000 +0100

Avec un lien sym, l’inode est différente.

Pour ta remarque, je ne le sais que trop bien … mais il faut bien s’entrainer … C’est bcp de buchage la LPI … :frowning:

Ceci dit, en regardant de plus prêt, on voit qu’un fichier pompant une inode peut-être plus petit que la même quantité de lien sym … On peut donc partir du principe que bcp de lien sym satureront le FS alors que pleins de fichiers de moins de 5 block le rempliront moins … ?:!
Edité le 20/01/2009 à 16:18

B


Pour le A je ne crois pas, car un nouveau inode est créé, mais l'espace est également dupliqué non?
Pour le D, possible mais tu vas saturer le nombre de symlinks possibles bien avant le nombre d'inodes possibles il me semble ?? (à confirmer)

hum je crois pas… justement, l’interet du hardlink est d’avoir 2 references sur le meme fichier. Donc pas de duplication de donnees…

Effectivement


Edit : par contre je ne comprends pas ce qu'on doit comprendre par too many hardlink are [b]in use[/b] [u]on home[/u]

Trop de lien sont “in use”, ça suggère que “les contenus des fichiers sont ouverts en I/O”, plus que “trop de liens sont créés”
De plus je ne vois pas ce que vient faire “on home” parce que ça ne dépend pas du répertoire ou de la partition (enfin si, mais pas tel que c’est présenté au moins)
Edité le 20/01/2009 à 21:25

hum… je pense que c’est la formulation de la question est un peu foireuse… :ane:

Je ne savais même pas qu’il y avait une limite distinct pour les liens … je vais regarder çà de plus prêt …


Pour l'histoire du home ... c'est parcequ'il introduise la question en indiquant qu'un utilisateur s'est retrouvé à ne pas pouvoir écrire sur son FS alors qu'il lui restait de la place libre -> problème d'inode mais à cause de qui, des fichiers ou des simlinks :pt1cable:

[quote="[B2F]Tom"] problème d’inode mais à cause de qui, des fichiers ou des simlinks :pt1cable:
[/quote]

les 2 me paraissent tout a fait possibles…
De tres petits fichiers inferieurs en taille a un bloc peuvent foutre une merde de ce genre.
Neanmoins, il faut aussi comment est calculee le volume de disque disponible. Peut etre qu’il calcule les blocs occupes et non pas la taille reelle des fichiers ecrits.

Bon, la réponse restera un mystère alors parcequ’on en est arrivé à la même conclusion tous les trois : les deux sont possibles …
Reste à espérer que je tomberai pas sur une question de ce type là …
Allez, je retourne travaillez, merci à tous les deux !

y’a une limite au symlinks récursifs lwn.net…

pour moi la réponse D est contenu dans la réponse B. Car pour arriver à limite d’inodes disonibles avec que des symlinks il faudrait que tous les fichiers aient plusieurs liens symbolique pointant vers eux. Ce qui semble assez peu probable
De plus un symlink peut être considéré comme un fichier puisqu’il prend un inode et occupe de l’espace disque
Et puis il a aussi les fast symlinks qui eux ne prennent pas d’inode mais occupe une zone supplémentaire de l’inode du fichier vers lequel ils pointent