Le 4 août 2008 à 16:22:13 +0200, Pascal Hambourg a écrit :

Loic Tortay a écrit :

Le 4 août 2008 à 10:58:48 +0200, Pascal Hambourg a écrit :

Pas assez fiable. Un bloc accédé récemment peut avoir été libéré depuis,
et inversement un bloc occupé n'ayant pas été accédé depuis peut être
absent du journal qui n'a pas une profondeur infinie. Seul le système de
fichier le sait de façon fiable.

Il n'est pas non plus nécessaire d'avoir un journal très évolué, un
simple « bitmap » peut suffir.

Que signifierait chaque bit ? Si le bloc correspondant a été accédé au
moins une fois ou non ? Ça ne règle pas le problème des blocs libérés.

Plutôt qu'accédé ce serait modifié, néanmoins comme déjà mentionné ce
n'est évidemment pas aussi trivial à résoudre dans le cas général.

Pour que les blocs « libérés » soient connus, il faut la coopération de
l'application (système de fichiers ou autre).

[...]

Pourtant les deux couches resteraient séparées, ce serait juste un ajout
optionnel à leur interface de communication. Y aurait-il un problème à
ce que la couche du dessous demande un service à la couche du dessus ?

Il me semble que le fait que la couche de dessous demande un service à la
couche du dessus (habituellement uniquement « cliente ») est justement le
coeur du « problème » de la non-séparation (par analogie, IP ne demande pas
de service à TCP).

Cependant on peut envisager quelque chose d'asynchrone, avec le système
de fichiers qui indique régulièrement à la couche en-dessous les blocs
dont l'état a changé (ce qui pose le problème de savoir quand les blocs
précédemment vides sont pris par le système de fichiers, là il faut
sans doute être synchrone et/ou travailler avec des groupes de blocs,
« extents » ou autres).
Pour que cela soit « standard » (c'est-à-dire pas spécifique à un
système) il faudrait sans doute quelque chose au niveau SCSI.

Malgré tout c'est se fatiguer pour pas grand chose et ne régler qu'un
problème presque marginal.
Pour éviter la fragilité exacerbée d'un volume RAID-5 pendant le temps
de reconstruction d'un disque en panne, il « suffit » d'utiliser du
RAID-6 et/ou un nombre suffisament bas de disques dans le volume RAID
pour minimiser la probabilité qu'un second disque lâche simultanément.

Ce qui irait vraiment à l'encontre du découpage en couches, ce serait
que le pilote de périphérique lise lui-même les méta-données du système
de fichiers pour en déduire si un bloc est libre ou occupé.

Clairement.

C'est d'ailleurs l'un des reproches adressés à ZFS.

Tu m'étonnes.

Quoi qu'il en soit ZFS fonctionne extrêmement bien, en tout cas pas plus
mal (et souvent mieux) que les solutions bien découpées avec des jolies
barrières.

Mais ce n'est évidemment pas magique, tous les logiciels non triviaux ont
des bugs.


Loïc.