Notion de lien pour un dossier et connaître la taille d'un bloc sur un système de fichier

Le
Francois Lafont
Bonjour à tous,

En lisant deux trois choses sur Linux, j'ai été amené à me poser deux
questions un peu "théoriques" pour lesquelles je n'arrive pas à avoir de
réponse claire.


1) Je comprends bien (enfin je crois) ce qu'est un lien non symbolique
pour un fichier standard et j'ai bien vu qu'un tel type de lien
n'existait pas pour les fichiers de type dossier. Mais alors dans ça :

$ stat /
File: «/»
Size: 4096 Blocks: 8 IO Block: 4096 répertoire
Device: 801h/2049d Inode: 2 Links: 22
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2010-11-01 14:37:45.000000000 +0100
Modify: 2010-11-01 12:17:09.000000000 +0100
Change: 2010-11-01 12:17:09.000000000 +0100

Que signifie exactement "Links 22" ? Empiriquement, j'ai constaté que ça
correspondait aux nombres de dossiers contenus dans "/" (si on compte
les dossiers . et .. aussi). Mais alors pourquoi appeler ça "Links" ?


2) Comment faire pour connaître la taille en octet d'un bloc (au sens de
http://fr.wikipedia.org/wiki/Bloc_%28disque_dur%29) sur son système de
fichiers ?

J'ai ceci :

#-
# dumpe2fs -h /dev/sdb1 | grep 'Block size'
dumpe2fs 1.41.11 (14-Mar-2010)
Block size: 4096
#-

où j'en déduis que un cluster (bloc) vaut 4096 octets sur sdb1. Mais par
ailleurs, j'ai ça :

#-
# sfdisk -l -uB /dev/sdb

Disque /dev/sdb : 19457 cylindres, 255 têtes, 63 secteurs/piste
Unités= blocs de 1024 octets, décompte à partir de 0

Périph Amorce Début Fin #blocs Id Système
/dev/sdb1 31+ 156288352- 156288321 83 Linux
/dev/sdb2 0 - 0 0 Vide
/dev/sdb3 0 - 0 0 Vide
/dev/sdb4 0 - 0 0 Vide
#-

qui m'incite à penser qu'un bloc fait 1024 octet. Il me semble bien que
la réponse est bien 4096 octet (d'après google). Alors que représente ce
1024 octet exactement ?

Merci d'avance pour vos lumières.


--
François Lafont
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #22746841
Salut,

Francois Lafont a écrit :

1) Je comprends bien (enfin je crois) ce qu'est un lien non symbolique
pour un fichier standard et j'ai bien vu qu'un tel type de lien
n'existait pas pour les fichiers de type dossier.



Bien sûr que si. De ce point de vue, un répertoire est un inode comme un
autre. Seulement on ne peut pas en créer n'importe comment, sinon on
pourrait provoquer des boucles dans l'arborescence.

Mais alors dans ça :

$ stat /
File: «/»
Size: 4096 Blocks: 8 IO Block: 4096 répertoire
Device: 801h/2049d Inode: 2 Links: 22


[...]
Que signifie exactement "Links 22" ? Empiriquement, j'ai constaté que ça
correspondait aux nombres de dossiers contenus dans "/" (si on compte
les dossiers . et .. aussi). Mais alors pourquoi appeler ça "Links" ?



Parce que c'en est. Un pour le lien depuis le répertoire parent, un pour
le "." depuis le répertoire lui-même et un pour le ".." dans chaque
répertoire fils.

# dumpe2fs -h /dev/sdb1 | grep 'Block size'
dumpe2fs 1.41.11 (14-Mar-2010)
Block size: 4096


[...]
# sfdisk -l -uB /dev/sdb

Disque /dev/sdb : 19457 cylindres, 255 têtes, 63 secteurs/piste
Unités= blocs de 1024 octets, décompte à partir de 0


[...]
qui m'incite à penser qu'un bloc fait 1024 octet. Il me semble bien que
la réponse est bien 4096 octet (d'après google). Alors que représente ce
1024 octet exactement ?



4096 est la taille d'un bloc du système de fichiers ext2/3/4 qui est sur
sdb1. 1024 est une taille de bloc arbitraire utilisée par sfdisk pour
l'affichage. La taille d'un secteur "visible" du disque sdb est
probablement 512 octets, comme sur la plupart des disques actuels. On
commence à voir des disques avec des secteurs physiques de 4096 octets,
mais la taille visible reste 512 par compatibilité.
Francois Lafont
Le #22747651
Le 01/11/2010 17:54, Pascal Hambourg a écrit :

1) Je comprends bien (enfin je crois) ce qu'est un lien non symbolique
pour un fichier standard et j'ai bien vu qu'un tel type de lien
n'existait pas pour les fichiers de type dossier.



Bien sûr que si. De ce point de vue, un répertoire est un inode comme un
autre. Seulement on ne peut pas en créer n'importe comment, sinon on
pourrait provoquer des boucles dans l'arborescence.



Ah, mais alors est-ce que tu as un exemple reproductible à me proposer ?
Personnellement, j'ai essayé ça :

#--------------
$ mkdir dossierPipeau
19:52 ~/Bureau

$ ln dossierPipeau/ dossierPipeau2
ln: «dossierPipeau/»: lien direct non permis pour un répertoire
#--------------

Et le message me dit que je ne peux pas créer un lien direct
(c'est-à-dire non symbolique) sur un répertoire.

Que signifie exactement "Links 22" ? Empiriquement, j'ai constaté que ça
correspondait aux nombres de dossiers contenus dans "/" (si on compte
les dossiers . et .. aussi). Mais alors pourquoi appeler ça "Links" ?



Parce que c'en est.



C'est une bonne raison, en effet. :-)

Un pour le lien depuis le répertoire parent, un pour
le "." depuis le répertoire lui-même et un pour le ".." dans chaque
répertoire fils.



Je si comprends bien :

* un fichier (et/ou dossier) est caractérisé de manière unique par son
numéro d'i-node.
* un dossier est un petit fichier dont le contenu peut se voir une sorte
de tableau où les entrées sont de la forme (numéro d'i-node ; nom), un
peu comme ce que retourne la commande "ls -1ia mon_dossier".
* un lien direct vers un fichier (et/ou dossier) d'i-node N est un
entrée (un couple) dans un dossier de la forme (N ; xxx)

Et vu ainsi, avec le décompte que tu me donnes, ça colle. :-)
Je ne sais pas si c'est une coïncidence heureuse et volontaire, mais il
s'avère que ça donne au final le nombre de sous-dossiers contenus dans
le dossier (en comptant . et .. aussi).

4096 est la taille d'un bloc du système de fichiers ext2/3/4 qui est sur
sdb1.



Ok, ça confirme mon sentiment avec mes recherches sur Google.

1024 est une taille de bloc arbitraire utilisée par sfdisk pour
l'affichage.



Ok, mais alors c'est vache d'avoir appelé ça "bloc".

La taille d'un secteur "visible" du disque sdb est
probablement 512 octets, comme sur la plupart des disques actuels. On
commence à voir des disques avec des secteurs physiques de 4096 octets,
mais la taille visible reste 512 par compatibilité.



Ok. Merci pour ton aide.


--
François Lafont
Pascal Hambourg
Le #22748711
Francois Lafont a écrit :
Le 01/11/2010 17:54, Pascal Hambourg a écrit :

1) Je comprends bien (enfin je crois) ce qu'est un lien non symbolique
pour un fichier standard et j'ai bien vu qu'un tel type de lien
n'existait pas pour les fichiers de type dossier.



Bien sûr que si. De ce point de vue, un répertoire est un inode comme un
autre. Seulement on ne peut pas en créer n'importe comment, sinon on
pourrait provoquer des boucles dans l'arborescence.



Ah, mais alors est-ce que tu as un exemple reproductible à me proposer ?



Inutile, tu l'as déjà fait ci-dessous.

Personnellement, j'ai essayé ça :

$ mkdir dossierPipeau



Voilà, en créant un répertoire tu as créé trois liens vers des répertoires.

$ ln dossierPipeau/ dossierPipeau2
ln: «dossierPipeau/»: lien direct non permis pour un répertoire

Et le message me dit que je ne peux pas créer un lien direct
(c'est-à-dire non symbolique) sur un répertoire.



C'est ce que j'entendais par "n'importe comment". En gros, autrement que
par la création d'un répertoire. La page de manuel de la commande ln
mentionne l'option -d, -F, --directory pour permettre au
super-utilisateur de créer des liens vers des répertoire, mais signale
que cela va probablement échouer à cause de restrictions du système.

La commande "ln" de debugfs (pour un système de fichiers ext2/3 et
peut-être 4) permet peut-être d'outrepasser cette limitation, mais c'est
à ses risques et périls.

Un pour le lien depuis le répertoire parent, un pour
le "." depuis le répertoire lui-même et un pour le ".." dans chaque
répertoire fils.



Je si comprends bien :

* un fichier (et/ou dossier) est caractérisé de manière unique par son
numéro d'i-node.



Oui, du moins dans un même système de fichiers.

* un dossier est un petit fichier dont le contenu peut se voir une sorte
de tableau où les entrées sont de la forme (numéro d'i-node ; nom), un
peu comme ce que retourne la commande "ls -1ia mon_dossier".



Je ne connais pas les détails techniques, mais c'est ainsi que je le vois.

* un lien direct vers un fichier (et/ou dossier) d'i-node N est un
entrée (un couple) dans un dossier de la forme (N ; xxx)



Oui, un lien est simplement une entrée de répertoire. "Supprimer" un
fichier, c'est en fait supprimer ce lien (fonction unlink), et pas
l'inode cible. Lorsque le nombre de liens tombe à zéro, le fichier est
effectivement supprimé. A noter que l'ouverture d'un fichier par un
processus incrémente le nombre de liens afin que le fichier ne soit pas
supprimé tant qu'il est ouvert.

Et vu ainsi, avec le décompte que tu me donnes, ça colle. :-)
Je ne sais pas si c'est une coïncidence heureuse et volontaire, mais il
s'avère que ça donne au final le nombre de sous-dossiers contenus dans
le dossier (en comptant . et .. aussi).



Ce n'est pas une coïncidence puisque chacun de ces répertoires contient
effectivement un lien vers le répertoire.
Erwan David
Le #22748801
Pascal Hambourg
Francois Lafont a écrit :
Le 01/11/2010 17:54, Pascal Hambourg a écrit :

1) Je comprends bien (enfin je crois) ce qu'est un lien non symbolique
pour un fichier standard et j'ai bien vu qu'un tel type de lien
n'existait pas pour les fichiers de type dossier.



Bien sûr que si. De ce point de vue, un répertoire est un inode comme un
autre. Seulement on ne peut pas en créer n'importe comment, sinon on
pourrait provoquer des boucles dans l'arborescence.



Ah, mais alors est-ce que tu as un exemple reproductible à me proposer ?



Inutile, tu l'as déjà fait ci-dessous.

Personnellement, j'ai essayé ça :

$ mkdir dossierPipeau



Voilà, en créant un répertoire tu as créé trois liens vers des répertoires.

$ ln dossierPipeau/ dossierPipeau2
ln: «dossierPipeau/»: lien direct non permis pour un répertoire

Et le message me dit que je ne peux pas créer un lien direct
(c'est-à-dire non symbolique) sur un répertoire.



C'est ce que j'entendais par "n'importe comment". En gros, autrement que
par la création d'un répertoire. La page de manuel de la commande ln
mentionne l'option -d, -F, --directory pour permettre au
super-utilisateur de créer des liens vers des répertoire, mais signale
que cela va probablement échouer à cause de restrictions du système.

La commande "ln" de debugfs (pour un système de fichiers ext2/3 et
peut-être 4) permet peut-être d'outrepasser cette limitation, mais c'est
à ses risques et périls.



certains systèmes permettent de faire un lien de ce type à l'aide de
mknod, là aussi réservé au super-utilisateur.

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Francois Lafont
Le #22749141
Le 02/11/2010 10:05, Pascal Hambourg a écrit :

$ mkdir dossierPipeau



Voilà, en créant un répertoire tu as créé trois liens vers des répertoires.



Ok, par contre c'est "deux liens" que tu voulais dire je suppose (si 58
est le numéro inode de dossierPipeau/, on a l'entrée (58 ;
dossierPipeau) contenue dans le dossier parent de dossierPipeau/ et
l'entrée (58 ; . ) dans dossierPipeau/ lui-même).

$ ln dossierPipeau/ dossierPipeau2
ln: «dossierPipeau/»: lien direct non permis pour un répertoire

Et le message me dit que je ne peux pas créer un lien direct
(c'est-à-dire non symbolique) sur un répertoire.



C'est ce que j'entendais par "n'importe comment". En gros, autrement que
par la création d'un répertoire. La page de manuel de la commande ln
mentionne l'option -d, -F, --directory pour permettre au
super-utilisateur de créer des liens vers des répertoire, mais signale
que cela va probablement échouer à cause de restrictions du système.



Ok, en effet, avec "man ln" je trouve ceci ; « -d, -F, --directory allow
the superuser to attempt to hard link directories (note: will probably
fail due to system restrictions, even for the superuser) »

La commande "ln" de debugfs (pour un système de fichiers ext2/3 et
peut-être 4) permet peut-être d'outrepasser cette limitation, mais c'est
à ses risques et périls.



Ok. En même temps, c'est si grave d'avoir une boucle infinie ? Je
pourrais toujours y sortir avec un "cd /", non ?

* un fichier (et/ou dossier) est caractérisé de manière unique par son
numéro d'i-node.



Oui, du moins dans un même système de fichiers.



Oui, j'avais oublié ce point important.

* un lien direct vers un fichier (et/ou dossier) d'i-node N est un
entrée (un couple) dans un dossier de la forme (N ; xxx)



Oui, un lien est simplement une entrée de répertoire. "Supprimer" un
fichier, c'est en fait supprimer ce lien (fonction unlink), et pas
l'inode cible. Lorsque le nombre de liens tombe à zéro, le fichier est
effectivement supprimé.



Et pour les fichiers de type "dossier", le mécanisme est un peu
différent, non ? Car un dossier ne peut être supprimé que s'il est vide
et pourtant même vide il y a deux liens pointant vers lui.

Merci bien pour les explications.


--
François Lafont
Pascal Hambourg
Le #22749231
Francois Lafont a écrit :
Le 02/11/2010 10:05, Pascal Hambourg a écrit :

$ mkdir dossierPipeau



Voilà, en créant un répertoire tu as créé trois liens vers des répertoires.



Ok, par contre c'est "deux liens" que tu voulais dire je suppose (si 58
est le numéro inode de dossierPipeau/, on a l'entrée (58 ;
dossierPipeau) contenue dans le dossier parent de dossierPipeau/ et
l'entrée (58 ; . ) dans dossierPipeau/ lui-même).



Et ".." dans dossierPipeau/ pointant vers le répertoire parent.

Ok. En même temps, c'est si grave d'avoir une boucle infinie ?



J'ai tendance à penser que oui, si elle n'est pas détectée. Et j'imagine
que le fait que la structure de répertoires ne soit plus purement
arborescente mais contiennent des boucles ou des "ponts" entre deux
branches peut poser des problèmes conceptuels (quid d'un chroot dans ces
conditions).

Oui, un lien est simplement une entrée de répertoire. "Supprimer" un
fichier, c'est en fait supprimer ce lien (fonction unlink), et pas
l'inode cible. Lorsque le nombre de liens tombe à zéro, le fichier est
effectivement supprimé.



Et pour les fichiers de type "dossier", le mécanisme est un peu
différent, non ? Car un dossier ne peut être supprimé que s'il est vide
et pourtant même vide il y a deux liens pointant vers lui.



C'est pour cela qu'il y a une fonction différente, rmdir(2).
Francois Lafont
Le #22749311
Le 02/11/2010 12:17, Pascal Hambourg a écrit :

$ mkdir dossierPipeau



Voilà, en créant un répertoire tu as créé trois liens vers des répertoires.



Ok, par contre c'est "deux liens" que tu voulais dire je suppose (si 58
est le numéro inode de dossierPipeau/, on a l'entrée (58 ;
dossierPipeau) contenue dans le dossier parent de dossierPipeau/ et
l'entrée (58 ; . ) dans dossierPipeau/ lui-même).



Et ".." dans dossierPipeau/ pointant vers le répertoire parent.



Ah oui, pardon,, je ne sais pas pourquoi, je me focalisais sur les liens
pointant vers dossierPipeau uniquement.

Ok. En même temps, c'est si grave d'avoir une boucle infinie ?



J'ai tendance à penser que oui, si elle n'est pas détectée. Et j'imagine
que le fait que la structure de répertoires ne soit plus purement
arborescente mais contiennent des boucles ou des "ponts" entre deux
branches peut poser des problèmes conceptuels (quid d'un chroot dans ces
conditions).



Ok.

Oui, un lien est simplement une entrée de répertoire. "Supprimer" un
fichier, c'est en fait supprimer ce lien (fonction unlink), et pas
l'inode cible. Lorsque le nombre de liens tombe à zéro, le fichier est
effectivement supprimé.



Et pour les fichiers de type "dossier", le mécanisme est un peu
différent, non ? Car un dossier ne peut être supprimé que s'il est vide
et pourtant même vide il y a deux liens pointant vers lui.



C'est pour cela qu'il y a une fonction différente, rmdir(2).



Ok, merci beaucoup Pascal. Je crois que je suis au clair sur ces
considérations maintenant. :-)

A+


--
François Lafont
Publicité
Poster une réponse
Anonyme