Chapitre

V

Description

du

prototype

Ce

chapitre

d?ecrit

les

points

importants

du

prototype

Apr?es

avoir

d?ecrit

succintement

sa

structuration

nous

donnons

les

hypoth?eses

faites

lors

sa

conception

et

les

choix

faits

quant

a

son

environnement

Nous

d?etaillons

ensuite

le

mode

d'utilisation

du

service

de

journalisation

en

pr?esentant

le

langage

de

description

des

graphes

et

l'interface

des

vues

de

journalisation

Les

grandes

lignes

de

la

r?ealisation

du

service

sont

ensuite

expos?ees

au

travers

de

l'

etude

des

serveurs

de

journalisation

modes

de

communication

parall?elisme

au

sein

des

serveurs

gestion

des

objets

et

liste

des

services

offerts

Le

mod?ele

de

panne

la

d?etection

et

le

traitement

des

pannes

sont

ensuite

pr?esent?es

Enfin

certains

points

particuliers

sont

discut?es

la

r?ealisation

d'une

certaine

s?ecurit?e

d'acc

es

aux

journaux

le

nommage

des

journaux

logiques

et

la

m?ethode

de

r?ealisation

des

types

abstraits

en

C++

Pr?esentation

du

prototype

Le

prototype

est

constitu?e

d'un

ensemble

de

serveurs

qui

r?ealisent

le

service

de

journalisation

d'une

librairie

cliente

et

de

programmes

de

contr

ole

L'application

communique

avec

le

a

l'aide

de

la

librairie

cliente

Lorsque

l'application

d?emarre

une

proc?edure

de

la

librairie

est

appel?ee

Elle

initialise

les

communications

avec

un

serveur

et

lui

transmet

le

graphe

de

configuration

de

l'application

Le

choix

du

serveur

est

fait

au

hasard

lorsque

le

site

du

client

ne

poss?ede

pas

de

serveur

sinon

le

serveur

local

est

choisi

afin

d'

eviter

les

echanges

de

messages

sur

le

r?eseau

L'application

doit

ensuite

ouvrir

ou

cr?eer

ses

journaux

logiques

avant

de

pouvoir

journaliser

ou

lire

des

enregistrements

sur

son

ou

ses

journaux

Le

serveur

choisi

comme

interlocuteur

pour

l'application

communique

avec

elle

par

RPC

-LSB-

Nelson

-RSB-

Contrairement

au

mod?ele

afin

de

simplifier

la

r?ealisation

du

prototype

tous

les

objets

du

graphe

de

l'application

sont

instanci?es

dans

les

espaces

d'adressage

des

serveurs

Au

moment

du

d?emarrage

de

l'application

le

serveur

qui

service

de

journalisation

est

constitu?e

de

l'ensemble

des

services

rendus

par

l'ensemble

des

serveurs

Un

service

correspond

a

l'une

des

fonctions

d'un

serveur

pouvant

etre

appel?ee

par

un

autre

processus

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

re?coit

le

graphe

de

description

de

l'application

instancie

les

objets

de

l'application

dans

son

espace

d'adressage

Puis

s

il

y

a

lieu

il

instancie

les

objets

des

sous-graphes

syst?eme

n?ecessaires

ou

en

effectue

la

demande

aupr?es

des

autres

serveurs

Les

serveurs

communiquent

entre

eux

d'une

fa?con

asynchrone

de

mani?ere

a

eviter

des

probl?emes

d'interblocage

et

de

b?en?eficier

d'un

plus

grand

parall?elisme

Lorsque

l'appel

d'un

client

n?ecessite

une

communication

entre

serveurs

le

client

reste

bloqu?e

jusqu

a

ce

que

les

serveurs

distants

aient

r?epondu

ou

bien

soient

consid?er?es

en

panne

Diff?erents

programmes

de

contr

ole

aident

a

la

mise

au

point

des

graphes

de

configuration

Un

autre

ensemble

de

programmes

permet

de

consulter

le

contenu

d'un

journal

physique

et

d'en

modifier

le

contenu

Un

programme

de

contr

ole

particulier

le

moniteur

permet

de

lancer

les

serveurs

de

journalisation

a

distance

d'en

d?etecter

les

pannes

de

contr

oler

leur

etat

de

consulter

la

liste

des

objets

instanci?es

par

les

serveurs

de

cr?eer

d?etruire

lire

ou

ecrire

diff?erents

journaux

logiques

etc.

Hypoth?eses

et

environnement

Un

certain

nombre

d'

el?ements

ont

influenc?e

d'une

mani?ere

g?en?erale

la

conception

de

KitLog

Cette

section

pr?esente

les

diff?erentes

hypoth?eses

et

choix

faits

lors

de

la

conception

du

prototype

ainsi

que

l'environnement

choisi

Pas

de

mat?eriel

d?edi?e

Certains

syst?emes

ont

fait

le

choix

pour

simplifier

la

r?ealisation

de

la

s

uret?e

de

fonctionnement

d'utiliser

un

support

mat?eriel

d?edi?e

m?emoire

secourue

-LSB-

Ban

atre

et

al

Ban

atre

et

al.

-RSB-

alimentation

en

courant

ininterruptible

-LSB-

Liskov

et

al.

Liskov

et

al.

-RSB-

disques

miroirs

-LSB-

Ban

atre

et

al.

-RSB-

tableaux

de

disques

-LSB-

Patterson

et

al.

-RSB-

Nous

avons

pr?ef?er?e

une

solution

uniquement

logicielle

Car

d'une

part

un

mat?eriel

sp?ecifique

serait

co

uteux

d'autre

part

l'utiliser

restreint

la

portabilit?e

d'un

service

Toutefois

l'usage

de

ce

type

de

mat?eriel

n'est

pas

prohib?e

par

KitLog

Il

est

envisageable

de

l'utiliser

afin

de

simplifier

les

hypoth?eses

de

pannes

et

de

r?eduire

la

complexit?e

des

graphes

Par

exemple

dans

le

cas

des

pannes

de

disque

une

application

pourra

utiliser

un

disque

miroir

afin

d'

eviter

la

r?eplication

d'un

journal

physique

au

niveau

logiciel

Evolution

technologique

L'observation

de

l'

evolution

technologique

montre

que

les

acc?es

aux

r?eseaux

et

aux

disques

deviennent

des

goulots

d'

etranglement

et

risquent

de

le

rester

dans

les

ann?ees

a

venir

-LSB-

Patterson

et

al.

-RSB-

p

Actuellement

la

vitesse

des

processeurs

s

am?eliore

de

a

par

an

La

capacit?e

et

la

vitesse

des

m?emoires

vives

et

la

capacit?e

des

supports

de

stockage

suivent

a

peu

pr?es

la

m

eme

evolution

-LCB-

-LCB-

Hypoth?eses

et

environnement

p

En

revanche

bien

que

le

d?ebit

des

r?eseaux

s

accroisse

l'acc

es

proprement

dit

au

r?eseau

reste

cher

p

Enfin

bien

que

la

capacit?e

des

disques

s

accroisse

tr?es

vite

pour

un

co

ut

tr?es

faible

la

vitesse

de

rotation

des

disques

reste

inchang?ee

depuis

une

dizaine

d'ann

ees

Ainsi

durant

le

m

eme

laps

de

temps

le

temps

d'acc

es

a

ceux-ci

n

a

pu

s

am?eliorer

que

d'un

facteur

de

deux

Par

cons?equent

en

supposant

que

l'

evolution

de

la

technologie

se

poursuive

dans

ce

sens

on

peut

consid?erer

que

la

puissance

de

calcul

la

taille

de

la

m?emoire

et

la

taille

du

support

de

stockage

sont

gigantesques

alors

que

les

vitesses

d'acc

es

au

r?eseau

et

au

support

de

stockage

sont

les

facteurs

limitatifs

auxquels

il

faudra

faire

particuli?erement

attention

Hypoth?eses

de

fonctionnement

Les

pannes

et

probl?emes

sont

nombreux

et

souvent

difficiles

a

classifier

Nous

en

laisserons

de

c

ot?e

un

certain

nombre

en

faisant

des

hypoth?eses

de

fonctionnement

restrictives

La

premi?ere

restriction

-LRB-

et

la

plus

importante

-RRB-

consiste

a

se

limiter

aux

pannes

non-byzantines

-LSB-

Lamport

et

al.

Br?es

-RSB-

De

plus

le

syst?eme

d'exploitation

utilis?e

est

suppos?e

etre

a

panne

franche

-LRB-

fail-stop

-RRB-

-LSB-

Schlichting

et

Schneider

Schneider

-RSB-

Ainsi

lorsqu'il

d?etecte

une

erreur

le

syst?eme

s

arr

ete

enti?erement

de

fonctionner

il

n

emet

plus

ne

traite

plus

ne

re?coit

plus

de

messages

Plus

aucune

information

ne

peut

etre

modifi?ee

sur

ses

supports

de

stockage

Ces

hypoth?eses

permettent

de

d?efinir

un

mod?ele

de

pannes

restreint

que

nous

d?evelopperons

au

Nous

supposerons

egalement

que

la

d?erive

relative

des

horloges

durant

un

laps

de

temps

r?eel

fixe

est

born?ee

par

une

limite

finie

et

connue

Cette

hypoth?ese

permet

d'assurer

l'unicit

e

des

identificateurs

d?elivr?es

par

les

serveurs

nous

la

discuterons

au

La

derni?ere

restriction

consiste

a

supposer

que

dans

un

syst?eme

r?eparti

il

reste

toujours

un

minimum

de

composants

ind?ependants

en

etat

de

marche

-LRB-

pas

de

coupure

de

courant

g?en?erale

-RRB-

Il

reste

toujours

un

certain

nombre

de

machines

avec

des

supports

de

stockage

capables

de

fonctionner

ind?ependamment

des

pannes

des

autres

machines

ou

disques

Cette

hypoth?ese

revient

a

ignorer

le

cas

des

catastrophes

o?u

quelque

soit

le

degr?e

de

r?eplication

des

donn?ees

utilis?ees

rien

ne

peut

etre

fait

pour

r?esister

aux

pannes

d'une

mani?ere

logicielle

Environnement

R?ealisant

un

service

a

but

g?en?eral

pour

un

grand

nombre

d'applications

il

nous

a

sembl?e

naturel

de

se

placer

dans

un

environnement

relativement

standard

Le

prototype

a

et?e

r?ealis?e

au-dessus

d'Unix

en

C

ANSI

et

en

C++

L'environnement

est

constitu?e

d'un

ensemble

de

stations

de

travail

Sun

et

Sun

reli?ees

par

un

r?eseau

Ethernet

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

Le

syst?eme

Unix

a

et?e

choisi

comme

etant

un

standard

de

fait

Des

syst?emes

plus

r?ecents

tels

que

Chorus

-LSB-

Rozier

et

al.

-RSB-

ou

Mach

-LSB-

Black

et

al.

-RSB-

proposent

une

couche

formant

un

sous-syst

eme

Unix

et

donc

permettent

de

porter

a

faible

co

ut

un

service

d?evelopp?e

sous

Unix

La

r?ealisation

de

l'approche

objet

du

mod?ele

KitLog

a

et?e

facilit?ee

par

le

choix

d'un

langage

a

objets

C++

a

naturellement

et?e

choisi

pour

son

ad?equation

a

la

programmation

au-dessus

d'Unix

et

par

le

fait

qu'il

est

largement

r?epandu

Utilisation

du

service

Cette

section

d?etaille

le

mode

d'utilisation

du

service

vu

par

un

client

de

la

journalisation

Elle

d?ecrit

le

langage

de

description

des

graphes

dont

l'usage

est

illustr?e

par

deux

exemples

et

les

vues

de

journalisation

qui

r?ealisent

l'interface

proprement

dite

de

la

journalisation

Langage

de

description

des

graphes

Le

graphe

d'une

application

est

d?ecrit

au

moyen

de

deux

fichiers

de

configuration

L'un

est

le

fichier

syst?eme

l'autre

est

celui

de

l'application

Ces

fichiers

sont

ecrits

au

moyen

d'un

mini-langage

de

description

interpr?et?e

par

le

service

Le

fichier

de

configuration

du

syst?eme

d?ecrit

la

liste

des

ressources

disponibles

qui

peuvent

etre

partag?ees

par

les

diff?erentes

applications

et

les

modes

d'acc

es

a

ces

ressources

repr?esent?ees

par

des

sous-graphes

Ce

fichier

est

configur?e

par

l'administrateur

du

service

de

journalisation

Dans

la

r?ealisation

actuelle

un

seul

fichier

contient

l'ensemble

de

la

configuration

de

la

partie

syst?eme

Dans

le

cas

d'un

service

a

grande

echelle

il

serait

n?ecessaire

de

disposer

de

diff?erents

fichiers

ne

contenant

pas

la

totalit?e

de

ces

informations

Ce

point

reste

a

etudier

Le

fichier

de

configuration

de

l'application

contient

la

partie

du

graphe

propre

a

celle-ci

Il

est

constitu?e

d'un

ensemble

de

sous-graphes

qui

connect?es

aux

diff?erents

sous-graphes

de

la

partie

syst?eme

forment

le

graphe

total

d?efinissant

les

caract?eristiques

du

journal

de

l'application

Au

moment

o?u

une

application

d?emarre

elle

donne

son

graphe

a

un

serveur

de

journalisation

Celui-ci

commence

par

en

faire

une

analyse

syntaxique

puis

il

v?erifie

certaines

r?egles

de

composition

des

objets

effectuant

notamment

une

d?etection

de

cycles

dans

le

graphe

Enfin

le

serveur

instancie

les

objets

dans

son

espace

d'adressage

et

envoie

eventuellement

des

requ

etes

aux

autres

serveurs

afin

qu'ils

instancient

pour

l'application

les

objets

devant

se

trouver

sur

leur

site

L'analyse

du

graphe

se

fait

en

plusieurs

passes

La

premi?ere

est

constitu?ee

d'une

analyse

de

la

syntaxe

qui

laisse

volontairement

des

possibilit?es

de

constituer

des

graphes

aberrants

-LRB-

par

exemple

un

objet

qui

aurait

plusieurs

successeurs

sans

etre

un

objet

de

r?eplication

-RRB-

L'analyse

s?emantique

constitue

une

seconde

phase

Elle

doit

d?etecter

les

anomalies

les

plus

fr?equentes

-LCB-

-LCB-

Utilisation

du

service

Cette

d?ecomposition

permet

d'

elargir

la

syntaxe

en

ajoutant

par

exemple

juste

le

mot-cl

e

correspondant

au

nom

d'une

nouvelle

classe

sans

avoir

a

modifier

l'analyse

syntaxique

Les

r?egles

de

composition

des

objets

sont

regroup?ees

dans

la

partie

d'analyse

s?emantique

Syntaxe

Le

graphe

est

d?ecrit

a

l'aide

d'un

mini-langage

de

description

La

conception

de

ce

mini-langage

n

a

pas

et?e

tr?es

d?evelopp?ee

car

cela

aurait

et?e

au

del?a

des

buts

de

ce

travail

Il

a

et?e

calqu?e

sur

le

mod?ele

du

mini-language

de

description

de

graphe

de

ressources

de

la

premi?ere

version

de

GATOS

-LSB-

Folliot

et

Ruffin

-RSB-

Ce

mini-langage

a

et?e

con?cu

avec

l'id

ee

qu'une

fois

le

graphe

dessin?e

il

soit

simple

a

d?ecrire

Il

comporte

onze

mots-cl

es

fixes

et

un

ensemble

de

mots-cl

es

-LRB-

pouvant

etre

etendu

-RRB-

correspondant

aux

noms

des

classes

Le

paragraphe

suivant

donne

la

syntaxe

de

description

de

la

partie

syst?eme

du

graphe

Nous

donnons

ensuite

celle

de

la

partie

du

graphe

de

l'application

Celleci

diff?ere

par

la

pr?esence

des

vues

de

journalisation

et

la

connexion

du

graphe

de

l'application

avec

les

sous-graphes

syst?eme

Description

de

la

partie

syst?eme

du

graphe

La

figure

V.

donne

la

syntaxe

de

la

partie

syst?eme

du

graphe

selon

un

formalisme

proche

de

BNF

-LRB-

Backus-Naur

Formalism

-LSB-

Backus

-RSB-

-RRB-

Le

fichier

de

configuration

de

la

partie

syst?eme

du

graphe

d?efinit

des

classes

de

CBP

-LRB-

<pbc class>

pour

predefined

block

composition

class

<=-RRB-

puis

la

configuration

de

chaque

site

Une

classe

de

CBP

est

une

CBP

non

attach?ee

a

un

site

particulier

ou

a

des

supports

de

stockage

nomm?es

La

configuration

d'un

site

est

d?efinie

par

un

nom

de

site

le

type

de

son

architecture

et

des

entr?ees

Ces

entr?ees

peuvent

etre

de

trois

esp?eces

des

blocs

des

CBP

ou

des

ressources

Un

bloc

est

d?efini

par

un

nom

symbolique

sa

classe

et

eventuellement

sa

liste

de

successeurs

Dans

la

figure

V.

un

param?etre

optionnel

a

volontairement

et?e

omis

afin

de

simplifier

la

description

de

la

syntaxe

Il

s

agit

des

donn?ees

a

passer

au

constructeur

de

l'objet

la

taille

des

tampons

pour

un

bloc

tampon

et

les

droits

d'acc

es

pour

un

bloc

de

partage

Pour

cela

deux

nouveaux

mots-cl

es

ont

et?e

introduits

SIZE

et

RIGHTS

Une

ressource

est

d?efinie

par

un

nom

symbolique

une

classe

et

un

nom

de

p?eriph?erique

a

la

mode

Unix

Une

CBP

est

d?efinie

par

un

nom

symbolique

un

nom

de

classe

symbolique

et

une

eventuelle

liste

de

successeurs

Les

noms

de

classe

correspondent

aux

noms

de

blocs

dans

la

description

de

la

syntaxe

En

r?ealit?e

cela

peut

etre

n'importe

quel

nom

de

classe

choisi

par

la

personne

l'ayant

programm?ee

Les

notions

d'appartenance

a

un

type

abstrait

ou

de

r?ealisation

d'un

bloc

particulier

n'apparaissent

pas

Cette

absence

dans

le

langage

vient

du

fait

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

<system config>

<pbc class>

<site configs>

j

<pbc class>

<system config>

j

<site configs>

<site configs>

<site config>

j

<site config>

<site configs>

<site config>

HOST

<host name>

ARCH

<architecture>

-LSB-

<entries>

-RSB-

<architecture>

j

<entries>

<entry>

j

<entry>

<entries>

<entry>

<block>

j

<pbc>

j

<resource>

<block>

BLOCK

<symbolic name>

CLASS

<class name>

-LSB-

<successors>

-RSB-

<successors>

<successor>

j

<successor>

<successors>

<successor>

SUCC

<symbolic name>

j

SUCC

CLASS

<class name>

-LSB-

<number of copies>

-RSB-

j

SUCC

CLASS

<symbolic class name>

-LSB-

<number of copies>

-RSB-

<class name>

Buffer

j

Sharing

j

Replication

j

Distribution

j

<resource class>

<pbc class>

PBC

<symbolic class name>

<successor>

<pbc>

PBC

<symbolic name>

CLASS

<symbolic class name>

-LSB-

<successors>

-RSB-

<resource>

RES

<symbolic name>

<resource class>

<resource name>

<resource class>

Disk

j

Terminal

j

Process

<resource name>

dev

<device name>

Figure

V.

Syntaxe

de

description

du

graphe

syst?eme

Les

crochets

d?elimitent

les

expressions

optionnelles

Dans

un

souci

de

simplification

les

d?efinitions

de

<host name>

<symbolic name>

<symbolic class name>

<device name>

et

<number of copies>

n'ont

pas

et?e

sp?ecifi?ees

en

BNF

Les

quatre

premiers

correspondent

a

des

cha

nes

de

caract?eres

le

dernier

est

un

entier

Les

mots-cl

es

du

langage

sont

en

MAJUSCULE

Les

noms

de

classes

sont

distingu?es

par

des

Petites

majuscules

Il

s

agit

de

la

liste

de

mots-cl

es

extensible

-LCB-

-LCB-

Utilisation

du

service

que

dans

le

prototype

il

est

n?ecessaire

de

tout

recompiler

lors

de

l'ajout

d'une

classe

Notamment

il

faut

ajouter

le

nom

de

la

classe

dans

un

ensemble

de

donn?ees

des

programmes

Le

choix

des

structures

o?u

est

inscrit

la

nouvelle

classe

d?efinit

son

bloc

Description

du

graphe

des

applications

La

syntaxe

de

description

de

la

partie

du

graphe

de

l'application

est

l?eg?erement

diff?erente

La

figure

V.

donne

les

r?egles

de

cette

syntaxe

Les

r?egles

non

sp?ecifi?ees

dans

cette

figure

sont

identiques

aux

r?egles

de

la

syntaxe

syst?eme

<application config>

<pbc class>

<client configs>

j

<pbc class>

<application config>

j

<client configs>

<client configs>

<client config>

j

<client config>

<client configs>

<client config>

VIEW

<symbolic name>

<entries>

<successor>

SUCC

-LSB-

SYST

-RSB-

<symbolic name>

j

SUCC

-LSB-

SYST

-RSB-

CLASS

<class name>

-LSB-

<number of copy>

-RSB-

j

SUCC

-LSB-

SYST

-RSB-

CLASS

<symbolic class name>

-LSB-

<number of copies>

-RSB-

Figure

V.

Syntaxe

de

description

du

graphe

des

applications

Le

fichier

de

configuration

de

l'application

peut

commencer

par

la

description

d'une

s?erie

de

classes

de

CBP

Il

doit

ensuite

comprendre

une

description

des

points

d'entr

ee

dans

le

graphe

des

diff?erents

composants

de

l'application

-LRB-

<client configs>

-RRB-

Une

configuration

cliente

a

pour

point

d'entr

e

une

vue

de

journalisation

Celle-ci

est

caract?eris?ee

par

un

nom

symbolique

et

une

s?erie

d'entr

ees

qui

comme

pr?ec?edemment

peuvent

etre

des

blocs

des

CBPs

et

des

ressources

Enfin

le

mot-cl

e

suppl?ementaire

SYST

est

ajout?e

dans

la

d?esignation

des

successeurs

afin

de

d?esigner

des

sous-graphes

situ?es

dans

la

partie

syst?eme

L'ajout

de

ce

mot-cl

e

permet

au

programmeur

d'applications

de

choisir

les

noms

symboliques

de

ses

objets

ind?ependamment

de

ceux

existants

dans

la

partie

syst?eme

du

graphe

Exemple

de

graphe

statique

La

figure

V.

donne

un

exemple

de

description

d'un

graphe

simple

La

description

de

la

partie

du

graphe

de

l'application

est

la

suivante

VIEW

v

SUCC

r

BLOCK

r

CLASS

Replication

SUCC

SUCC

BLOCK

CLASS

Distribution

SUCC

SYST

BLOCK

CLASS

Distribution

SUCC

SYST

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

RV

PSd

corto

Site

zorglub

CBP

A

Sous-graphe

de

l'application

Sous-graphes

syst?me

Figure

V.

Un

exemple

de

graphe

statique

La

partie

syst?eme

du

graphe

est

d?ecrite

de

la

mani?ere

suivante

PBC

A

SUCC

p

BLOCK

p

CLASS

Sharing

SUCC

t

BLOCK

t

CLASS

Buffer

SUCC

sd

BLOCK

sd

CLASS

Disk

HOST

corto.inria.fr

ARCH

PBC

CLASS

A

SUCC

r

RES

r

DISK

HOST

zorglub.inria.fr

ARCH

PBC

CLASS

A

SUCC

RES

DISK

HOST

gaston.inria.fr

ARCH

RES

DISK

O?u

trois

sites

participent

a

la

journalisation

mais

la

ressource

du

troisi?eme

n'est

pas

utilis?ee

Exemple

de

graphe

dynamique

Le

graphe

peut

etre

rendu

dynamique

si

dans

la

partie

de

l'application

les

CBP

ne

sont

pas

d?esign?ees

explicitement

mais

par

leur

classe

VIEW

v

SUCC

r

BLOCK

r

CLASS

Replication

SUCC

SUCC

BLOCK

CLASS

Distribution

SUCC

SYST

CLASS

A

BLOCK

CLASS

Distribution

SUCC

SYST

CLASS

A

Il

n'est

alors

pas

utile

dans

la

partie

syst?eme

de

d?eclarer

les

instances

de

CBP

elles

seront

cr?eee

par

le

syst?eme

Toutefois

cette

d?eclaration

peut

servir

a

imposer

que

-LCB-

-LCB-

Utilisation

du

service

l'acc

es

a

la

ressource

se

fasse

au

moyen

d'une

construction

d'objets

identique

a

celle

repr?esent?ee

par

la

CBP

PBC

A

SUCC

p

BLOCK

p

CLASS

Sharing

SUCC

t

BLOCK

t

CLASS

Buffer

SUCC

sd

BLOCK

sd

CLASS

Disk

HOST

corto.inria.fr

ARCH

RES

r

DISK

HOST

zorglub.inria.fr

ARCH

RES

DISK

HOST

gaston.inria.fr

ARCH

RES

DISK

Dans

ce

cas

le

service

de

journalisation

choisira

lui-m

eme

deux

des

sites

sur

les

trois

disposant

d'un

disque

utilisable

pour

instancier

les

objets

de

deux

CBPs

de

classe

A.

R?egles

de

composition

du

graphe

Une

fois

le

graphe

analys?e

syntaxiquement

un

certain

nombre

de

r?egles

de

construction

sont

v?erifi?ees

p

Les

noms

symboliques

doivent

etre

uniques

au

sein

d'un

m

eme

fichier

de

configuration

p

Les

noms

des

ressources

sont

uniques

sur

un

site

donn?e

p

Tous

les

objets

ont

un

successeur

a

l'exception

eventuellement

des

blocs

tampon

p

Seuls

les

objets

de

partage

et

les

CBPs

qui

comportent

en

entr?ee

un

objet

de

partage

ont

plus

d'un

pr?ed?ecesseur

p

Seuls

les

objets

de

r?eplication

et

les

CBPs

comportant

un

tel

objet

ont

plus

d'un

successeur

p

Seuls

les

blocs

de

support

ont

comme

successeur

une

ressource

physique

p

Tout

bloc

support

a

une

ressource

comme

successeur

p

Seuls

les

blocs

de

distribution

peuvent

avoir

un

successeur

sur

un

site

diff?erent

p

Il

n

y

a

pas

de

cycle

dans

le

graphe

R?egles

a

l'instanciation

D'autres

r?egles

sont

n?ecessaires

au

moment

de

l'instanciation

et

de

la

liaison

des

objets

dans

le

cas

de

la

liaison

dynamique

avons

l?eg?erement

etendu

la

d?efinition

du

mot

successeur

a

un

el?ement

n'appartenant

pas

au

graphe

afin

de

simplifier

le

discours

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

p

Lorsque

des

objets

sont

li?es

dynamiquement

comme

successeurs

d'un

objet

de

r?eplication

les

feuilles

du

sous-graphe

dont

l'objet

r?eplication

est

la

racine

qui

sont

situ?ees

sur

le

m

eme

site

doivent

correspondre

a

des

supports

de

stockage

distincts

p

Lorsque

des

objets

sont

li?es

dynamiquement

comme

successeurs

d'un

objet

de

r?eplication

et

que

ces

objets

comprennent

des

objets

de

distribution

les

sites

d'instanciation

doivent

etre

distincts

Ces

deux

r?egles

permettent

d'assurer

les

caract?eristiques

de

r?eplication

souhait?ees

par

les

programmeurs

d'application

Une

erreur

est

retourn?ee

quand

elles

ne

peuvent

etre

appliqu?ees

par

manque

de

ressources

disponibles

Extensibilit?e

du

langage

L'ajout

d'une

nouvelle

classe

n?ecessite

l'adjonction

d'un

nouveau

mot-cl

e

au

langage

correspondant

au

nom

de

la

classe

dans

le

langage

Un

tableau

diff?erent

enregistre

les

noms

de

classe

r?ealisant

un

m

eme

bloc

Il

y

a

donc

un

tableau

par

bloc

L'analyse

syntaxique

ne

n?ecessite

pas

la

connaissance

de

la

nature

des

blocs

r?ealis?es

par

les

classes

contrairement

a

l'analyse

s?emantique

Dans

tous

les

cas

l'ajout

d'une

classe

implique

la

recompilation

compl?ete

des

diff?erentes

parties

du

code

pour

d'une

part

augmenter

le

langage

et

d'autre

part

ajouter

le

code

de

la

nouvelle

classe

L'ajout

de

code

pourait

etre

r?esolu

par

la

liaison

dynamique

de

celui-ci

en

revanche

la

non

recompilation

du

code

pour

l'interpr

etation

du

langage

est

un

probl?eme

plus

complexe

a

r?esoudre

Une

solution

a

ce

probl?eme

pourrait

etre

un

m?eta

langage

d?efinissant

les

mots-cl

es

Type

et

langage

de

description

Le

langage

de

description

de

graphe

est

assez

simple

a

utiliser

une

fois

le

graphe

construit

Toutefois

il

ne

laisse

appara

tre

clairement

ni

la

notion

de

type

abstrait

des

blocs

ni

le

fait

qu'une

classe

est

la

r?ealisation

d'un

bloc

particulier

La

notion

de

type

abstrait

des

blocs

est

li?ee

a

l'organisation

du

stockage

physique

puisque

celle-ci

d?etermine

l'interface

des

blocs

-LRB-

cf.

chapitre

III

-RRB-

Il

est

donc

n?ecessaire

pour

une

ressource

donn?ee

de

pouvoir

d?eterminer

quel

type

de

bloc

il

faut

utiliser

pour

la

g?erer

Pour

conserver

l'information

concernant

la

structuration

des

donn?ees

sur

une

ressource

de

stockage

particuli?ere

le

langage

de

description

du

graphe

doit

permettre

d'associer

un

type

abstrait

de

bloc

a

chaque

ressource

ayant

et?e

utilis?ee

De

plus

on

peut

facilement

envisager

des

compatibilit?es

entre

les

types

et

m

eme

des

conversions

de

type

Pour

que

cela

soit

r?ealisable

il

est

n?ecessaire

de

pouvoir

exprimer

dans

le

langage

l'appartenance

des

blocs

aux

types

et

les

informations

n?ecessaires

a

ces

transformations

-LCB-

-LCB-

Utilisation

du

service

Modification

du

graphe

en

cours

de

fonctionnement

Le

programmeur

d'applications

d?efinit

son

graphe

pour

un

journal

logique

donn?e

ou

un

ensemble

de

journaux

logiques

Il

peut

par

la

suite

entre

deux

utilisations

modifier

ce

graphe

Cela

pose

un

probl?eme

de

compatibilit?e

des

versions

successives

des

graphes

Imaginons

un

journal

logique

r?epliquant

les

enregistrements

sur

les

sites

A

et

B

transform?e

par

la

suite

en

un

journal

logique

r?epliqu?e

sur

les

sites

C

et

D.

La

recherche

d'enregistrements

ant?erieurs

a

cette

modification

des

caract?eristiques

du

graphe

devrait

se

faire

sur

les

sites

A

et

B.

Plusieurs

solutions

s

offrent

a

nous

dans

de

tels

cas

La

premi?ere

consiste

a

chercher

l'enregistrement

sur

tous

les

sites

et

les

supports

ayant

un

jour

journalis?e

quelque

chose

Cela

reviendrait

en

quelque

sorte

a

trahir

les

sp?ecifications

donn?ees

par

l'application

puisque

l'application

sp?ecifie

par

l'interm

ediaire

de

son

graphe

que

les

enregistrements

doivent

etre

cherch?es

sur

les

sites

C

et

D.

Une

autre

solution

consiste

a

garder

une

trace

des

diverses

transformations

des

caract?eristiques

du

journal

Ceci

est

possible

au

moyen

de

traces

gard?ees

pour

chaque

journal

et

peut

etre

r?ealis?e

au

moyen

d'un

journal

global

de

m?eta

donn?ees

On

stocke

pour

un

journal

donn?e

la

configuration

du

graphe

correspondant

et

ses

evolutions

Ceci

a

et?e

propos?e

par

Rosenthal

-LRB-

-LSB-

Rosenthal

-RSB-

-RRB-

pour

les

syst?emes

de

fichiers

Rosenthal

empile

des

couches

encapsulant

des

caract?eristiques

de

la

gestion

de

fichiers

Les

fichiers

transitent

a

travers

les

couches

avant

d'

etre

stock?es

Il

envisage

de

stocker

un

type

associ?e

a

chaque

fichier

correspondant

a

l'empilement

de

couches

travers?ees

Pour

un

fichier

donn?e

l'

evolution

de

l'empilement

des

couches

devient

alors

un

probl?eme

de

compatibilit?e

de

types

Dans

notre

prototype

ce

genre

de

probl?eme

n'est

pas

pris

en

compte

Le

programmeur

fournit

un

graphe

et

le

service

de

gestion

du

journal

reste

dans

les

etroites

limites

d?efinies

par

ce

graphe

pour

la

gestion

des

journaux

logiques

Toute

modification

est

sous

la

responsabilit?e

du

programmeur

d'application

et

de

l'administrateur

du

service

de

journalisation

Aide

a

la

description

du

graphe

Le

graphe

d'une

application

donn?ee

est

relativement

difficile

a

construire

d'une

mani?ere

qui

soit

la

plus

optimis?ee

possible

en

fonction

d'un

but

d?etermin?e

Cette

complexit?e

va

cro

tre

avec

l'ajout

de

nouvelles

classes

et

la

r?ealisation

de

nouveaux

types

abstraits

Il

est

en

cons?equence

souhaitable

de

disposer

d'un

outil

d'aide

a

la

construction

du

graphe

Cet

outil

doit

prendre

en

compte

diff?erents

facteurs

p

En

premier

lieu

une

description

du

mode

d'utilisation

du

graphe

taille

moyenne

des

enregistrements

volume

des

lectures

en

fonction

du

volume

des

ecritures

le

type

des

lectures

-LRB-

s?equentielles

ou

non

-RRB-

le

nombre

de

journaux

logiques

utilis?es

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

A

partir

de

l?a

un

ensemble

de

r?egles

pourraient

d?eterminer

quelle

est

la

meilleure

m?ethode

de

journalisation

a

choisir

p

En

second

lieu

les

caract?eristiques

des

journaux

logiques

utilis?es

besoins

en

fiabilit?e

en

transparence

etc.

qui

permettraient

de

d?efinir

les

diff?erents

blocs

utilis?es

pour

la

journalisation

et

leur

mode

de

constitution

en

un

graphe

p

Finalement

la

liste

des

diff?erents

protocoles

souhait?es

maintien

de

la

coh?erence

des

copies

m?ethode

de

gestion

de

cache

par

exemple

afin

d'affiner

le

choix

des

blocs

par

l'utilisation

des

classes

r?ealisant

leurs

caract?eristiques

d'une

mani?ere

la

plus

adapt?ee

a

l'ensemble

des

politiques

d?esir?ees

Un

tel

outil

serait

un

syst?eme

expert

a

base

de

r?egles

o?u

la

base

de

faits

serait

constitu?ee

des

besoins

de

l'application

et

de

la

description

des

sous-graphes

du

fichier

de

configuration

syst?eme

La

base

de

r?egles

pourrait

etre

constitu?ee

de

r?egles

pr?esidant

aux

choix

du

type

et

des

classes

ainsi

que

des

r?egles

de

composition

du

graphe

Le

choix

du

syst?eme

expert

semble

assez

naturel

dans

la

mesure

o?u

les

syst?emes

experts

sont

les

outils

privil?egi?es

d'aide

au

diagnostic

De

plus

l'utilisation

de

r?egles

permettrait

d'ajouter

ais?ement

de

nouvelles

classes

et

de

nouveaux

types

par

l'ajout

et

le

raffinement

des

r?egles

de

d?eductions

En

revanche

le

langage

de

description

du

graphe

devrait

etre

transform?e

en

une

base

de

faits

pouvant

correspondre

a

diff?erents

niveaux

de

pr?ecision

dans

la

description

du

graphe

Ceci

est

a

l'

etat

prospectif

Vues

de

journalisation

Les

vues

de

journalisation

sont

les

objets

d'interface

des

clients

Leur

r

ole

est

de

transformer

les

requ

etes

des

clients

faites

via

l'invocation

des

op?erations

des

vues

en

invocations

sur

leur

bloc

successeur

et

de

prot?eger

les

blocs

du

graphe

Description

de

l'interface

L'interface

des

vues

de

journalisation

est

donn?ee

par

la

figure

V.

Les

op?erations

create

log

-LRB-

-RRB-

destroy

log

-LRB-

-RRB-

open

log

-LRB-

-RRB-

et

close

log

-LRB-

-RRB-

permettent

respectivement

de

cr?eer

d?etruire

ouvrir

et

fermer

un

journal

logique

Un

journal

logique

est

rep?er?e

par

son

identificateur

unique

Lid

Toutefois

il

est

possible

de

lui

associer

un

nom

a

sa

cr?eation

-LRB-

Id

-RRB-

qui

est

un

num?ero

choisi

par

le

cr?eateur

du

journal

-LRB-

nous

reviendrons

sur

le

probl?eme

du

nommage

des

journaux

au

-RRB-

Une

op?eration

suppl?ementaire

get

lid

-LRB-

-RRB-

permet

de

retrouver

l'identificateur

unique

d'un

journal

logique

a

partir

de

l'identificateur

donn?e

par

l'application

et

du

nom

symbolique

de

la

vue

de

journalisation

utilis?ee

pour

cr?eer

le

L'op

eration

put

-LRB-

-RRB-

permet

au

client

de

concat?ener

un

nouvel

enregistrement

a

un

journal

logique

existant

Ce

dernier

est

d?efini

par

son

Lid

alors

que

l'enregistrement

est

d?efini

par

un

num?ero

d'enregistrement

unique

a

travers

le

journal

logique

-LRB-

Rid

-RRB-

son

nom

de

la

vue

de

journalisation

n'appara

t

pas

dans

l'interface

car

la

vue

conna

t

son

nom

symbolique

-LCB-

-LCB-

Utilisation

du

service

Cr?eation

et

destruction

de

journaux

logiques

create

log

-LRB-

Id

Lid

-RRB-

destroy

log

-LRB-

Lid

-RRB-

Ouverture

et

fermeture

de

journaux

logiques

get

lid

-LRB-

Id

Lid

-RRB-

open

log

-LRB-

Lid

-RRB-

close

log

-LRB-

Lid

-RRB-

Concat?enation

d'enregistrements

put

-LRB-

Lid

Rid

Contents

S

-RRB-

put

-LRB-

Lid

Rid

Contents

S

-RRB-

Signalisation

au

syst?eme

de

la

liste

des

enregistrements

obsol?etes

invalidate

records

-LRB-

Lid

Rid

-RRB-

invalidate

records

-LRB-

Lid

-RRB-

invalidate

records

-LRB-

Lid

Rid

-RRB-

Lectures

en

arri?ere

get

last

-LRB-

Lid

Rid

Contents

S

-RRB-

get

prev

-LRB-

Lid

Rid

Contents

S

-RRB-

Lectures

en

avant

get

-LRB-

Lid

Rid

Contents

S

-RRB-

get

next

-LRB-

Lid

Rid

Contents

S

-RRB-

Action

de

forcer

les

ecritures

sur

les

supports

de

stockage

flush

-LRB-

Level

-RRB-

Figure

V.

Interface

des

vues

de

journalisation

Lid

Identificateur

de

journal

-LRB-

Log

identifier

-RRB-

Rid

Identificateur

d'enregistrement

-LRB-

Record

identifier

-RRB-

Contents

Bloc

opaque

de

donn?ees

de

l'enregistrement

S

Taille

de

l'enregistrement

-LRB-

Size

-RRB-

Passage

du

param?etre

par

r?ef?erence

contenu

-LRB-

Contents

-RRB-

et

sa

taille

-LRB-

S

-RRB-

Deux

op?erations

put

-LRB-

-RRB-

sont

possibles

selon

que

le

client

souhaite

lui-m

eme

choisir

son

identificateur

d'enregistrement

ou

non

Dans

le

premier

cas

l'application

affecte

elle-m

eme

les

identificateurs

d'enregistrement

Dans

le

second

cas

le

service

les

alloue

lui-m

eme

et

retourne

leur

valeur

Les

Rid

fournis

par

le

client

sont

suppos?es

uniques

et

croissants

le

service

de

journalisation

ne

le

v?erifie

pas

L'op

eration

invalidate

records

-LRB-

-RRB-

est

similaire

a

celle

des

blocs

-LRB-

d?ecrite

au

du

chapitre

IV

-RRB-

Elle

a

trois

formes

correspondant

aux

trois

m?ethodes

d'indication

des

enregistrements

obsol?etes

d'un

journal

logique

Les

quatre

op?erations

pour

la

lecture

d'enregistrements

get

last

-LRB-

-RRB-

get

prev

-LRB-

-RRB-

get

-LRB-

-RRB-

et

get

next

-LRB-

-RRB-

correspondent

aux

op?erations

de

recherche

d'enregistrement

et

de

r?ecup?eration

de

leurs

valeurs

Get

last

-LRB-

-RRB-

retourne

le

num?ero

le

contenu

et

la

taille

du

dernier

enregistrement

d'un

journal

logique

Get

prev

-LRB-

-RRB-

rend

les

informations

similaires

concernant

l'enregistrement

pr?ec?edent

l'enregistrement

courant

L'op

eration

get

-LRB-

-RRB-

rend

l'enregistrement

de

num?ero

Rid

et

les

donn?ees

aff?erentes

Si

la

valeur

du

Rid

est

nulle

elle

rend

les

donn?ees

correspondant

au

premier

enregistrement

du

journal

logique

Finalement

l'op

eration

get

next

-LRB-

-RRB-

retourne

les

donn?ees

concernant

l'enregistrement

suivant

l'enregistrement

courant

L'op

eration

flush

-LRB-

-RRB-

est

similaire

a

celle

de

l'interface

des

blocs

-LRB-

d?ecrite

au

du

chapitre

IV

-RRB-

Elle

demande

de

mani?ere

r?ecursive

a

ses

successeurs

de

vider

leurs

eventuels

tampons

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

Type

et

classes

d'une

vue

Une

vue

de

journalisation

utilise

dans

son

interface

des

structures

de

donn?ees

identiques

a

celle

du

type

abstrait

de

bloc

qu'elle

prot?ege

des

acc?es

directs

En

cons?equence

l'interface

d'une

vue

est

d?ependante

de

celle

d'un

type

abstrait

de

blocs

Il

n'est

pas

impensable

de

disposer

de

plusieurs

impl?ementations

des

vues

de

journalisation

pour

un

m

eme

type

abstrait

de

bloc

En

cons?equence

de

m

eme

que

pour

les

blocs

on

peut

d?efinir

un

type

abstrait

pour

les

vues

r?ealis?e

par

diff?erentes

classes

Dans

le

prototype

cette

distinction

entre

type

et

classe

n

a

pas

et?e

r?ealis?ee

pour

les

vues

de

journalisation

Une

relation

particuli?ere

lie

le

type

d'une

vue

au

type

des

blocs

Tous

les

objets

d'un

type

de

vue

donn?e

doivent

etre

capables

d'invoquer

toutes

les

op?erations

-LRB-

autoris?ees

-RRB-

des

objets

se

conformant

au

type

des

blocs

On

voit

bien

ici

l'int

er

et

d'encapsuler

la

protection

des

invocations

au

niveau

du

type

et

non

de

la

classe

Cela

permet

d'ajouter

de

nouvelles

classes

-LRB-

de

vue

et

de

bloc

-RRB-

sans

avoir

a

modifier

quoi

que

ce

soit

Nous

reviendrons

sur

ce

point

au

Discussion

Les

vues

telles

qu'elles

sont

utilis?ees

consistent

a

donner

une

interface

publique

aux

blocs

qui

disposent

egalement

d'une

sorte

d'interface

de

groupe

-LSB-

Gourhant

-RSB-

Ceci

a

d?ej?a

et?e

fait

sous

des

formes

diff?erentes

dans

d'autres

syst?emes

Par

exemple

dans

Emerald

un

objet

peut

avoir

plusieurs

interfaces

diff?erentes

-LRB-

ou

plusieurs

types

abstraits

-RRB-

qui

forment

son

type

concret

-LSB-

Black

et

al.

-RSB-

C'est

une

solution

que

nous

aurions

pu

adopter

en

donnant

simplement

deux

interfaces

aux

objets

plut

ot

qu'en

ajoutant

l'objet

vue

Le

choix

d'un

type

d'objets

distinct

r?ealisant

l'interface

publique

des

blocs

est

motiv?e

par

des

raisons

d'efficacit

e

et

de

modularit?e

En

effet

dans

le

cas

particulier

de

KitLog

il

eut

et?e

inutile

de

munir

chaque

objet

de

toutes

les

op?erations

r?eserv?ees

aux

vues

D'une

part

cela

aurait

diminu?e

les

performances

-LRB-

objets

plus

gros

plus

complexes

-RRB-

d'autre

part

cela

aurait

oblig?e

pour

chaque

d?efinition

de

classe

d'objet

la

d?efinition

de

l'interface

publique

en

plus

de

celle

de

groupe

Le

service

de

journalisation

Le

service

est

r?ealis?e

par

la

coop?eration

de

l'ensemble

de

ses

serveurs

Un

serveur

doit

s

ex?ecuter

sur

chaque

site

participant

a

la

journalisation

Les

serveurs

sont

a

etat

et

sont

mono-t

ache

c'est

a-dire

qu'ils

correspondent

a

un

processus

Unix

qu'ils

conservent

des

informations

d'

etat

et

ne

supportent

pas

plusieurs

fils

d'ex

ecution

-LRB-

threads

-RRB-

simultan?es

Ce

choix

a

et?e

fait

dans

un

but

de

simplification

du

prototype

et

sera

discut?e

au

-LCB-

-LCB-

Le

service

de

journalisation

Communications

Les

serveurs

communiquent

a

l'aide

d'un

protocole

a

flots

fiable

et

ordonn?e

TCP/IP

-LSB-

Postel

Postel

-RSB-

Au

moment

du

d?emarrage

d'un

serveur

ils

ouvrent

des

sockets

TCP

vers

chacun

des

autres

serveurs

actuellement

en

etat

de

servir

Asynchronisme

La

communication

entre

un

serveur

et

ses

clients

est

synchrone

c'est

a-dire

que

le

client

se

bloque

en

attendant

une

r?eponse

du

serveur

En

revanche

les

serveurs

communiquent

entre

eux

de

mani?ere

asynchrone

Lorsque

un

serveur

envoie

une

requ

ete

a

un

autre

serveur

il

ne

reste

pas

bloqu?e

en

attente

de

la

r?eponse

Il

stocke

un

descriptif

de

la

requ

ete

envoy?ee

et

continue

d'autres

traitements

Lorsque

l'autre

serveur

a

trait?e

la

requ

ete

il

envoie

la

r?eponse

sous

la

forme

d'une

nouvelle

requ

ete

au

premier

serveur

Celui-ci

recherche

alors

le

descriptif

de

requ

ete

correspondant

et

d?ebloque

le

client

qui

restait

en

attente

de

sa

r?eponse

-LRB-

voir

figure

V.

-RRB-

Client

Requ?te

Requ?te

R?ponse

Requ?te

Serveur

R?ponse

synchroneRequ?te

asynchroneR?ponse

asynchrone

Serveur

en

attentede

requ?teTraitements

du

client

Traitements

du

client

Attente

de

r?ponseRequ?te

synchrone

Figure

V.

Asynchronisme

des

communications

entre

serveurs

La

requ

ete

n?ecessite

une

requ

ete

asynchrone

au

second

serveur

La

r?eponse

a

la

requ

ete

est

envoy?ee

sous

la

forme

d'une

requ

ete

asynchrone

Pendant

le

traitement

de

par

le

second

serveur

le

premier

serveur

a

re?cu

une

autre

requ

ete

dont

il

a

pu

commencer

le

traitement

Si

deux

serveurs

capables

de

s

envoyer

des

requ

etes

communiquent

d'une

mani?ere

synchrone

il

y

a

risque

d'interblocage

ou

de

disfonctionnement

En

effet

prenons

l'exemple

de

deux

serveurs

communiquant

d'une

mani?ere

synchrone

au

moyen

de

RPC

-LSB-

Nelson

-RSB-

et

s

envoyant

simultan?ement

une

requ

ete

Les

serveurs

restent

alors

bloqu?es

en

attente

de

la

r?eponse

En

supposant

que

l'on

evite

l'interblocage

en

limitant

la

dur?ee

de

l'attente

lorsque

les

serveurs

se

r?eveillent

ils

consid?erent

que

leur

requ

ete

a

echou?e

Apr?es

avoir

mis

en

oeuvre

le

traitement

n?ecessaire

a

cet

echec

ils

consultent

la

liste

des

requ

etes

arriv?ees

Ils

trouvent

alors

en

attente

la

requ

ete

de

l'autre

serveur

la

traite

et

lui

renvoie

une

r?eponse

Ce

qui

produit

a

nouveau

une

erreur

car

l'autre

serveur

n'attend

plus

sa

r?eponse

En

conclusion

les

deux

requ

etes

auront

et?e

trait?ees

et

chaque

serveur

aura

consid?er?e

qu'elles

ont

echou?e

Enfin

le

r?esultat

de

ces

requ

etes

aura

et?e

perdu

Une

autre

solution

pour

g?erer

l'asynchronisme

aurait

et?e

a

chaque

appel

a

un

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

serveur

a

cr?eer

une

t

ache

attendant

la

r?eponse

Cette

solution

est

plus

complexe

a

mettre

en

oeuvre

puisqu'il

faut

g?erer

la

concurrence

des

acc?es

aux

donn?ees

globales

du

serveur

L'asynchronisme

des

communications

entre

serveurs

permet

egalement

a

un

serveur

de

continuer

a

traiter

des

requ

etes

durant

le

traitement

par

un

autre

serveur

d'un

de

ses

appels

Cet

accroissement

du

parall?elisme

est

illustr?e

par

la

figure

V.

H?et?erog?en?eit?e

KitLog

fonctionne

en

environnement

h?et?erog?ene

Dans

le

prototype

des

sites

Sun

et

Sun

coop?erent

pour

la

journalisation

d'enregistrements

Pour

cela

les

serveurs

utilisent

les

fonctions

XDR

-LRB-

eXternal

Data

Representation

-RRB-

-LSB-

Sun

Microsystems

Inc.

SunOS/XDR

-RSB-

afin

de

traduire

les

requ

etes

faites

a

un

site

d'architecture

diff?erente

en

un

format

r?eseau

connu

de

chaque

site

le

format

XDR

Toutefois

les

fonctions

XDR

doivent

etre

appliqu?ees

a

l'ensemble

des

param?etres

pass?es

a

l'appel

et

re?cus

en

retour

d'un

appel

distant

Or

le

corps

des

enregistrements

est

un

bloc

de

donn?ees

opaque

pour

les

diff?erents

programmes

et

biblioth?eques

de

KitLog

Seule

l'application

g?en?erant

les

corps

des

enregistrements

est

capable

d'en

conna

tre

la

structuration

et

donc

eventuellement

de

les

traduire

dans

le

format

standard

XDR

ce

qui

pose

un

probl?eme

aux

serveurs

qui

s

echangent

des

enregistrements

Deux

solutions

sont

possibles

pour

r?esoudre

ce

probl?eme

La

premi?ere

est

a

l'image

de

celle

adopt?ee

par

les

RPC

de

Sun

-LSB-

SunOS/RPC

-RSB-

Elle

consiste

pour

chaque

enregistrement

a

demander

a

l'application

cliente

de

fournir

une

proc?edure

apte

a

effectuer

la

traduction

de

celui-ci

dans

le

format

XDR

Cette

proc?edure

etant

appliqu?ee

a

l'enregistrement

par

la

biblioth?eque

cliente

La

seconde

solution

que

nous

avons

choisie

consiste

a

consid?erer

que

les

enregistrements

sont

d?ej?a

traduits

dans

le

format

XDR

Elle

a

le

m?erite

de

la

simplicit?e

mais

a

l'inconv

enient

d'effectuer

des

traductions

inutiles

lorsque

les

enregistrements

restent

sur

des

sites

d'architectures

compatibles

Un

autre

probl?eme

se

pose

lors

de

la

traduction

des

donn?ees

en

format

XDR

Le

taille

des

donn?ees

r?esultantes

peut

etre

plus

grande

que

celle

des

donn?ees

non

traduites

Cela

se

produit

dans

le

cas

des

cha

nes

de

caract?eres

ou

des

donn?ees

dont

la

longueur

n'est

pas

un

multiple

de

bits

En

cons?equence

les

m?eta

donn?ees

des

secteurs

-LRB-

marqueurs

trailers

etc.

-RRB-

qui

sont

les

seules

donn?ees

que

nous

traduisons

au

sein

d'un

secteur

doivent

etre

d'une

taille

multiple

de

bits

Cela

permet

de

conserver

le

secteur

comme

unit?e

de

transfert

entre

blocs

m

eme

dans

le

cas

du

bloc

de

distribution

Parall?elisme

au

sein

des

serveurs

Le

parall?elisme

au

sein

d'un

serveur

a

etat

pose

des

probl?emes

de

coh?erence

de

donn?ees

que

nous

avons

ignor?e

lors

de

la

conception

du

prototype

-LCB-

-LCB-

Le

service

de

journalisation

On

rencontre

g?en?eralement

deux

types

de

parall?elisme

dans

de

tels

cas

Le

premier

est

celui

de

serveurs

comme

NFS

Au

d?ebut

de

son

ex?ecution

le

programme

lanc?e

se

clone

en

plusieurs

exemplaires

correspondant

chacun

a

un

serveur

partageant

un

certain

nombre

de

donn?ees

r?eserv?ees

a

la

synchronisation

avec

les

autres

serveurs

mais

ne

partageant

aucun

autre

type

de

donn?ee

Chaque

serveur

etant

identique

aux

autres

ce

m?ecanisme

permet

de

r?epartir

la

charge

entre

diff?erents

processus

Ceci

est

utilis?e

pour

les

serveurs

sans

etat

qui

ont

besoin

d'une

synchronisation

faible

et

qui

sont

souvent

bloqu?es

par

des

entr?ees

sorties

Le

second

type

de

parall?elisme

est

celui

o?u

un

processus

utilise

diff?erents

fils

d'ex

ecution

et

o?u

chaque

fil

-LRB-

t

ache

-RRB-

est

sp?ecialis?e

dans

le

traitement

d'un

travail

particulier

Ce

type

de

parall?elisme

n?ecessite

une

certaine

s?eparation

du

travail

entre

t

aches

de

mani?ere

a

minimiser

les

donn?ees

partag?ees

par

deux

t

aches

ce

qui

permet

de

restreindre

les

probl?emes

d'incoh

erence

entre

fils

d'ex

ecution

Le

prototype

actuel

ne

pr?evoit

le

parall?elisme

que

lors

du

compactage

d'un

support

de

stockage

Au

d?ebut

d'un

compactage

le

serveur

se

scinde

en

deux

processus

L'un

continuera

a

effectuer

les

services

traditionnels

tandis

que

l'autre

se

chargera

du

compactage

proprement

dit

Une

fois

celui-ci

effectu?e

le

second

processus

se

terminera

L'int

er

et

de

cette

technique

r?eside

dans

la

limitation

du

partage

des

donn?ees

entre

les

deux

serveurs

Le

processus

de

compactage

est

capable

d'avoir

acc?es

en

lecture

a

toutes

les

donn?ees

du

serveur

tout

en

n'interf

erant

en

ecriture

que

lors

de

l'acc

es

au

support

de

stockage

Gestion

des

objets

La

gestion

des

objets

est

r?ealis?ee

par

les

serveurs

Cette

gestion

comprend

l'instanciation

des

blocs

l'initialisation

la

liaison

la

localisation

l'invocation

distante

la

d?eliaison

la

d?esinitialisation

et

l'effacement

des

objets

Structure

de

donn?ees

des

serveurs

Au

fur

et

a

mesure

que

le

service

de

journalisation

analyse

le

graphe

de

l'application

pour

chaque

entit?e

des

structures

de

donn?ees

sont

cr?e?ees

La

figure

V.

donne

une

partie

des

structures

de

donn?ees

utilis?ees

pour

d?ecrire

un

graphe

Pour

simplifier

la

figure

nous

avons

omis

les

deux

structures

Desc

d?ecrivant

les

deux

disques

utilis?es

-LRB-

symbolis?ees

par

les

deux

eches

n'aboutissant

pas

et

sortant

des

structures

Pair

en

bas

a

gauche

de

la

figure

-RRB-

Quatre

sortes

de

structures

rep?erent

les

diff?erentes

entit?es

Chaque

application

est

d?ecrite

par

une

structure

Appli

desc

donnant

son

nom

symbolique

sa

cl?e

son

niveau

de

droits

d'acc

es

et

un

pointeur

vers

l'une

des

vues

de

l'application

Les

diff?erents

descripteurs

de

vue

-LRB-

View

desc

-RRB-

d'une

m

eme

application

sont

cha

n?es

entre

eux

Les

blocs

les

CBP

et

les

ressources

sont

d?ecrits

par

une

structure

Desc

Le

successeur

d'un

bloc

ou

bien

le

premier

el?ement

d'une

CBP

est

d?ecrit

par

une

structure

Pair

La

structure

Desc

stocke

des

informations

et

des

pointeurs

sur

l'objet

Elle

comprend

les

champs

suivants

la

nature

de

l'entit

e

manipul?ee

-LRB-

objet

CBP

ou

ressource

-RRB-

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

suc_namesymb_nameownerhostptrviewnextView_desc

View_descnextviewptrhostownersymb_namesuc_name

PairclassPairptrnbcpnextownersuc_nameclass

suchostownercolorobjectsymb_nameblockclassDesc

symb_nameobjectcolorownerhostsucblockclassDesc

VV

D

P

Sd

R

Sd

Pairptrnbcpnextownersuc_nameclassPairptrnbcpnextownersuc_nameclassPair

ptrnbcpnextownersuc_nameclassPairptrnbcpnextownersuc_nameclassPairptrn

CBP

Figure

V.

Structures

de

donn?ees

des

serveurs

-LCB-

-LCB-

Le

service

de

journalisation

le

nom

symbolique

donn?e

a

l'entit

e

une

couleur

permettant

de

la

marquer

lors

des

parcours

de

graphe

l'identit

e

de

l'application

propri?etaire

la

machine

d'instanciation

de

l'entit

e

un

pointeur

vers

une

eventuelle

structure

Pair

faisant

r?ef?erence

a

un

successeur

le

nom

de

la

classe

de

l'entit

e

et

un

pointeur

vers

l'entit

e

si

celle-ci

est

un

objet

instanci?e

Les

vues

de

journalisation

disposent

de

descripteurs

similaires

-LRB-

un

peu

simplifi?es

-RRB-

La

structure

Pair

permet

de

disposer

de

plusieurs

successeurs

et

de

disposer

de

successeurs

non

instanci?es

Instanciations

L'analyseur

syntaxique

du

graphe

cr?ee

les

structures

de

donn?ees

L'analyseur

s?emantique

cr?ee

les

pointeurs

entre

les

diff?erentes

structures

Lorsqu'un

serveur

d?emarre

il

cr?ee

les

structures

de

donn?ees

correspondant

aux

morceaux

de

graphes

syst?eme

dont

les

objets

doivent

etre

instanci?es

sur

son

site

Tous

ces

descripteurs

ont

pour

propri?etaire

le

syst?eme

Lorsqu'une

application

est

en

phase

d'initialisation

les

descripteurs

sont

cr?e?es

dans

la

partie

syst?eme

Puis

les

objets

sont

cr?e?es

Si

un

objet

est

situ?e

a

distance

une

requ

ete

de

demande

d'instanciation

des

objets

est

effectu?ee

au

serveur

concern?e

Les

adresses

locales

des

objets

distants

sont

retourn?ees

Seuls

les

objets

de

distribution

pointent

sur

des

objets

distants

Lorsqu'ils

doivent

invoquer

un

objets

distant

ils

contactent

le

serveur

correspondant

et

lui

donnent

l'adresse

de

l'objet

a

invoquer

Lorsque

l'application

veut

utiliser

son

graphe

elle

doit

initialiser

une

vue

Les

objets

concern?es

sont

alors

instanci?es

et

initialis?es

Les

objets

syst?eme

sont

eventuellement

initialis?es

s

ils

ne

l'

etaient

pas

auparavant

-LRB-

suivant

qu'ils

sont

actuellement

utilis?es

ou

non

par

une

autre

application

-RRB-

Les

CBPs

sont

court-circuit

ees

dans

le

graphe

Un

objet

qui

r?ef?erence

une

CBP

pointe

directement

vers

l'objet

racine

de

la

CBP

Toutefois

la

liaison

de

ces

deux

objets

n'est

possible

que

par

la

travers?ee

du

descripteur

de

la

CBP

Services

offerts

Cette

section

d?ecrit

les

diff?erents

services

offerts

par

les

serveurs

aux

clients

de

la

journalisation

Les

services

sont

divis?es

en

trois

cat?egories

correspondant

a

trois

niveaux

de

s?ecurit?e

ceux

r?eserv?es

aux

clients

ordinaires

qui

ont

une

connaissance

moindre

du

service

de

journalisation

ceux

r?eserv?es

a

certains

clients

privil?egi?es

tels

que

les

programmes

de

contr

ole

qui

peuvent

aller

jusqu

a

arr

eter

le

fonctionnement

du

serveur

et

ceux

r?eserv?es

aux

serveurs

eux-m

emes

qui

sont

asynchrones

La

s?ecurit?e

dans

KitLog

sera

d?ecrite

au

La

figure

V.

donne

la

liste

compl?ete

des

services

Services

g?en?eraux

Les

services

g?en?eraux

peuvent

etre

appel?es

par

n'importe

quel

processus

request

effectue

un

simple

appel

vide

au

serveur

qui

retourne

un

accus?e

de

r?eception

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

Services

g?en?eraux

request

Requ

ete

vide

Connect

Demande

de

connexion

Disconnect

Demande

de

d?econnexion

Services

d'initialisation

de

la

journalisation

Init

appli

Initialisation

d'une

application

Free

appli

Terminaison

normale

d'une

application

Reread

graph

Demande

de

relecture

du

graphe

Activate

view

Activation

d'une

vue

de

journalisation

Passivate

view

D?esactivation

d'une

vue

de

journalisation

Services

pour

l'invocation

des

vues

de

journalisation

Create

log

Cr?eation

d'un

journal

logique

Destroy

log

Destruction

d'un

journal

logique

Get

lid

Recherche

de

l'identificateur

d'un

journal

logique

Open

log

Ouverture

d'un

journal

logique

Close

log

Fermeture

d'un

journal

logique

Put

Les

deux

op?erations

put

-LRB-

-RRB-

Get

Les

quatre

op?erations

get

-LRB-

-RRB-

Flush

L'op

eration

flush

-LRB-

-RRB-

Infos

L'op

eration

infos

-LRB-

-RRB-

Invalidate

records

Les

trois

op?erations

invalidate

records

-LRB-

-RRB-

Services

asynchrones

pour

l'invocation

des

objets

de

type

bloc

Async

put

L'op

eration

put

-LRB-

-RRB-

Async

get

L'op

eration

get

-LRB-

-RRB-

Async

seek

Les

quatre

op?erations

seek

-LRB-

-RRB-

Async

flush

L'op

eration

flush

-LRB-

-RRB-

Async

prefetch

L'op

eration

prefetch

-LRB-

-RRB-

Async

infos

L'op

eration

infos

-LRB-

-RRB-

Async

invalidate

records

Les

trois

op?erations

invalidate

records

-LRB-

-RRB-

Async

multiple

put

L'op

eration

multiple

put

-LRB-

-RRB-

Async

multiple

get

L'op

eration

multiple

get

-LRB-

-RRB-

Services

asynchrones

de

gestion

des

objets

et

d'information

Create

block

Demande

de

cr?eation

d'un

bloc

Destroy

block

Demande

de

destruction

d'un

bloc

Client

alive

Demande

la

v?erification

de

la

vivacit?e

d'un

client

Client

dead

Signal

de

la

mort

d'un

client

Get

infos

Demande

d'informations

sur

l'

etat

des

serveurs

Set

infos

Envoi

d'informations

sur

l'

etat

des

serveurs

Services

divers

Asynchronous

resp

R?eponse

d'une

demande

asynchrone

Stop

log

server

Demande

-LRB-

synchrone

-RRB-

d'arr

et

du

serveur

Figure

V.

Liste

des

services

-LCB-

-LCB-

Le

service

de

journalisation

Ce

service

permet

de

v?erifier

la

pr?esence

et

la

bonne

marche

du

serveur

et

de

tester

les

communications

Connect

et

Disconnect

permettent

la

connexion

et

la

d?econnexion

d'un

client

au

serveur

La

connexion

etablit

la

communication

entre

clients

et

serveurs

enregistre

le

processus

client

et

effectue

le

travail

n?ecessaire

a

son

authentification

future

-LRB-

voir

-RRB-

La

d?econnexion

est

l'op

eration

inverse

Elle

permet

de

d?esallouer

les

structures

et

objets

d'un

client

Initialisation

de

la

journalisation

Le

service

Init

appli

permet

d'initialiser

une

application

cr?eation

des

descripteurs

n?ecessaires

interpr?etation

de

son

graphe

etc.

Free

appli

est

l'op

eration

inverse

de

terminaison

normale

d'une

application

Reread

graph

permet

de

demander

au

serveur

de

relire

dynamiquement

le

graphe

de

l'application

ou

bien

le

graphe

syst?eme

Si

aucun

conflit

majeur

n'est

d?etect?e

le

graphe

est

reconfigur?e

Dans

le

cas

ou

des

processus

utilisent

des

objets

du

graphe

devant

etre

effac?es

la

demande

de

reconfiguration

echoue

Une

fois

le

graphe

cr?e?e

les

objets

doivent

etre

instanci?es

par

l'activation

des

vues

de

journalisation

Le

service

Activate

view

permet

d'instancier

une

vue

pour

un

processus

donn?e

Il

instancie

r?ecursivement

les

successeurs

de

la

vue

qui

ne

le

sont

pas

encore

Le

service

Passivate

view

permet

l'op

eration

inverse

Les

successeurs

de

la

vue

qui

ne

sont

pas

en

cours

d'utilisation

par

d'autres

processus

sont

d?esinstanci?es

Invocations

des

vues

de

journalisation

Un

service

existe

pour

chacune

des

op?erations

sur

les

vues

de

journalisation

Lorsque

plusieurs

op?erations

peuvent

etre

invoqu?ees

diff?eremment

-LRB-

comme

l'op

eration

put

-LRB-

-RRB-

par

exemple

-RRB-

un

seul

service

assure

les

diff?erentes

formes

de

l'invocation

Nous

ne

d?ecrirons

pas

en

d?etail

le

r

ole

de

ces

services

qui

consiste

a

invoquer

les

op?erations

des

vues

de

journalisation

-LRB-

voir

-RRB-

Le

choix

de

cr?eer

un

service

pour

chaque

op?eration

sur

les

vues

est

un

choix

de

simplification

de

r?ealisation

du

prototype

De

mani?ere

a

pouvoir

accepter

diff?erents

type

de

vues

il

est

n?ecessaire

de

disposer

d'un

seul

service

qui

re?coit

des

demandes

d'invocations

des

vues

de

journalisation

param?etr?ees

par

un

code

d'op

eration

et

les

arguments

d'appel

et

de

retour

Si

le

prototype

avait

r?ealis?e

compl?etement

le

mod?ele

repoussant

les

objets

dans

l'espace

d'adressage

des

clients

ces

services

dispara

traient

puisque

les

vues

de

journalisation

seraient

directement

invoqu?ees

par

les

processus

clients

Toutefois

il

pourrait

etre

int?eressant

de

conserver

une

interface

restreinte

pour

les

clients

non

privil?egi?es

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

Invocations

distantes

des

objets

de

type

bloc

De

m

eme

que

pour

les

vues

un

service

d'invocation

a

distance

existe

pour

chaque

op?eration

sur

les

objets

de

type

bloc

Les

appels

a

ses

services

sont

asynchrones

car

dans

le

prototype

seuls

les

objets

distribution

situ?es

dans

l'espace

d'adressage

des

serveurs

peuvent

invoquer

ces

services

De

la

m

eme

mani?ere

que

pour

les

vues

afin

de

pouvoir

changer

le

type

des

blocs

il

est

n?ecessaire

de

transformer

cet

ensemble

de

services

en

un

seul

service

param?etr?e

par

le

code

de

l'op

eration

a

invoquer

et

ses

arguments

Toutefois

ce

service

devra

exister

tant

que

des

objets

seront

instanci?es

dans

l'espace

d'adressage

du

serveur

de

journalisation

Services

de

gestion

des

objets

et

d'information

Les

services

Create

block

et

Destroy

block

permettent

de

demander

l'instanciation

et

la

destruction

des

objets

entre

serveurs

Ils

sont

utilis?es

au

moment

de

l'activation

ou

la

d?esactivation

des

vues

de

journalisation

lorsque

l'un

des

successeurs

dans

le

graphe

de

la

vue

est

distant

Diff?erents

ev?enements

peuvent

d?eclencher

une

v?erification

g?en?erale

de

la

validit?e

des

donn?ees

d'

etat

d'un

serveur

Les

services

Client

alive

et

Client

dead

permettent

le

ramassage

de

miettes

au

sein

de

l'espace

d'adressage

des

serveurs

Les

miettes

etant

constitu?ees

des

descripteurs

de

requ

etes

inter-serveurs

n'ayant

pas

aboutit

de

descripteurs

et

d'objets

allou?es

pour

des

clients

tomb?es

en

panne

etc.

Le

premier

service

demande

a

un

serveur

distant

de

v?erifier

l'existence

effective

d'un

processus

client

sur

son

site

Le

second

service

signale

a

un

serveur

qu'un

client

est

tomb?e

en

panne

ou

s

est

arr

et?e

normalement

de

fonctionner

Les

serveurs

conservent

des

donn?ees

sur

chacun

des

autres

serveurs

participant

a

la

journalisation

Certains

ev?enements

d?eclenchent

la

v?erification

de

ces

informations

ou

la

transmission

de

l'

etat

connu

ou

suspect?e

d'un

serveur

Le

service

Get

info

permet

de

demander

a

un

serveur

les

informations

dont

il

dispose

sur

l'

etat

des

serveurs

alors

que

le

service

Set

infos

transmet

ces

informations

a

un

autre

serveur

Ces

deux

derniers

services

sont

extensibles

de

mani?ere

a

pouvoir

transf?erer

toutes

sortes

d'informations

entre

serveurs

On

pourrait

par

exemple

etendre

ces

services

afin

de

transf?erer

des

informations

concernant

la

charge

des

machines

et

des

serveurs

si

l'on

souhaitait

effectuer

de

la

r?epartition

de

charge

Services

divers

Le

service

Asynchronous

resp

permet

de

recevoir

les

requ

etes

en

r?eponse

d'une

demande

de

service

asynchrone

C'est

le

seul

service

qui

ne

renvoie

pas

de

r?eponse

Enfin

le

service

Stop

log

server

permet

d'arr

eter

proprement

un

serveur

Son

appel

est

r?eserv?e

aux

programmes

de

contr

ole

L'appel

est

synchrone

afin

de

pouvoir

d?eterminer

le

moment

exact

de

l'arr

et

d'un

serveur

Ceci

est

utile

pour

pouvoir

le

relancer

-LCB-

-LCB-

Mod?ele

de

pannes

d?etection

et

traitement

Mod?ele

de

pannes

d?etection

et

traitement

Cette

section

d?ecrit

le

mod?ele

de

pannes

suppos?e

par

KitLog

Pour

chaque

type

de

panne

nous

d?ecrivons

la

m?ethode

de

d?etection

suppos?ee

ou

r?ealis?ee

et

la

r?eaction

aux

erreurs

engendr?ees

D?efaillances

erreurs

fautes

et

pannes

Les

d?efinitions

des

termes

d?efaillance

faute

et

erreur

sont

calqu?ees

sur

celles

de

Powell

-LRB-

-LSB-

Powell

-RSB-

-RRB-

Une

d?efaillance

survient

lorsqu'un

syst?eme

se

comporte

d'une

mani?ere

erron?ee

par

rapport

a

ses

sp?ecifications

Une

erreur

est

la

partie

de

l'

etat

du

syst?eme

susceptible

d'entra

ner

une

d?efaillance

Une

faute

est

la

cause

d'une

erreur

mais

aussi

la

cons?equence

d'une

d?efaillance

Elle

peut

etre

dormante

ou

active

Une

faute

active

produit

des

erreurs

qui

peuvent

produire

a

leur

tour

de

nouvelles

d?efaillances

On

obtient

ainsi

le

sch?ema

suivant

faute

erreur

d?ef

aillance

faute

erreur

d?ef

aillance

Un

certain

nombre

de

taxonomies

des

fautes

ont

et?e

faites

-LSB-

Cristian

et

al.

Powell

Br?es

-RSB-

Elles

correspondent

g?en?eralement

a

un

mod?ele

de

processus

communiquant

par

messages

o?u

la

vision

des

fautes

est

celle

des

processus

Notre

approche

est

plus

pragmatique

et

d?efinit

un

certain

nombre

de

pannes

ind?ependantes

de

la

vision

que

l'on

peut

en

avoir

et

dont

nous

consid?erons

les

cons?equences

Nous

d?efinissons

une

panne

comme

une

classe

particuli?ere

de

d?efaillances

ayant

pour

origine

suppos?ee

une

erreur

mat?erielle

ou

physique

-LRB-

d?ebranchement

d'un

c

able

Ethernet

par

exemple

-RRB-

et

dont

la

cons?equence

est

la

perte

ou

l'indisponibilit

e

de

donn?ees

Plus

pr?ecis?ement

sans

vouloir

etre

exhaustif

nous

allons

d?efinir

un

certain

nombre

de

pannes

dont

nous

allons

etudier

les

m?ethodes

de

d?etection

et

la

r?eaction

de

KitLog

aux

erreurs

qu'elles

g?en?erent

Une

perte

de

secteurs

est

caract?eris?ee

par

la

perte

d'un

certain

nombre

de

secteurs

-LRB-

ou

de

blocs

-RRB-

sur

un

support

de

stockage

physique

Une

panne

de

support

de

stockage

m?ene

a

l'indisponibilit

e

compl?ete

du

support

ou

a

la

perte

compl?ete

de

son

contenu

Une

panne

de

communication

est

une

non

r?eception

une

alt?eration

d?etect?ee

ou

un

d?es?equencement

de

messages

Une

panne

de

processus

est

l'arr

et

anormal

d'un

processus

menant

a

la

perte

de

son

contexte

d'ex

ecution

Une

panne

de

site

m?ene

a

la

perte

de

sa

m?emoire

volatile

Une

panne

de

r?eseau

correspond

a

l'isolation

d'une

ou

de

plusieurs

machines

de

l'ensemble

des

autres

machines

Nous

nous

restreignons

aux

pannes

qui

nous

semble

pouvoir

survenir

dans

l'environnement

choisi

Par

exemple

etant

donn?e

qu'avec

les

hypoth?eses

que

nous

avons

faites

les

machines

sont

toutes

reli?ees

par

un

m

eme

c

able

Ethernet

le

d?es?equencement

eventuel

de

messages

ne

peut

pas

provenir

d'un

retard

de

transmission

d

u

a

une

passerelle

surcharg?ee

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

D?etection

et

traitement

des

pannes

dans

KitLog

Pour

chaque

type

de

panne

consid?er?e

nous

donnons

une

ou

plusieurs

causes

probables

et

en

evaluons

les

cons?equences

directes

possibles

De

ces

cons?equences

nous

en

d?eduisons

des

m?ethodes

de

d?etection

et

si

possible

une

m?ethode

de

traitement

Au

cas

o?u

la

cause

de

la

panne

est

diff?erente

de

celles

envisag?ees

nous

supposerons

qu'une

m?ethode

de

d?etection

existe

permettant

de

se

retrouver

dans

un

des

cas

trait?es

Nos

m?ethodes

de

traitement

de

pannes

ne

sont

pas

tr?es

fines

mais

elles

permettent

de

r?esoudre

bon

nombre

de

cas

pratiques

Perte

de

secteur

La

d?etection

des

pertes

de

secteur

du

journal

physique

est

suppos?ee

etre

faite

par

le

contr

oleur

du

support

de

stockage

La

perte

de

secteurs

peut

avoir

lieu

lors

d'une

erreur

mat?erielle

au

cours

d'une

ecriture

Dans

ce

cas

quelques

secteurs

cons?ecutifs

peuvent

comporter

des

donn?ees

erron?ees

Si

l'erreur

n

a

pas

eu

lieu

ou

n

a

pas

et?e

d?etect?ee

au

moment

de

l'

ecriture

lors

d'une

lecture

de

ces

secteurs

le

contr

oleur

d?etecte

l'incoh

erence

-LRB-

par

utilisation

de

bits

de

parit?e

par

exemple

-RRB-

L'erreur

une

fois

d?etect?ee

est

transmise

au

serveur

de

journalisation

pour

le

compte

de

qui

l'

ecriture

ou

la

lecture

a

et?e

faite

La

panne

lors

d'une

erreur

d'

ecriture

sur

un

disque

lorsqu'elle

est

d?etect?ee

peut

souvent

etre

corrig?ee

par

une

r?e

ecriture

en

place

des

donn?ees

Lorsque

ce

n'est

pas

le

cas

il

est

parfois

n?ecessaire

de

remplacer

les

secteurs

concern?es

par

des

secteurs

de

secours

Cette

op?eration

n?ecessite

une

intervention

manuelle

pour

ajouter

les

secteurs

a

la

liste

des

secteurs

d?efectueux

du

disque

Enfin

dans

le

pire

des

cas

il

est

n?ecessaire

de

reformater

enti?erement

le

disque

Lorsqu'une

telle

erreur

est

diagnostiqu?ee

le

serveur

de

journalisation

elimine

le

support

de

stockage

du

graphe

syst?eme

qu'il

conserve

en

m?emoire

et

d?etruit

les

objets

concern?es

Eventuellement

il

proc?edera

a

une

reconfiguration

des

graphes

de

ses

clients

Lorsque

le

serveur

re?coit

une

demande

de

relecture

de

son

graphe

syst?eme

ou

lorsqu'il

red?emarre

il

suppose

que

le

support

de

stockage

s

il

est

toujours

dans

le

graphe

a

et?e

r?epar?e

l'erreur

a

disparu

si

n?ecessaire

des

marqueurs

de

fin

de

secteurs

valides

ont

et?e

ecrits

dans

les

secteurs

r?epar?es

mais

les

donn?ees

perdues

n'ont

pas

et?e

restaur?ees

Suivant

la

nature

des

secteurs

perdus

et

la

nature

des

eventuels

blocs

de

r?eplication

utilis?es

le

serveur

et

les

blocs

de

r?eplication

recouvrent

une

partie

ou

la

totalit?e

des

informations

perdues

-LRB-

voir

du

chapitre

IV

-RRB-

Pannes

de

support

de

stockage

La

panne

d'un

support

de

stockage

r?esulte

soit

en

une

perte

totale

des

donn?ees

du

support

soit

en

l'indisponibilit

e

de

celui-ci

Le

traitement

de

pannes

effectu?e

est

le

m

eme

que

pr?ec?edemment

Dans

des

cas

comme

la

coupure

de

l'alimentation

d'un

disque

la

d?etection

de

la

panne

est

imm?ediate

par

un

syst?eme

d'exploitation

Nous

-LCB-

-LCB-

Mod?ele

de

pannes

d?etection

et

traitement

supposerons

que

ce

type

de

d?etection

est

possible

dans

tous

les

cas

et

qu'un

message

d'erreur

en

cons?equence

est

d?elivr?e

au

serveur

La

perte

de

la

totalit?e

d'un

support

n'arrive

jamais

dans

la

pratique

il

s

agit

plut

ot

du

changement

d'un

support

par

un

autre

par

exemple

a

la

suite

d'une

panne

mat?erielle

non

r?eparable

On

supposera

dans

ce

cas

que

le

serveur

de

journalisation

aura

et?e

arr

et?e

proprement

au

pr?ealable

ou

qu'une

panne

de

secteur

a

eu

lieu

pr?ec?edemment

Dans

le

cas

du

remplacement

d'un

support

de

stockage

par

un

nouveau

support

neuf

-LRB-

et

format?e

-RRB-

le

bloc

support

d?etecte

automatiquement

par

lecture

des

N

premiers

secteurs

-LRB-

N

vaut

dans

le

prototype

-RRB-

qu'il

n

a

pas

et?e

initialis?e

pour

la

journalisation

et

effectue

l'initialisation

de

ces

secteurs

qui

constitue

l'initialisation

du

support

Pannes

de

communication

Les

pannes

de

communication

peuvent

etre

de

trois

ordres

perte

de

messages

alt?eration

du

contenu

des

messages

ou

d?es?equencement

des

messages

Les

communications

entre

clients

et

serveur

et

entre

serveurs

sont

effectu?ees

au

moyen

du

protocole

TCP

-LSB-

Postel

-RSB-

Ce

protocole

se

charge

de

ces

trois

types

de

probl?eme

Dans

la

suite

nous

supposerons

les

communications

fiables

Nous

reviendrons

sur

le

probl?eme

du

d?es?equencement

au

du

chapitre

VI

Pannes

de

processus

La

panne

d'un

processus

se

produit

lorsqu'un

processus

est

arr

et?e

par

le

syst?eme

dans

des

circonstances

menant

a

la

perte

du

contenu

de

son

espace

d'adressage

Elle

peut

etre

d?etect?ee

gr

ace

au

principe

de

fonctionnement

des

sockets

de

type

stream

utilis?ee

par

le

protocole

TCP

dans

son

impl?ementation

sous

SunOS

Lorsqu'un

serveur

dispose

d'une

socket

avec

un

processus

r?eguli?erement

il

consulte

l'

etat

de

la

socket

En

cas

de

panne

d'un

processus

connect?e

la

consultation

de

l'

etat

de

la

socket

rend

une

erreur

appropri?ee

fournie

par

le

syst?eme

d'exploitation

On

peut

alors

tester

s

il

s

agit

d'une

panne

d'un

processus

isol?e

ou

non

Si

le

processus

est

un

client

ordinaire

le

serveur

d?etruit

les

objets

non

partag?es

utilis?es

par

ce

processus

Il

signale

alors

aux

serveurs

ayant

cr?e?e

des

objets

pour

ce

processus

la

mort

du

client

afin

qu'ils

puissent

r?ealiser

le

travail

de

ramasse-miettes

n?ecessaire

Si

le

processus

est

un

serveur

le

traitement

est

plus

d?elicat

Les

objets

cr?e?es

pour

le

compte

d'un

client

de

ce

serveur

ne

devraient

pas

etre

d?etruits

si

le

client

est

toujours

vivant

et

s

il

a

un

moyen

de

les

acc?eder

directement

sans

passer

par

l'interm

ediaire

du

serveur

en

panne

Le

probl?eme

est

d'autant

plus

complexe

que

le

client

doit

trouver

un

serveur

capable

de

remplacer

celui

en

panne

Ceci

n'est

pas

r?ealis?e

dans

le

prototype

et

les

objets

des

clients

ayant

pour

interlocuteur

principal

le

serveur

en

panne

sont

d?etruits

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

Pannes

de

site

et

pannes

de

r?eseau

Au

niveau

de

la

d?etection

une

machine

est

incapable

de

diff?erencier

une

panne

de

site

d'une

panne

de

r?eseau

Lorsque

l'une

de

ces

pannes

se

produit

la

connexion

TCP

entre

les

serveurs

de

journalisation

vivants

et

ceux

qui

ne

peuvent

plus

etre

atteint

est

rompue

La

d?etection

de

ce

fait

est

imm?ediatement

signal?ee

par

le

syst?eme

La

nature

de

la

panne

ne

pourra

etre

connue

que

lorsque

celle-ci

aura

et?e

r?epar?ee

Durant

de

telles

pannes

les

serveurs

traitent

les

processus

inatteignables

comme

un

ensemble

de

processus

en

panne

Lorsque

la

panne

est

corrig?ee

et

qu'il

s

agit

d'une

panne

r?eseau

ayant

entra

n?e

un

partitionnement

des

machines

un

traitement

sp?ecial

peut

etre

effectu?e

selon

que

les

blocs

constituant

le

graphe

d'une

application

tiennent

compte

du

partionnement

ou

non

Apr?es

une

panne

d'un

site

lorsque

un

serveur

de

journalisation

est

lanc?e

sur

ce

site

il

recr?ee

les

connexions

avec

les

autres

serveurs

et

eventuellement

d?eclenche

une

reprise

sur

panne

D?erive

des

horloges

La

d?erive

relative

des

horloges

peut

poser

certains

probl?emes

de

synchronisation

des

processus

Imaginons

deux

processus

sur

deux

sites

distincts

partageant

un

m

eme

journal

logique

Chaque

processus

demande

au

service

de

journalisation

de

g?en?erer

les

Rid

des

enregistrements

qu'il

ajoute

au

journal

Les

Rid

doivent

etre

uniques

et

croissants

avec

le

temps

Les

Rid

g?en?er?es

par

le

service

de

journalisation

comportent

dans

l'ordre

la

date

compos?ee

du

nombre

de

secondes

depuis

le

premier

janvier

et

du

nombre

de

micro-secondes

et

l'identificateur

unique

du

site

de

g?en?eration

Un

Rid

Ri

est

plus

grand

qu'un

Rid

Rj

si

le

nombre

de

secondes

de

Ri

est

sup?erieur

a

celui

de

Rj

ou

bien

si

leur

nombre

de

secondes

est

egal

et

que

le

nombre

de

micro-secondes

de

Ri

est

sup?erieur

a

celui

de

Rj

ou

enfin

si

les

dates

sont

egales

et

que

l'identificateur

de

site

de

Ri

est

sup?erieur

a

celui

de

Rj

En

supposant

que

les

horloges

des

machines

indiquent

la

date

r?eelle

exacte

l'ordre

de

g?en?eration

des

Rid

correspond

a

l'ordre

des

Rid

a

l'exception

du

cas

o?u

ils

sont

g?en?er?es

au

m

eme

instant

Dans

ce

cas

un

ordre

arbitraire

est

fix?e

par

l'ordre

des

identificateurs

de

site

Dans

le

cas

o?u

les

horloges

d?erivent

les

unes

par

rapport

aux

autres

la

propri?et?e

entre

les

Rid

d'un

m

eme

journal

logique

allou?es

sur

des

sites

diff?erents

est

plus

complexe

a

maintenir

et

n?ecessite

de

mettre

en

oeuvre

un

algorithme

r?eparti

complexe

au

passage

que

cela

donne

une

long?evit?e

de

ans

pour

la

g?en?eration

des

Rid

a

partir

de

cette

date

soit

jusqu'en

-LRB-

a

condition

de

stocker

le

nombre

de

secondes

dans

un

unsigned

long

sur

bits

-RRB-

-LCB-

-LCB-

Mod?ele

de

pannes

d?etection

et

traitement

Nous

avons

suppos?e

au

que

la

d?erive

relative

des

horloges

durant

un

laps

de

temps

r?eel

fixe

ffit

est

born?ee

par

une

limite

finie

et

connue

En

supposant

que

les

horloges

soient

remises

a

jour

a

une

m

eme

heure

tous

les

ffit

-LRB-

ce

laps

de

temps

comprenant

la

dur?ee

maximum

permettant

d'effectuer

la

mise

a

jour

-RRB-

une

solution

permettant

de

conserver

la

propri?et?e

des

Rid

consiste

a

ramener

a

une

valeur

inf?erieure

au

temps

n?ecessaire

pour

la

construction

d'un

Rid

Nous

supposons

que

lorsque

cette

solution

n'est

pas

r?ealis?ee

dans

le

prototype

l'application

cliente

g?en?ere

ses

propres

Rid

Pannes

et

coh?erence

des

journaux

logiques

Suite

a

une

panne

un

journal

logique

consid?er?e

dans

sa

totalit?e

peut

poser

des

probl?emes

de

coh?erence

En

effet

un

journal

logique

o?u

il

manquerait

des

enregistrements

ou

bien

conservant

vivants

des

enregistrements

qui

ont

et?e

d?eclar?es

obsol?etes

peut

etre

consid?er?e

comme

incoh?erent

Le

manque

de

certains

enregistrements

suite

a

une

panne

de

site

ou

de

disque

a

d?ej?a

et?e

discut?e

et

doit

etre

r?esolu

par

un

algorithme

de

r?eplication

qui

maintient

un

certain

nombre

de

copies

avec

une

politique

de

coh?erence

appropri?ee

L'incoh

erence

r?esultant

d'une

panne

lors

de

la

d?eclaration

d'enregistrements

obsol?etes

est

un

probl?eme

diff?erent

Si

un

journal

logique

est

r?epliqu?e

sur

diff?erents

sites

et/ou

supports

de

stockage

une

panne

d'un

de

ces

el?ements

peut

conduire

a

des

journaux

logiques

contenant

des

enregistrements

vivants

bien

que

d?eclar?es

obsol?etes

et

donc

jamais

effac?es

Lorsqu'un

client

lit

s?equentiellement

un

journal

logique

il

peut

obtenir

des

lectures

diff?erentes

en

fonction

du

support

de

lecture

choisi

Bien

que

non

r?ealis?ees

dans

le

prototype

plusieurs

solutions

sont

envisageables

La

premi?ere

solution

consisterait

en

d?ebut

de

compactage

a

questionner

les

diff?erents

serveurs

pour

obtenir

d'eux

la

liste

de

leurs

enregistrements

obsol?etes

Ainsi

petit

a

petit

on

efface

les

enregistrements

inutiles

d'une

mani?ere

paresseuse

un

enregistrement

d?eclar?e

obsol?ete

a

un

serveur

en

panne

au

moment

de

cette

interrogation

peut

rester

vivant

apr?es

le

compactage

mais

dispara

tra

a

long

terme

Une

seconde

solution

plus

complexe

et

ne

n?ecessitant

pas

de

synchronisation

entre

les

serveurs

consisterait

apr?es

qu'un

serveur

ait

effectu?e

son

compactage

a

ce

qu'il

construise

pour

chaque

journal

logique

la

liste

des

enregistrements

restant

vivants

et

qu'il

la

diffuse

a

l'ensemble

des

serveurs

disposant

d'une

portion

de

ce

journal

logique

Lorsque

un

serveur

compacte

son

journal

il

lit

les

diff?erentes

listes

d'enregistrements

vivants

stock?ees

et

construit

pour

chaque

liste

qu'on

lui

a

envoy?e

la

liste

des

enregistrements

obsol?etes

que

l'autre

serveur

a

laiss?e

vivants

L'envoi

de

ces

listes

permet

de

r?etablir

la

coh?erence

de

mani?ere

paresseuse

tels

algorithmes

de

mises

a

jour

r?eparties

des

horloges

existent

voir

par

exemple

NTP

-LSB-

Crowcroft

et

Onions

-RSB-

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

S?ecurit?e

Les

services

sont

d?ecoup?es

en

quatre

niveaux

de

protection

correspondant

a

quatre

sortes

de

clients

-LRB-

ce

m?ecanisme

est

inspir?e

du

m?ecanisme

des

anneaux

de

protection

de

Multics

-LSB-

Berstel

et

Perrot

-RSB-

-RRB-

Chaque

niveau

de

protection

donne

des

droits

croissants

par

rapport

aux

pr?ec?edents

Le

niveau

trois

correspond

a

des

services

pouvant

etre

invoqu?es

par

tous

processus

Le

niveau

deux

correspond

a

des

clients

ordinaires

et

donne

le

droit

d'acc

eder

aux

services

de

journalisation

Le

niveau

un

est

r?eserv?e

a

des

clients

avertis

et

permet

un

certain

contr

ole

des

serveurs

de

journalisation

-LRB-

par

exemple

leur

arr

et

propre

-RRB-

Le

niveau

z?ero

est

r?eserv?e

aux

serveurs

de

journalisation

et

donne

acc?es

a

tous

les

services

Les

diff?erents

clients

de

niveaux

inf?erieurs

a

trois

du

service

de

journalisation

doivent

etre

inscrits

dans

un

fichier

de

configuration

avant

de

pouvoir

effectuer

une

requ

ete

a

l'un

des

serveurs

Ce

fichier

est

sens?e

n

etre

lisible

que

par

les

serveurs

de

journalisation

et

doit

etre

maintenu

par

un

administrateur

de

la

journalisation

Nom

Identificateur

Cl?e

Niveau

Logging

Server

Monitor

Client

Client

Figure

V.

Exemple

de

configuration

d'application

Pour

chaque

client

le

fichier

-LRB-

cf.

figure

V.

-RRB-

comprend

un

nom

d'application

un

identificateur

unique

une

cl?e

et

un

niveau

Le

nom

d'application

est

une

cha

ne

de

caract?ere

quelconque

utilis?ee

pour

d?eterminer

l'identificateur

unique

de

l'application

L'identificateur

est

un

identificateur

unique

du

client

La

cl?e

est

un

num?ero

arbitraire

quelconque

son

r

ole

est

similaire

a

celui

d'un

mot

de

passe

Authentification

Lors

de

son

d?emarrage

une

application

donne

son

nom

et

sa

cl?e

a

la

proc?edure

d'initialisation

de

la

librairie

cliente

Celle-ci

obtient

du

serveur

l'identificateur

de

l'application

et

construit

un

descripteur

du

client

comportant

la

cl?e

qui

servira

pour

tout

appel

successif

au

serveur

Ce

m?ecanisme

simple

repose

sur

le

fait

que

les

cl?es

sont

tenues

secr?etes

Il

est

con?cu

de

mani?ere

a

r?ealiser

un

minimum

de

s?ecurit?e

Une

cl?e

peut

etre

d?ecouverte

par

l'essai

successif

de

toutes

les

combinaisons

possibles

ou

bien

par

capture

des

paquets

transitant

sur

le

r?eseau

Toutefois

ce

m?ecanisme

est

construit

de

mani?ere

a

comporter

tous

les

el?ements

n?ecessaires

a

la

r?ealisation

dans

l'avenir

de

m?ecanisme

plus

s

urs

tel

que

la

cryptographie

-LSB-

Needham

Blain

-RSB-

-LCB-

-LCB-

S?ecurit?e

Droits

d'acc

es

et

partage

Le

partage

possible

des

journaux

logiques

des

sous-graphes

et

des

journaux

physiques

n?ecessite

des

m?ecanismes

de

protection

additionnels

Partage

de

journaux

logiques

Pour

que

deux

processus

puissent

partager

un

journal

logique

ils

doivent

conna

tre

son

identit?e

-LRB-

Lid

-RRB-

ou

bien

ils

doivent

appartenir

a

la

m

eme

application

et

utiliser

une

vue

de

journalisation

ayant

le

m

eme

nom

pour

conna

tre

son

Lid

a

partir

de

l'identificateur

associ?e

au

journal

logique

par

le

cr?eateur

de

celui-ci

Lors

de

la

cr?eation

d'un

journal

logique

des

droits

lui

sont

associ?es

Nous

avons

diff?erenci?e

les

droits

en

lecture

des

droits

en

ecriture

et

distingu?e

trois

types

de

partage

Un

journal

logique

peut

ne

pas

etre

partageable

etre

partageable

par

les

diff?erents

processus

d'une

m

eme

application

etre

partageable

par

tous

Ces

droits

ne

s

appliquent

que

pour

le

niveau

de

l'application

qui

cr?ee

le

journal

et

les

niveaux

sup?erieurs

Les

niveaux

inf?erieurs

ont

tous

les

droits

sur

un

journal

logique

Les

droits

d'acc

es

sont

v?erifi?es

lors

du

premier

acc?es

par

un

processus

au

journal

logique

Le

cas

de

journaux

logiques

non

partageables

est

particulier

Le

journal

logique

est

alors

r?eserv?e

au

processus

qui

le

cr?ee

Lorsque

celui-ci

se

termine

aucun

autre

processus

ne

peut

le

r?eutiliser

En

cons?equence

de

quoi

un

journal

logique

non

partageable

est

un

journal

logique

temporaire

Partage

de

sous-graphes

Les

objets

de

partage

permettent

de

partager

un

-LRB-

ou

plusieurs

-RRB-

journal

physique

Lors

de

la

description

de

ces

objets

dans

un

fichier

de

configuration

les

droits

d'acc

es

aux

objets

de

partage

y

sont

d?ecrits

Les

droits

d'acc

es

ne

distinguent

pas

la

lecture

de

l'

ecriture

Les

objets

de

partage

peuvent

appartenir

au

syst?eme

et

dans

ce

cas

etre

partageables

par

tous

les

clients

admis

a

journaliser

ou

bien

etre

r?eserv?es

a

une

application

Les

droits

d'acc

es

aux

blocs

de

partage

d?efinissent

les

droits

sur

tous

leurs

successeurs

et

permettent

de

g?erer

le

partage

des

ressources

physiques

Les

droits

d'acc

es

sont

v?erifi?es

lors

de

la

liaison

comme

pr?ed?ecesseur

d'un

objet

a

un

objet

de

partage

Composition

des

droits

d'acc

es

Trois

sortes

de

droits

d'acc

es

sont

d?efinis

a

partir

des

niveaux

des

clients

des

droits

d'acc

es

associ?es

aux

journaux

logiques

et

de

ceux

associ?es

aux

sous-graphes

La

composition

de

ces

modes

d'acc

es

donne

un

certain

nombre

de

combinaison

pour

le

partage

des

donn?ees

d'un

client

d'un

certain

niveau

La

figure

V.

donne

les

droits

d'acc

es

r?esultant

pour

le

partage

des

donn?ees

d'un

client

de

niveau

Les

clients

de

niveau

et

ont

tous

les

droits

d'acc

es

sur

le

journal

logique

du

client

de

niveau

Ceux

de

niveau

n'en

ont

aucun

Les

clients

de

niveau

peuvent

acc?eder

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

Niveau

du

client

Graphe

partageable

Tout

acc?es

Tout

acc?es

Acc?es

restreint

Pas

d'acc

es

Graphe

non

partageable

Tout

acc?es

Tout

acc?es

Pas

d'acc

es

Pas

d'acc

es

Figure

V.

Droits

d'acc

es

a

un

journal

logique

d'un

client

de

niveau

au

journal

logique

si

ses

enregistrements

passent

par

un

bloc

de

partage

L'acc

es

est

restreint

aux

droits

associ?es

au

partage

du

journal

logique

Pour

chaque

niveau

une

table

de

combinaisons

similaire

peut

etre

construite

Si

n?ecessaire

cette

m?ethode

de

gestion

des

droits

d'acc

es

peut

etre

raffin?ee

par

l'introduction

de

groupes

d'applications

et

la

distinction

plus

pr?ecise

des

diff?erents

modes

d'acc

es

Nommage

des

journaux

logiques

Les

journaux

logiques

sont

manipul?es

au

moyen

de

Lid

Du

point

de

vue

d'un

client

les

Lid

sont

des

valeurs

arbitraires

d?elivr?ees

par

le

service

de

journalisation

a

la

cr?eation

des

journaux

logiques

Initialement

KitLog

ne

proposait

pas

de

m?ecanisme

additionnel

pour

nommer

les

journaux

Le

client

devait

g?erer

lui-m

eme

la

m?emorisation

des

Lid

afin

de

pouvoir

r?eouvrir

un

journal

logique

Il

s

est

av?er?e

qu'un

m?ecanisme

de

nommage

des

journaux

logiques

etait

indispensable

Par

exemple

dans

le

cas

d'un

syst?eme

de

fichiers

enti?erement

journalis?e

il

est

impossible

au

syst?eme

de

fichiers

de

m?emoriser

la

liste

de

ses

journaux

logiques

ailleurs

que

sur

le

journal

physique

Par

cons?equent

il

etait

n?ecessaire

pour

chaque

application

de

disposer

d'au

moins

un

journal

identifiable

de

mani?ere

ind?ependante

des

identificateurs

uniques

de

journaux

Pour

r?esoudre

le

probl?eme

de

nommage

sans

pour

autant

cr?eer

un

service

de

nommage

complet

KitLog

permet

de

rep?erer

un

journal

logique

par

un

entier

arbitraire

et

un

nom

de

vue

de

journalisation

donn?e

par

l'application

a

la

cr?eation

du

journal

logique

La

correspondance

entre

cet

entier

le

nom

de

la

vue

et

l'identificateur

unique

d'application

permet

ainsi

de

retrouver

le

Lid

du

journal

correspondant

gr

ace

a

l'op

eration

get

lid

-LRB-

-RRB-

de

l'interface

des

vues

L'association

de

la

vue

de

la

journalisation

avec

l'entier

donn?e

par

l'application

permet

pour

chaque

vue

d'avoir

un

identificateur

identique

pour

un

journal

donn?e

Ceci

permet

par

exemple

a

une

application

r?epartie

qui

utiliserait

une

vue

de

journalisation

sur

chaque

site

d'associer

un

identificateur

commun

a

un

journal

logique

qui

aurait

un

r

ole

identique

sur

chaque

site

Les

vues

etant

d?esign?ees

par

leur

nom

symbolique

choisi

par

le

programmeur

d'application

la

totalit?e

de

l'identification

du

journal

logique

est

bien

effectu?ee

par

l'application

-LCB-

-LCB-

Simulation

de

types

en

C++

Simulation

de

types

en

C++

L'un

des

principaux

probl?emes

lors

de

la

conception

de

KitLog

a

et?e

la

simulation

du

type

abstrait

des

blocs

en

C++

Cette

section

apr?es

avoir

expos?e

la

probl?ematique

d?ecrit

les

solutions

envisag?ees

Probl?ematique

C++

-LSB-

Stroustrup

-RSB-

est

un

langage

qui

ne

diff?erencie

pas

les

notions

de

type

et

de

classe

Trois

principes

de

base

sont

n?ecessaires

pour

la

r?ealisation

de

la

composition

d'objets

telle

que

nous

l'avons

d?efinie

p

Un

type

encapsule

la

protection

des

invocations

entre

objets

un

objet

ne

peut

invoquer

les

op?erations

d'un

autre

objet

que

s

il

se

conforme

au

m

eme

type

ou

bien

si

son

type

y

est

explicitement

autoris?e

p

Une

classe

est

la

r?ealisation

d'un

type

Les

objets

dont

les

classes

r?ealisent

le

m

eme

type

doivent

pouvoir

invoquer

mutuellement

leurs

op?erations

p

La

d?erivation

des

classes

de

C++

doit

conserver

la

protection

li?ee

au

type

sans

la

restreindre

De

ces

principes

de

base

d?ecoulent

un

certain

nombre

de

contraintes

pour

la

r?ealisation

des

types

abstraits

des

blocs

-LRB-

type

Block

-RRB-

dans

KitLog

Une

classe

conforme

au

type

Block

peut

invoquer

les

op?erations

des

autres

classes

r?ealisant

ce

type

Une

vue

de

journalisation

encapsule

une

interface

d'acc

es

a

un

type

Block

Elle

peut

a

ce

titre

invoquer

un

sous-ensemble

des

op?erations

de

ce

type

L'invocation

des

op?erations

du

type

Block

est

limit?ee

aux

classes

r?ealisant

ce

type

et

aux

vues

de

journalisation

qui

y

sont

explicitement

autoris?ees

Les

objets

des

classes

d?eriv?ees

de

classes

conformes

au

type

Block

se

comportent

comme

ceux

de

leurs

classes

de

base

leurs

op?erations

peuvent

etre

invoqu?ees

par

une

vue

de

journalisation

et

ils

peuvent

invoquer

toute

op?eration

d'un

objet

dont

la

classe

se

conforme

au

m

eme

type

L'ajout

d'une

nouvelle

classe

r?ealisant

le

type

Block

ne

doit

pas

n?ecessiter

la

modification

du

code

des

classes

existantes

ou

de

celui

des

vues

de

journalisation

Premi?ere

solution

La

figure

V.

illustre

la

premi?ere

solution

Le

type

abstrait

des

blocs

est

r?ealis?e

par

une

classe

abstraite

Block

Les

diff?erents

blocs

sont

r?ealis?es

par

des

classes

d?eriv?ees

de

la

classe

abstraite

-LRB-

Ditribution

et

Sharing

-RRB-

ou

par

des

classes

d?eriv?ees

de

ces

derni?eres

-LRB-

-RRB-

Une

vue

de

journalisation

est

r?ealis?ee

par

une

classe

ind?ependante

-LRB-

Logging

view

-RRB-

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

class

Block

f

protected

Block

successor

public

void

attach

-LRB-

Block

block

-RRB-

fsuccessor

block

g

virtual

void

op

-LRB-

-RRB-

g

class

Sharing

public

Block

f

private

virtual

void

op

-LRB-

-RRB-

fif

-LRB-

successor

-RRB-

successor

op

-LRB-

-RRB-

g

g

class

Distribution

public

Block

f

private

virtual

void

op

-LRB-

-RRB-

fif

-LRB-

successor

-RRB-

successor

op

-LRB-

-RRB-

g

g

class

public

Distribution

f

private

virtual

void

op

-LRB-

-RRB-

fif

-LRB-

successor

-RRB-

successor

op

-LRB-

-RRB-

g

g

class

Logging

view

f

Block

successor

public

Logging

view

-LRB-

Block

successor

-RRB-

fthis

successor

successor

g

void

vop

-LRB-

-RRB-

fif

-LRB-

successor

-RRB-

successor

op

-LRB-

-RRB-

g

g

main

-LRB-

-RRB-

f

Block

sharing

new

Sharing

Block

distribution

new

Logging

view

view

new

Logging

view

-LRB-

sharing

-RRB-

sharing

attach

-LRB-

distribution

-RRB-

view

vop

-LRB-

-RRB-

g

Figure

V.

Une

r?ealisation

du

type

Block

-LCB-

-LCB-

Simulation

de

types

en

C++

Une

op?eration

op

-LRB-

-RRB-

est

d?efinie

par

les

trois

classes

r?ealisant

les

blocs

Sharing

Distribution

et

Son

interface

est

d?eclar?ee

par

le

type

abstrait

des

blocs

au

moyen

d'une

d?eclaration

de

fonction

purement

virtuelle

dans

la

classe

La

vue

de

journalisation

d?efinie

une

op?eration

vop

-LRB-

-RRB-

qui

prot?ege

l'appel

a

la

fonction

op

-LRB-

-RRB-

des

classes

r?ealisant

les

blocs

Les

diff?erentes

classes

ont

chacune

un

successeur

potentiel

La

classe

Logging

view

d?eclare

un

membre

successor

pointeur

sur

un

objet

de

la

classe

abstraite

Block

alors

que

les

trois

classes

r?ealisant

les

blocs

h?eritent

d'un

membre

similaire

de

la

classe

abstraite

Block

Le

constructeur

de

la

classe

Logging

view

-LRB-

fonction

Logging

view

-LRB-

-RRB-

-RRB-

et

la

fonction

attach

-LRB-

-RRB-

des

blocs

-LRB-

h?erit?ee

de

la

classe

abstraite

-RRB-

permettent

a

l'ex

ecution

d'affecter

le

pointeur

successor

pour

qu'il

r?ef?erence

un

objet

de

type

Block

Le

code

du

main

illustre

ceci

en

instanciant

successivement

trois

objets

de

classe

Sharing

Distribution

et

Logging

view

L'objet

sharing

est

attach?e

comme

successeur

de

l'objet

view

et

l'objet

distribution

est

attach?e

comme

successeur

de

l'objet

sharing

L'appel

a

l'op

eration

vop

-LRB-

-RRB-

de

l'objet

view

va

appeler

l'op

eration

op

-LRB-

-RRB-

de

l'objet

sharing

qui

elle

m

eme

appellera

celle

de

l'objet

distribution

L'invocation

directe

des

fonctions

op

-LRB-

-RRB-

des

classes

r?ealisant

les

blocs

est

prot?eg?ee

par

la

d?eclaration

private

des

op?erations

de

la

Ainsi

cette

op?eration

ne

peut

etre

appel?ee

directement

Par

exemple

l'appel

sharing.op

-LRB-

-RRB-

dans

la

partie

main

serait

refus?e

par

le

compilateur

La

d?eclaration

protected

du

membre

successor

de

la

classe

Block

permet

aux

classes

d?eriv?ees

d'acc

eder

a

ce

pointeur

La

d?eclaration

public

de

l'op

eration

op

-LRB-

-RRB-

alli?ee

a

l'utilisation

d'un

h?eritage

public

-LRB-

mot-cl

e

public

dans

la

d?eclaration

des

classes

d?eriv?ees

-RRB-

permet

aux

classes

d?eriv?ees

l'invocation

de

l'op

eration

op

-LRB-

-RRB-

de

leur

successeur

qui

peut

appartenir

a

une

classe

soeur

-LRB-

deux

classes

sont

soeurs

si

elles

d?erivent

de

la

m

eme

classe

de

base

-RRB-

La

d?eclaration

public

des

op?erations

de

la

classe

abstraite

Block

permet

egalement

a

tout

objet

disposant

d'un

membre

de

cette

classe

d'invoquer

ces

op?erations

L'objet

view

utilise

cette

propri?et?e

En

r?esum?e

cette

solution

r?ealise

le

type

abstrait

des

blocs

au

moyen

d'une

classe

abstraite

Block

Les

blocs

sont

r?ealis?es

par

des

classes

d?eriv?ees

de

la

classe

abstraite

La

r?ealisation

de

conformit?e

de

type

est

effectu?ee

par

l'

h?eritage

Une

classe

est

conforme

au

type

Block

si

et

seulement

si

elle

d?erive

publiquement

de

la

classe

abstraite

Block

Cette

solution

permet

de

r?ealiser

les

contraintes

et

d?efinies

au

mais

elle

ne

satisfait

pas

a

la

troisi?eme

En

effet

avec

cette

solution

un

objet

quelconque

peut

invoquer

n'importe

quelle

op?eration

de

l'interface

des

blocs

a

partir

du

moment

o?u

il

d?eclare

un

membre

de

cette

classe

d?eclaration

d'une

fonction

virtuelle

dans

une

classe

effectu?ee

au

moyen

du

mot-cl

e

virtual

autorise

une

red?efinition

de

cette

fonction

dans

les

classes

d?eriv?ees

La

qualification

de

cette

d?eclaration

de

fonction

par

l'expression

oblige

sa

red?efinition

dans

les

classes

d?eriv?ees

et

emp

eche

l'instanciation

de

la

classe

m?ere

que

l'on

appelle

alors

classe

abstraite

mot-cl

e

private

limite

l'acc

es

aux

membres

d'une

classe

-LRB-

donn?ees

ou

op?erations

-RRB-

aux

objets

de

la

m

eme

classe

Le

mot-cl

e

protected

limite

l'acc

es

aux

objets

de

la

classe

et

des

classes

d?eriv?ees

Le

mot-cl

e

public

ne

limite

pas

l'acc

es

Pour

plus

de

d?etails

se

reporter

a

-LSB-

Ellis

et

Stroustrup

-RSB-

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

Variantes

Nous

avons

donc

essay?e

d'affiner

la

r?ealisation

du

type

La

modification

apport?ee

est

illustr?ee

par

la

figure

V.

Les

diff?erentes

classes

pouvant

invoquer

les

op?erations

du

type

ont

et?e

d?eclar?ees

amies

de

la

classe

abstraite

Block

-LRB-

au

moyen

du

mot-cl

e

friend

de

C++

-RRB-

et

l'op

eration

op

-LRB-

-RRB-

de

cette

classe

est

devenue

priv?ee

class

Block

f

friend

Logging

view

friend

Sharing

friend

Distribution

friend

protected

Block

successor

public

void

attach

-LRB-

Block

block

-RRB-

fsuccessor

block

g

private

virtual

void

op

-LRB-

-RRB-

g

Figure

V.

Variante

de

r?ealisation

du

type

block

Cette

variante

v?erifie

les

contraintes

a

d?efinies

au

mais

ne

v?erifie

pas

la

derni?ere

En

effet

elle

n?ecessite

la

modification

de

la

d?efinition

de

la

classe

Block

lors

de

l'adjonction

de

nouvelles

classes

r?ealisant

des

blocs

ou

r?ealisant

des

vues

de

journalisation

afin

de

les

d?eclarer

en

tant

qu

amies

du

type

Le

probl?eme

vient

du

fait

que

le

statut

d'

ami

ne

s

h?erite

pas

en

C++

Toutefois

cette

variante

prot?ege

les

invocations

des

op?erations

du

type

en

les

r?eservant

aux

classes

d?eclar?ees

amies

Elle

permet

une

meilleure

protection

que

la

solution

pr?ec?edente

mais

ne

permet

toujours

pas

de

limiter

les

invocations

des

vues

de

journalisation

a

un

sous-ensemble

de

l'interface

des

blocs

-LRB-

le

mot

cl?e

friend

de

C++

ne

permet

pas

un

tel

raffinement

-RRB-

Dans

la

classe

abstraite

il

est

possible

de

supprimer

la

d?eclaration

des

classes

amies

pour

les

classes

d?erivant

de

la

classe

abstraite

Pour

cela

il

faut

effectuer

une

op?eration

de

coercition

-LRB-

cast

-RRB-

sur

les

types

des

successeurs

au

moment

d'une

invocation

dans

le

code

d'une

classe

r?ealisant

le

type

Block

Ainsi

par

exemple

dans

la

classe

Sharing

l'appel

successor

op

-LRB-

-RRB-

sera

remplac?e

par

-LRB-

-LRB-

Sharing

-RRB-

successor

-RRB-

op

-LRB-

-RRB-

La

figure

V.

donne

la

solution

compl?ete

correspondant

a

l'exemple

de

la

figure

V.

Cette

solution

v?erifie

presque

les

cinq

contraintes

d?efinies

bien

qu'elle

soit

peu

orthodoxe

car

la

coercition

de

type

effectu?ee

trompe

le

compilateur

Les

contraintes

ne

sont

pas

tout

a

fait

respect?ees

dans

la

mesure

o?u

on

ne

sait

toujours

pas

limiter

les

acc?es

de

la

classe

des

vues

de

journalisation

a

un

ensemble

restreint

d'op

erations

du

type

-LCB-

-LCB-

Simulation

de

types

en

C++

class

Block

f

friend

Logging

view

protected

Block

successor

public

void

attach

-LRB-

Block

block

-RRB-

fsuccessor

block

g

private

virtual

void

op

-LRB-

-RRB-

g

class

Sharing

public

Block

f

private

virtual

void

op

-LRB-

-RRB-

fif

-LRB-

successor

-RRB-

-LRB-

-LRB-

Sharing

-RRB-

successor

-RRB-

op

-LRB-

-RRB-

g

g

class

Distribution

public

Block

f

private

virtual

void

op

-LRB-

-RRB-

fif

-LRB-

successor

-RRB-

-LRB-

-LRB-

Distribution

-RRB-

successor

-RRB-

op

-LRB-

-RRB-

g

g

class

public

Distribution

f

private

virtual

void

op

-LRB-

-RRB-

fif

-LRB-

successor

-RRB-

-LRB-

-LRB-

-RRB-

successor

-RRB-

op

-LRB-

-RRB-

g

g

class

Logging

view

f

Block

successor

public

Logging

view

-LRB-

Block

successor

-RRB-

fthis

successor

successor

g

void

vop

-LRB-

-RRB-

fif

-LRB-

successor

-RRB-

successor

op

-LRB-

-RRB-

g

g

Figure

V.

R?ealisation

finale

du

type

Block

Conclusion

La

simulation

de

type

abstrait

en

C++

v?erifiant

les

contraintes

fix?ees

n

a

pas

et?e

une

t

ache

simple

et

la

solution

obtenue

n'est

pas

compl?etement

satisfaisante

La

cause

de

cette

difficult?e

provient

essentiellement

de

l'absence

de

droits

d'acc

es

particuliers

entre

classes

soeurs

en

C++

Bien

que

le

mot-cl

e

protected

permette

d'

etendre

l'acc

es

aux

membres

d'une

classe

a

l'ensemble

des

classes

qui

en

d?erivent

aucun

m?ecanisme

ne

permet

de

donner

cet

acc?es

aux

classes

soeurs

sans

donner

acc?es

a

tous

De

plus

en

supposant

que

les

vues

de

journalisation

soient

r?ealis?ees

par

diff?erentes

classes

se

conformant

a

un

type

commun

comme

c'est

le

cas

pour

les

blocs

il

reste

a

trouver

une

solution

pour

qu'un

type

de

vue

de

journalisation

puisse

etre

ami

d'un

-LCB-

-LCB-

Chapitre

V

Description

du

prototype

type

de

blocs

Placer

la

relation

ami

au

niveau

des

types

plut

ot

qu'au

niveau

des

classes

est

naturelle

puisque

le

typage

permet

la

protection

des

objets

et

que

la

relation

ami

permet

de

violer

cette

protection

-LCB-

-LCB-

Chapitre

VI

Bilan

Ce

chapitre

dresse

un

bilan

de

KitLog

Apr?es

avoir

etudi?e

la

conception

d'une

application

au-dessus

de

KitLog

-LRB-

KFS

-RRB-

il

d?ecrit

les

difficult?es

rencontr?ees

lors

de

cette

conception

Une

etude

du

surco

ut

li?e

a

la

g?en?ericit?e

est

ensuite

faite

Quelques

am?eliorations

possibles

sont

alors

expliqu?ees

KFS

Cette

section

d?ecrit

l'architecture

de

-LRB-

KitLog

File

System

-RRB-

qui

est

un

syst?eme

de

fichiers

en

cours

d'impl

ementation

enti?erement

journalis?e

au-dessus

de

KitLog

Ce

syst?eme

de

fichiers

est

conforme

au

protocole

NFS

d?efini

par

-LSB-

Sun

Microsystems

Inc.

-RSB-

KFS

a

et?e

con?cu

dans

le

but

de

valider

KitLog

et

de

l'utiliser

Cette

description

est

suivie

d'un

bilan

de

l'ad

equation

de

KitLog

a

un

tel

type

de

journalisation

Description

de

KFS

A

l'origine

la

conception

de

KFS

devait

etre

proche

de

celle

de

Sprite

LFS

C'est

a-dire

que

nous

nous

proposions

d'utiliser

les

structures

et

les

algorithmes

de

Sprite

LFS

dans

la

conception

de

KFS

De

mani?ere

a

utiliser

au

mieux

les

services

propos?es

et

a

ne

pas

r?e

impl?ementer

des

fonctions

d?ej?a

r?ealis?ees

dans

KitLog

la

conception

de

KFS

s

est

peu

a

peu

eloign?ee

de

celle

de

Sprite

LFS

Organisation

du

stockage

de

KFS

Comme

dans

les

syst?emes

de

fichiers

traditionnels

un

fichier

est

d?ecoup?e

en

blocs

dont

les

diff?erentes

localisations

sont

r?ef?erenc?ees

par

l'inode

du

fichier

Un

inode

contient

egalement

les

attributs

du

fichier

taille

du

fichier

date

de

derni?ere

modification

date

du

dernier

acc?es

identit?e

du

propri?etaire

droits

d'acc

es

etc.

r?ealisation

de

KFS

a

et?e

l'objet

du

stage

de

DEA

de

syst?emes

informatiques

de

Carole

Fouqu?e

effectu?e

au

sein

du

projet

SOR

a

l'INRIA

-LCB-

-LCB-

Chapitre

VI

Bilan

Un

journal

logique

est

r?eserv?e

a

chaque

fichier

Il

comprend

les

enregistrements

correspondant

aux

blocs

du

fichier

et

un

enregistrement

correspondant

a

l'inode

du

fichier

Contrairement

aux

syst?emes

de

fichiers

traditionnels

KFS

d?ecoupe

un

fichier

en

blocs

de

taille

variable

mais

limit?ee

par

une

taille

maximum

Lors

de

la

cr?eation

d'un

fichier

l'inode

correspondant

a

un

fichier

vide

est

ecrit

comme

premier

enregistrement

du

journal

logique

Puis

les

eventuelles

donn?ees

du

fichier

sont

constitu?ees

en

un

seul

bloc

Si

la

taille

des

donn?ees

est

sup?erieure

a

la

limite

de

taille

des

blocs

le

fichier

est

d?ecoup?e

en

plusieurs

blocs

chacun

constituant

un

enregistrement

Une

fois

ces

enregistrements

ecrits

le

nouvel

inode

est

ecrit

a

la

fin

du

journal

et

l'enregistrement

pr?ec?edent

contenant

l'ancienne

version

de

l'inode

est

d?eclar?e

obsol?ete

Lorsqu'un

bloc

est

modifi?e

un

enregistrement

correspondant

au

nouveau

bloc

et

le

nouvel

inode

du

fichier

sont

ecrits

a

la

fin

du

journal

logique

Les

anciens

enregistrements

correspondant

au

bloc

modifi?e

et

a

l'ancien

inode

sont

d?eclar?es

obsol?etes

La

figure

VI

d?ecrit

cette

organisation

I

I

I

I

I

Figure

VI

Journal

logique

d'un

fichier

dans

KFS

A

la

cr?eation

du

fichier

l'inode

I

est

ecrit

en

d?ebut

de

journal

Puis

les

Blocs

a

sont

ecrits

L'inode

I

est

mis

a

jour

-LRB-

I

-RRB-

Puis

le

bloc

est

modifi?e

Il

est

remplac?e

par

le

bloc

et

l'inode

I

est

r?e

ecrit

a

la

fin

-LRB-

I

-RRB-

Disposer

de

blocs

de

tailles

variables

permet

d'

economiser

la

place

sur

le

support

de

stockage

pour

les

petits

fichiers

ou

bien

pour

les

fichiers

souvent

modifi?es

a

la

fin

La

de

la

taille

des

blocs

permet

de

ne

pas

r?e

ecrire

le

fichier

complet

a

chaque

modification

Lecture

d'un

fichier

Les

inodes

ne

r?ef?erencent

pas

directement

les

enregistrements

mais

stockent

pour

chaque

bloc

son

identificateur

d'enregistrement

KFS

est

ainsi

ind?ependant

du

compactage

de

KitLog

et

lui

laisse

la

charge

de

la

recherche

d'enregistrements

Les

r?epertoires

dans

les

syst?emes

de

fichiers

traditionnels

stockent

la

correspondance

entre

le

nom

d'un

fichier

et

le

num?ero

d'inode

de

ce

fichier

Dans

KFS

un

limite

est

l?eg?erement

inf?erieure

a

octets

dans

la

r?ealisation

courante

Elle

correspond

a

la

valeur

suivante

-LRB-

taille

d'un

secteur

de

KitLog

taille

du

surco

ut

fixe

par

secteur

-RRB-

taille

du

surco

ut

d'un

enregistrement

En

cons?equence

l'enregistrement

correspondant

a

un

bloc

de

taille

maximale

est

stock?e

exactement

sur

secteurs

et

permet

une

certaine

economie

de

place

en

evitant

des

secteurs

incomplets

-LCB-

-LCB-

KFS

r?epertoire

stocke

la

correspondance

entre

le

nom

du

fichier

et

l'identificateur

de

journal

logique

du

fichier

-LRB-

Lid

-RRB-

Ainsi

la

recherche

d'un

fichier

consiste

a

partir

du

Lid

correspondant

a

son

journal

logique

a

demander

la

lecture

de

son

dernier

enregistrement

contenant

l'inode

du

Puis

a

partir

de

l'inode

il

suffit

de

demander

la

lecture

des

enregistrements

correspondant

aux

blocs

du

fichier

Recherche

de

la

racine

Dans

Unix

le

syst?eme

de

fichiers

peut

etre

r?eparti

sur

diff?erentes

partitions

de

diff?erents

disques

pouvant

etre

situ?es

sur

diff?erents

sites

Les

num?eros

d'inodes

au

travers

d'une

partition

sont

uniques

Chaque

partition

contient

une

racine

a

partir

de

laquelle

on

peut

atteindre

la

hi?erarchie

de

fichiers

Cette

racine

correspond

a

un

fichier

d?ecrit

par

deux

inodes

les

inodes

et

ce

qui

permet

de

les

trouver

ind?ependamment

de

toute

information

La

recherche

d'un

fichier

est

effectu?ee

ainsi

l'inode

est

recherch?e

dans

la

zone

des

inodes

qui

est

situ?ee

a

un

endroit

fixe

du

support

de

stockage

A

partir

de

cet

inode

les

blocs

constituant

le

r?epertoire

de

la

racine

sont

lus

Le

r?epertoire

permet

de

trouver

l'inode

du

r?epertoire

suivant

La

r?esolution

du

chemin

menant

au

fichier

continue

par

la

recherche

de

l'inode

correspondant

La

recherche

continue

ainsi

de

proche

en

proche

Pour

simplifier

le

discours

une

partie

ind?ependante

du

syst?eme

de

fichiers

de

KFS

-LRB-

equivalente

a

un

syst?eme

de

fichiers

d'une

partition

dans

Unix

-RRB-

sera

appel?ee

une

partition

KFS

utilise

une

vue

de

journalisation

diff?erente

pour

chaque

partition

Le

graphe

dont

la

vue

de

journalisation

est

la

t

ete

d?etermine

le

lieu

de

stockage

du

journal

En

cons?equence

les

caract?eristiques

de

la

journalisation

d?efinies

par

ce

graphe

sont

appliqu?ees

a

la

totalit?e

de

la

partition

Par

exemple

si

le

graphe

comporte

un

bloc

de

r?eplication

la

partition

compl?ete

sera

r?epliqu?ee

La

racine

correspond

a

un

journal

logique

particulier

KFS

lui

attribue

l'identificateur

Ainsi

pour

retrouver

la

racine

d'une

partition

KFS

fait

appel

au

service

de

nommage

de

KitLog

qui

a

partir

de

l'identificateur

de

journal

choisi

par

l'application

-LRB-

-RRB-

du

nom

symbolique

de

la

vue

-LRB-

correspondant

a

la

partition

-RRB-

et

de

l'identificateur

de

l'application

-LRB-

KFS

-RRB-

d?elivre

le

Lid

du

journal

logique

correspondant

a

la

racine

de

cette

partition

Une

fois

la

racine

trouv?ee

tout

fichier

de

la

hi?erarchie

peut

etre

trouv?e

de

proche

en

proche

comme

dans

les

syst?emes

de

fichiers

traditionnels

Atomicit?e

des

ecritures

L'

ecriture

des

enregistrements

d'un

fichier

peut

se

d?erouler

en

plusieurs

phases

d'

ecriture

Par

exemple

si

un

tampon

devient

plein

alors

qu'il

contient

des

blocs

du

fichier

sans

contenir

le

nouvel

inode

correspondant

aux

blocs

il

peut

etre

ecrit

sur

le

support

de

stockage

sans

son

inode

Une

panne

survenant

avant

l'

ecriture

effective

de

l'inode

produit

un

journal

logique

dont

le

dernier

enregistrement

n'est

pas

un

inode

Dans

un

tel

cas

il

faut

r?etablir

l'ancienne

version

du

fichier

afin

de

garantir

l'atomicit

e

des

ecritures

ce

qui

revient

a

trouver

la

version

de

l'inode

ant?erieure

a

la

panne

et

a

invalider

les

enregistrements

suivant

celui

de

l'inode

enregistrements

contenant

les

inodes

ne

sont

pas

limit?es

en

taille

ce

qui

assure

que

le

dernier

enregistrement

d'un

journal

logique

contient

bien

l'inode

complet

du

fichier

-LCB-

-LCB-

Chapitre

VI

Bilan

KFS

alloue

lui-m

eme

ses

identificateurs

uniques

d'enregistrements

-LRB-

Rid

-RRB-

Les

enregistrements

correspondant

a

des

inodes

sont

diff?erenci?es

des

autres

par

le

fait

que

leurs

Rid

sont

impairs

alors

que

les

blocs

de

fichiers

correspondent

a

des

enregistrements

aux

Rid

pairs

Ainsi

par

une

lecture

s?equentielle

arri?ere

du

journal

logique

le

premier

enregistrement

impair

donne

la

derni?ere

version

de

l'inode

du

fichier

Une

fois

qu'un

fichier

est

cr?e?e

il

existe

au

moins

un

inode

puisque

la

cr?eation

de

celui-ci

est

r?ealis?ee

par

une

ecriture

de

l'inode

correspondant

au

fichier

vide

Quand

forcer

les

ecritures

A

priori

a

aucun

moment

le

syst?eme

de

fichiers

n'est

oblig?e

de

forcer

les

ecritures

sur

le

support

de

stockage

Dans

ce

cas

les

modifications

perdues

a

la

suite

d'une

panne

peuvent

correspondre

a

une

dur?ee

quelconque

Seule

l'op

eration

flush

-LRB-

-RRB-

garantit

a

un

client

l'

ecriture

effective

des

enregistrements

sur

les

supports

de

stockage

Cette

op?eration

met

en

jeu

toutes

les

donn?ees

ayant

transit?e

a

travers

une

vue

Par

cons?equent

lorsqu'elle

est

d?eclench?ee

c'est

l'ensemble

des

modifications

apport?ees

a

une

partition

qui

sont

forc?ees

sur

le

support

de

stockage

KFS

force

les

ecritures

en

trois

occasions

au

moment

de

la

cr?eation

d'un

fichier

au

moment

de

la

fermeture

d'un

fichier

et

lorsque

les

modifications

apport?ees

a

une

partition

n'ont

pas

et?e

sauvegard?ees

depuis

un

certain

laps

de

temps

Ceci

permet

de

r?eduire

la

quantit?e

de

travail

perdu

en

cas

de

panne

de

site

ou

du

processus

serveur

Autres

caract?eristiques

Certaines

caract?eristiques

additionnelles

ont

et?e

envisag?ees

p

La

compression

des

journaux

logiques

consisterait

a

lire

la

totalit?e

des

enregistrements

d'un

fichier

et

a

le

r?e

ecrire

permettant

ainsi

de

r?eduire

la

fragmentation

des

fichiers

sur

le

support

de

stockage

p

Un

syst?eme

de

versions

de

fichiers

pourrait

etre

r?ealis?e

tr?es

simplement

Il

suffirait

pour

cela

de

ne

pas

d?eclarer

obsol?etes

les

enregistrements

des

inodes

et

des

anciennes

versions

de

blocs

lors

d'une

modification

Lors

d'une

lecture

arri?ere

du

journal

chaque

inode

trouv?e

correspondant

a

une

modification

du

permettrait

de

trouver

la

version

ant?erieure

du

fichier

Un

m?ecanisme

additionnel

proche

de

la

compression

devrait

etre

mis

en

oeuvre

afin

d'effacer

les

versions

les

plus

vieilles

du

fichier

acc?es

a

un

fichier

modifie

un

inode

Par

exemple

dans

le

cas

d'une

modification

des

droits

d'acc

es

a

un

fichier

la

date

de

dernier

changement

des

attributs

du

fichier

doit

etre

mise

a

jour

dans

l'inode

-LCB-

-LCB-

KFS

Bilan

de

la

r?ealisation

de

KFS

Le

bilan

de

la

r?ealisation

de

KFS

est

globalement

positif

en

raison

de

l'utilisation

judicieuse

des

journaux

logiques

Trois

points

sont

distingu?es

les

probl?emes

rencontr?es

lors

de

la

conception

de

KFS

les

performances

esp?er?ees

et

la

g?en?ericit?e

engendr?ee

par

KitLog

dans

KFS

Architecture

de

KFS

L'architecture

d'un

syst?eme

de

fichiers

similaire

a

celui

de

Sprite

LFS

repose

sur

un

choix

d?eterminant

Trois

solutions

principales

s

offraient

a

nous

dans

l'usage

des

journaux

logiques

disposer

d'un

journal

logique

pour

l'ensemble

des

donn?ees

du

syst?eme

de

fichiers

s?eparer

les

inodes

des

blocs

de

donn?ees

dans

des

journaux

logiques

diff?erents

ou

bien

utiliser

un

journal

logique

pour

chaque

fichier

comprenant

les

donn?ees

du

fichier

et

son

inode

-LRB-

ce

qui

constitue

la

solution

retenue

-RRB-

Les

deux

premi?eres

solutions

n?ecessitaient

l'usage

de

m?eta

donn?ees

complexes

similaires

a

celles

de

Sprite

pour

diff?erencier

les

inodes

des

blocs

de

donn?ees

et

pour

en

effectuer

un

rep?erage

et

une

recherche

rapide

Ces

solutions

auraient

demand?e

d'effectuer

un

travail

redondant

puisque

les

m?ecanismes

existaient

dans

KitLog

De

plus

la

m?ethode

de

rep?erage

des

inodes

de

Sprite

LFS

n?ecessite

de

pouvoir

ecrire

des

points

de

sauvegarde

a

un

endroit

fixe

du

support

de

stockage

Ceci

etait

impossible

dans

KitLog

Une

fois

la

m?ethode

d'utilisation

des

journaux

logiques

d?etermin?ee

il

nous

a

fallu

choisir

entre

des

enregistrements

de

taille

fixe

ou

variable

Le

compromis

choisi

permet

de

b?en?eficier

des

avantages

des

deux

solutions

Des

blocs

de

taille

variable

permettent

de

simplifier

la

gestion

des

r?epertoires

et

d'

economiser

de

la

place

disque

dans

le

cas

des

fichiers

de

petite

taille

La

limitation

de

la

taille

des

blocs

permet

d'

eviter

la

r?e

ecriture

de

la

totalit?e

des

fichiers

en

cas

de

modifications

l?eg?eres

Seuls

les

blocs

concern?es

par

la

modification

et

leurs

successeurs

dans

le

fichier

doivent

etre

r?e

ecrits

Une

fois

ces

points

fix?es

le

probl?eme

restant

etait

de

trouver

la

racine

d'une

partition

Il

fallait

pour

cela

pouvoir

distinguer

un

journal

logique

particulier

Le

service

de

nommage

de

KitLog

a

et?e

con?cu

dans

le

but

de

combler

cette

lacune

Initialement

nous

pensions

que

le

probl?eme

du

nommage

de

journaux

logiques

n

etait

pas

a

consid?erer

dans

le

cadre

de

nos

objectifs

Devant

l'importance

du

nommage

il

a

et?e

n?ecessaire

de

r?ealiser

un

service

minimum

de

nommage

L'atomicit

e

de

l'

ecriture

d'un

fichier

dans

KFS

a

et?e

r?esolue

par

la

distinction

entre

les

Rids

des

enregistrements

contenant

des

inodes

de

ceux

contenant

des

blocs

de

fichier

Le

probl?eme

vient

d'une

lacune

de

l'op

eration

flush

-LRB-

-RRB-

qui

est

utilis?ee

a

la

fois

pour

des

raisons

pratiques

-LRB-

tampons

pleins

-RRB-

et

des

raisons

logiques

-LRB-

assurance

que

l'

ecriture

a

effectivement

et?e

r?ealis?ee

-RRB-

Nous

proposerons

une

solution

a

ce

probl?eme

au

La

taille

des

Lid

pose

un

probl?eme

dans

KFS

KFS

se

conforme

aux

sp?ecifications

du

protocole

NFS

Dans

celui-ci

on

sp?ecifie

qu'une

demande

d'information

sur

un

fichier

-LRB-

appel

stat

-RRB-

retourne

l'identificateur

unique

du

fichier

-LRB-

num?ero

d'inode

sous

Unix

-RRB-

sous

la

forme

d'un

entier

Dans

KFS

ces

identificateurs

uniques

sont

des

Lid

qui

sont

dans

la

r?ealisation

actuelle

des

identificateurs

de

taille

trois

fois

sup?erieure

a

celle

-LCB-

-LCB-

Chapitre

VI

Bilan

d'un

entier

La

solution

choisie

lors

d'une

telle

demande

est

de

retourner

une

partie

du

Lid

qui

dans

la

majeure

partie

des

cas

permet

de

d?efinir

un

journal

logique

d'une

mani?ere

unique

Toutefois

cette

solution

n

etant

pas

suffisante

quelques

op?erations

ne

sont

pas

utilisables

dans

KFS

Par

exemple

la

commande

clri

-LRB-

clear

inode

-RRB-

d'Unix

ne

peut

etre

utilis?ee

Plusieurs

solutions

s

offraient

a

nous

pour

pallier

a

ce

probl?eme

nous

les

avons

rejet?ees

dans

le

mesure

o?u

cet

usage

des

identificateurs

uniques

etait

exceptionnel

et

reserv?e

a

des

cas

de

disfonctionnement

du

syst?eme

de

gestion

de

fichiers

L'architecture

de

KFS

est

tr?es

simple

Cette

simplicit?e

provient

d'une

part

de

l'ad

equation

de

l'interface

de

KitLog

et

d'autre

part

du

fait

que

les

services

rendus

sont

assez

complets

Par

exemple

la

gestion

des

espaces

libres

sur

le

support

de

stockage

se

limite

au

signalement

des

enregistrements

obsol?etes

par

KFS

la

recherche

des

blocs

d'un

fichier

se

limite

a

la

recherche

de

l'identificateur

de

son

journal

logique

Les

m?ecanismes

de

KitLog

sont

suffisamment

complets

pour

satisfaire

les

besoins

majeurs

de

KFS

Performances

de

KFS

Les

performances

de

KFS

d?ependent

essentiellement

de

celles

de

KitLog

Bien

qu'aucune

mesure

n'ait

et?e

encore

faite

-LRB-

KFS

est

en

cours

d'impl

ementation

-RRB-

on

peut

esp?erer

de

bonnes

performances

d'

ecritures

comparables

voire

sup?erieures

a

celles

de

Sprite

LFS

En

effet

nous

stockons

beaucoup

moins

de

m?eta

donn?ees

que

Sprite

et

nous

ecrivons

lin?eairement

sur

le

support

de

stockage

alors

que

les

secteurs

de

Sprite

ne

constituent

pas

des

secteurs

contigus

sur

le

support

physique

La

rapidit?e

des

lectures

dans

KitLog

d?epend

de

la

dur?ee

des

intervalles

de

temps

d?elimitant

la

m?emorisation

de

la

localisation

du

dernier

enregistrement

d'un

journal

logique

Dans

la

r?ealisation

de

KitLog

ce

param?etre

n?ecessite

une

recompilation

apr?es

modification

Un

service

suppl?ementaire

doit

donc

etre

ajout?e

pour

qu'une

application

puisse

modifier

ce

param?etre

dynamiquement

Les

performances

de

lectures

laissent

moins

a

esp?erer

etant

donn?e

que

la

m?ethode

de

journalisation

du

prototype

de

KitLog

a

et?e

con?cue

pour

des

applications

dont

les

lectures

sont

rares

en

comparaison

des

ecritures

-LRB-

ce

qui

n'est

pas

le

cas

d'un

syst?eme

de

fichiers

-RRB-

Mais

si

l'on

reprend

les

arguments

de

Sprite

LFS

avec

de

tr?es

gros

caches

m?emoire

-LRB-

ce

qui

correspond

a

nos

hypoth?eses

de

fonctionnement

donn?ees

au

du

chapitre

V

-RRB-

nous

devrions

obtenir

des

performances

correctes

G?en?ericit?e

dans

KFS

KFS

allie

par

l'utilisation

de

KitLog

les

avantages

d'une

syst?eme

de

fichiers

enti?erement

journalis?e

-LSB-

Rosenblum

et

Ousterhout

-RSB-

a

ceux

d'un

syst?eme

de

fichiers

en

partie

g?en?erique

-LSB-

Heidemann

et

Popek

-RSB-

En

effet

comme

dans

Ficus

les

caract?eristiques

de

chaque

partition

du

syst?eme

de

fichiers

-LRB-

r?eplication

par

exemple

-RRB-

peuvent

etre

adapt?ees

au

type

de

donn?ees

stock?ees

sur

la

partition

Par

exemple

les

partitions

stockant

des

donn?ees

critiques

pourrons

etre

g?er?ees

au

moyen

d'un

graphe

de

journalisation

r?ealisant

un

grand

nombre

de

copies

de

la

partition

Toutefois

si

l'on

compare

-LCB-

-LCB-

KFS

KFS

a

Ficus

le

choix

des

caract?eristiques

composables

est

limit?e

a

celles

d?efinies

par

les

blocs

de

KitLog

Si

l'on

d?esire

une

plus

grande

g?en?ericit?e

de

KFS

une

nouvelle

conception

de

KFS

peut

etre

envisag?ee

o?u

une

m?ethode

de

composition

de

blocs

similaire

a

celle

de

KitLog

permettrait

de

tenir

compte

des

caract?eristiques

d?ependantes

de

la

s?emantique

des

donn?ees

attach?ees

aux

syst?emes

de

fichiers

gestion

des

r?epertoires

cryptage

de

certains

champs

des

inodes

d?ecoupage

et

diss?emination

des

donn?ees

des

fichiers

gestion

de

versions

etc.

Ceci

constituerait

une

couche

au-dessus

de

KitLog

comprenant

deux

parties

La

premi?ere

serait

un

mod?ele

a

l'image

de

celui

de

KitLog

isolant

les

diff?erentes

caract?eristiques

li?ees

a

la

s?emantique

des

informations

trait?ees

et

d?eterminant

leurs

m?ethode

de

composition

La

seconde

partie

d?eterminerait

la

m?ethode

de

gestion

des

donn?ees

proprement

dites

de

la

m

eme

mani?ere

que

KitLog

distingue

la

m?ethode

de

gestion

des

journaux

de

son

mod?ele

Dans

le

cadre

de

KFS

cette

seconde

partie

correspondrait

a

la

gestion

de

fichier

que

nous

avons

d?ecrit

Si

l'on

g?en?eralise

cette

approche

a

l'ensemble

des

clients

de

KitLog

au

plus

bas

niveau

on

trouve

les

caract?eristiques

de

KitLog

qui

s

appliquent

d'une

mani?ere

g?en?erale

a

toute

sorte

de

donn?ees

Le

service

r?ealis?e

au-dessus

de

KitLog

est

constitu?e

d'un

mod?ele

d'objets

composables

encapsulant

les

caract?eristiques

propres

a

la

s?emantique

des

donn?ees

qu'il

traite

raffinant

le

mod?ele

KitLog

et

d'une

ou

plusieurs

m?ethodes

de

gestion

de

ces

donn?ees

La

figure

VI

sch?ematise

cette

structuration

hypoth?etique

P

R

D

M?thode

de

M?thode

de

M?thode

de

journalisation

A

journalisation

B

journalisation

C

Sd

St

V

Sp

Mod?le

Kitlog

Mod?le

d'un

client

M?thode

de

gestion

M?thode

de

gestiondes

donn?es

Bdes

donn?es

A

Figure

VI

Sch?ematisation

de

la

structuration

de

services

Un

service

est

repr?esent?e

par

un

mod?ele

qui

d?efinit

un

ensemble

de

caract?eristiques

encapsul?ees

dans

des

blocs

composables

ainsi

que

diff?erentes

m?ethodes

de

gestion

des

donn?ees

Certains

objets

servent

d'interface

haute

-LRB-

vues

de

journalisation

dans

KitLog

-RRB-

ou

basse

-LRB-

gestion

des

supports

dans

KitLog

-RRB-

et

encapsulent

la

communications

avec

les

autres

services

-LCB-

-LCB-

Chapitre

VI

Bilan

Performances

et

g?en?ericit?e

La

mesure

des

performances

n?ecessite

de

disposer

d'applications

r?ealis?ees

au-dessus

de

KitLog

g?en?erant

et

lisant

des

enregistrements

dans

un

mode

normal

d'utilisation

Dans

l'

etat

actuel

on

peut

effectuer

des

mesures

sur

certains

points

particuliers

du

service

vitesse

d'

ecriture

des

caches

performance

des

communications

dur?ee

de

travers?ee

de

chaque

classe

d'un

enregistrement

etc.

Toutefois

les

r?esultats

obtenus

n'ont

pas

une

grande

valeur

si

ils

ne

tiennent

pas

compte

d'un

mode

de

fonctionnement

normal

Par

exemple

la

vitesse

d'

ecriture

depuis

les

caches

vers

les

disques

dans

KitLog

est

de

l'ordre

de

octets

par

seconde

une

fois

les

t

etes

de

lectures

positionn?ees

ce

qui

est

proche

de

la

bande

passante

du

disque

-LRB-

ecriture

en

local

sur

un

Sun

reli?e

a

un

disque

d'interface

SCSI

de

octets

-RRB-

Cette

mesure

correspond

a

l'

ecriture

par

paquets

de

octets

-LRB-

secteurs

-RRB-

ce

qui

am?ene

l'

ecriture

d'un

secteur

de

KitLog

a

ms.

Le

positionnement

pr?ealable

des

t

etes

de

lecture

revient

a

supposer

qu'il

n

y

a

pas

de

lecture

ou

de

compactage

durant

les

ecritures

et

d?epend

enti?erement

du

mode

d'utilisation

de

l'application

cliente

La

vitesse

d'

ecriture

serait

largement

diminu?ee

sans

cette

hypoth?ese

Ce

qui

devrait

etre

mesur?e

par

exemple

c'est

la

dur?ee

moyenne

de

transit

d'un

enregistrement

entre

son

emission

par

un

client

et

le

moment

o?u

il

est

ecrit

Cette

dur?ee

d?epend

du

graphe

de

l'application

cliente

-LRB-

distribution

r?eplication

du

graphe

-RRB-

mais

il

d?epend

surtout

du

flots

de

donn?ees

re?cues

et

ne

peut

etre

mesur?e

qu

a

travers

une

application

r?eelle

KFS

etant

encore

en

cours

de

d?eveloppement

nous

n'avons

pu

effectuer

de

mesures

significatives

Toutefois

on

peut

faire

une

evaluation

du

surco

ut

li?e

au

mod?ele

provenant

de

la

g?en?ericit?e

Le

surco

ut

li?e

a

la

g?en?ericit?e

dans

KitLog

correspond

a

la

travers?ee

des

objets

qui

composent

le

graphe

des

applications

En

effet

le

surco

ut

li?e

a

la

constitution

du

graphe

ou

a

sa

reconfiguration

n'interviennent

pas

en

fonctionnement

normal

et

ces

actions

sont

cens?ees

se

produire

en

de

rares

occasions

La

g?en?ericit?e

dans

KitLog

entra

ne

un

surco

ut

qui

semble

n?egligeable

quand

on

la

compare

a

des

syst?emes

qui

ne

permettent

pas

de

choisir

les

caract?eristiques

de

la

journalisation

Nous

allons

comparer

la

journalisation

d'un

enregistrement

dans

Camelot

a

celle

de

KitLog

Comme

base

de

comparaison

nous

supposerons

que

le

graphe

de

la

figure

III

page

r?ealise

une

journalisation

equivalente

a

celle

de

Camelot

Dans

Camelot

est

issu

d'un

gestionnaire

de

transactions

L'enregistrement

est

copi?e

sur

le

r?eseau

pour

etre

envoy?e

par

message

au

serveur

de

journalisation

L'enregistrement

est

alors

copi?e

dans

un

cache

multiplexant

les

enregistrements

Il

est

egalement

copi?e

en

un

certain

nombre

d'exemplaires

sur

le

r?eseau

afin

d'

etre

r?epliqu?e

dans

les

caches

des

diff?erents

serveurs

de

journalisation

-LRB-

Camelot

n'utilise

pas

la

diffusion

physique

bien

qu'elle

limiterait

le

nombre

de

copies

-RRB-

L'enregistrement

sera

finalement

copi?e

sur

le

support

de

stockage

au

moment

opportun

En

cons?equence

ne

consid?erons

qu'un

seul

enregistrement

En

effet

le

cas

de

la

journalisation

de

paquets

d'enregistrements

dans

Camelot

comme

dans

KitLog

peut

etre

ramen?e

a

celui

d'un

seul

enregistrement

-LCB-

-LCB-

Performances

et

g?en?ericit?e

un

enregistrement

est

copi?e

trois

fois

dans

le

cas

du

serveur

recevant

la

demande

de

journalisation

et

quatre

fois

pour

les

autres

serveurs

Dans

KitLog

deux

etudes

sont

possibles

selon

que

l'on

consid?ere

le

mod?ele

ou

le

prototype

Nous

allons

d'abord

etudier

le

cas

du

mod?ele

o?u

les

objets

sont

instanci?es

dans

l'espace

d'adressage

du

client

avant

d'

etudier

le

cas

du

prototype

L'enregistrement

arrive

dans

la

vue

de

journalisation

sous

la

forme

d'un

pointeur

vers

les

donn?ees

correspondant

a

son

corps

L'op

eration

est

ensuite

r?epliqu?ee

par

le

bloc

de

distribution

sur

trois

blocs

de

distribution

-LRB-

l'enregistrement

n'est

pas

copi?e

seul

le

pointeur

qui

le

d?esigne

l'est

-RRB-

Il

est

ensuite

copi?e

sur

le

r?eseau

pour

etre

envoy?e

sous

la

forme

d'un

message

aux

diff?erents

serveurs

de

journalisation

-LRB-

une

copie

est

faite

par

serveur

-RRB-

Un

serveur

qui

re?coit

un

pointeur

sur

l'enregistrement

dans

un

bloc

de

partage

transmet

l'op

eration

a

un

bloc

tampon

qui

copie

l'enregistrement

dans

son

cache

Le

cache

sera

par

la

suite

copi?e

sur

le

support

de

stockage

Trois

copies

ont

eut

lieu

pour

chaque

serveur

Le

cas

du

prototype

est

semblable

a

Camelot

l'enregistrement

est

copi?e

sur

le

r?eseau

pour

le

changement

d'espace

d'adressage

il

est

ensuite

copi?e

dans

le

cache

du

serveur

et

pour

chaque

serveur

a

qui

il

est

envoy?e

en

message

Le

cache

doit

ensuite

etre

copi?e

sur

le

support

de

stockage

En

cons?equence

le

nombre

de

copies

de

l'enregistrement

est

globalement

le

m

eme

dans

Camelot

et

dans

le

prototype

de

KitLog

Il

est

moindre

dans

le

cas

du

mod?ele

Le

surco

ut

eventuel

de

KitLog

est

le

nombre

d'invocations

d'objets

au

travers

desquels

transite

l'op

eration

Il

y

a

eut

six

appels

de

proc?edures

correspondant

aux

invocations

des

objets

Nous

consid?ererons

ce

surco

ut

comme

n?egligeable

a

partir

du

moment

o?u

le

nombre

d'objets

travers?es

n'est

pas

trop

important

la

travers?ee

d'espaces

d'adressage

ou

le

passage

sur

le

r?eseau

etant

beaucoup

plus

co

uteux

Si

l'on

observe

les

diff?erents

exemples

qui

ont

et?e

donn?es

jusqu'ici

et

qui

correspondent

a

des

graphes

plausibles

on

peut

noter

qu'aucun

n'implique

la

travers?ee

de

plus

de

six

objets

Dans

le

cas

o?u

les

communications

s

effectuent

entre

des

architectures

h?et?erog?enes

l'enregistrement

ou

certaines

parties

de

celui-ci

doit

etre

traduit

dans

le

format

XDR

dans

KitLog

Ceci

induit

deux

copies

suppl?ementaires

Nous

ne

tenons

pas

compte

de

celles-ci

dans

la

mesure

o?u

Camelot

ne

semble

pas

fournir

un

tel

service

Les

co

uts

li?es

aux

caract?eristiques

encapsul?ees

par

les

objets

-LRB-

r?eplication

partage

gestion

de

cache

-RRB-

se

retrouvent

dans

une

application

qui

assure

les

m

emes

caract?eristiques

de

journalisation

Toutefois

l'envoi

des

enregistrements

a

un

ensemble

de

serveurs

m?erite

une

discussion

un

peu

plus

pouss?ee

Le

prototype

de

KitLog

n'utilise

pas

la

diffusion

Par

cons?equent

lorsqu'un

enregistrement

doit

etre

envoy?e

a

un

ensemble

de

serveurs

pour

chacun

d'eux

il

doit

etre

copi?e

sur

le

r?eseau

Afin

d'

eviter

ces

copies

il

pourrait

etre

souhaitable

de

r?ealiser

une

classe

de

distribution

utilisant

un

protocole

de

diffusion

Ceci

est

assez

complexe

a

r?ealiser

car

les

diff?erents

objets

de

distribution

doivent

coop?erer

pour

n'envoyer

qu'un

seul

message

Toutefois

ceci

est

possible

dans

le

prototype

actuel

car

les

objets

peuvent

avoir

connaissance

les

uns

des

autres

en

consultant

l'

etat

du

graphe

et

la

nature

des

objets

en

acc?edant

aux

structures

de

donn?ees

sur

les

objets

d?ecrites

au

x

du

chapitre

V.

-LCB-

-LCB-

Chapitre

VI

Bilan

Les

sections

suivantes

discutent

quelques

points

particuliers

de

KitLog

mettant

a

jour

quelques

probl?emes

jusqu

a

pr?esent

non

abord?es

et

sugg?erant

des

am?eliorations

Synchronisation

de

processus

Un

probl?eme

de

d?es?equencement

des

enregistrements

peut

se

produire

lorsque

deux

processus

partagent

un

m

eme

journal

logique

en

ecriture

Les

enregistrements

doivent

etre

stock?es

sur

le

support

de

stockage

final

dans

l'ordre

des

identificateurs

croissants

Le

d?es?equencement

des

enregistrements

peut

se

produire

dans

les

cas

suivants

p

lorsque

les

processus

sont

sur

deux

sites

distincts

et

que

les

messages

transportant

les

enregistrements

sont

d?es?equenc?es

-LRB-

ceci

peut

r?esulter

d'un

probl?eme

d'horloges

indiquant

des

heures

diff?erentes

et

non

de

d?es?equencement

r?eel

des

messages

-RRB-

p

lorsque

l'application

g?en?ere

elle-m

eme

les

identificateurs

d'enregistrements

et

n'envoie

pas

les

enregistrements

au

service

de

journalisation

dans

l'ordre

des

identificateurs

p

lorsque

les

enregistrements

ne

suivent

pas

le

m

eme

chemin

dans

le

graphe

avant

d'

etre

multiplex?es

par

un

bloc

de

partage

et

que

dans

la

partie

non

commune

du

graphe

des

blocs

tampons

retiennent

les

enregistrements

Les

deux

derniers

cas

sont

du

ressort

de

l'application

Le

premier

cas

peut

etre

r?esolu

de

diff?erentes

fa?cons

Dans

la

premi?ere

solution

les

deux

processus

se

synchronisent

par

envoi

des

enregistrements

a

un

m

eme

serveur

celui-ci

g?en?erant

les

identificateurs

d'enregistrements

Ainsi

c'est

l'ordre

de

r?eception

des

enregistrements

qui

d?etermine

l'ordre

des

enregistrements

Ceci

est

possible

car

les

clients

communiquent

avec

les

serveurs

au

moyen

du

protocole

TCP

en

mode

bloquant

TCP

etant

fiable

il

n

y

a

pas

de

risque

de

perte

de

message

De

plus

si

le

journal

est

r?eparti

les

serveurs

communiquant

entre

eux

par

le

protocole

TCP

ne

peuvent

pas

d?es?equencer

les

enregistrements

En

effet

lorsqu'un

message

contenant

des

enregistrements

est

envoy?e

a

un

autre

serveur

la

main

est

rendue

au

premier

serveur

une

fois

le

message

re?cu

Le

serveur

r?ecepteur

du

message

peut

traiter

le

message

tomber

en

panne

ou

simplement

mettre

le

message

en

attente

Un

second

message

arrivant

par

la

suite

sera

n?ecessairement

trait?e

apr?es

le

premier

car

les

serveurs

son

mono-t

ache

-LRB-

en

cas

de

panne

le

probl?eme

n'est

pas

celui

d'un

d?es?equencement

mais

une

perte

d'enregistrement

et

a

et?e

discut?e

au

du

chapitre

V

-RRB-

Une

seconde

solution

consiste

a

utiliser

un

protocole

de

communication

conservant

la

causalit?e

entre

les

diff?erents

messages

-LSB-

Isis

-RSB-

La

derni?ere

solution

consiste

a

r?eordonner

les

enregistrements

lors

de

la

lecture

Cette

solution

existe

dans

les

m?ethodes

de

journalisation

de

messages

par

un

emetteur

pr?esent?ees

au

chapitre

II

-LCB-

-LCB-

Atomicit?e

des

ecritures

sur

un

journal

logique

Dans

l'

etat

du

prototype

la

premi?ere

solution

est

utilisable

La

seconde

pourrait

etre

r?ealis?ee

en

modifiant

le

protocole

de

communication

entre

client

et

serveur

Toutefois

il

serait

pr?ef?erable

de

modifier

au

pr?ealable

le

prototype

de

mani?ere

a

repousser

les

objets

dans

les

espaces

d'adressage

des

clients

ainsi

la

seconde

solution

serait

r?ealis?ee

par

adjonction

d'une

classe

de

distribution

r?ealisant

un

protocole

de

communication

respectant

la

causalit?e

Enfin

la

derni?ere

solution

peut

etre

r?ealis?ee

par

une

nouvelle

classe

de

partage

Atomicit?e

des

ecritures

sur

un

journal

logique

KitLog

ne

garantit

pas

l'atomicit

e

de

l'

ecriture

d'un

paquet

d'enregistrements

sur

un

journal

logique

L'op

eration

flush

-LRB-

-RRB-

peut

etre

d?eclench?ee

par

une

application

qui

souhaite

ecrire

physiquement

des

enregistrements

sur

le

support

physique

Elle

peut

egalement

etre

d?eclench?ee

automatiquement

par

un

tampon

lorsque

celui-ci

est

plein

Dans

ce

second

cas

l'objet

passe

le

contenu

de

son

tampon

a

son

successeur

En

pratique

cela

correspond

g?en?eralement

a

une

op?eration

flush

-LRB-

-RRB-

s

il

n'existe

pas

d'autres

objets

tampon

parmis

les

successeurs

de

l'objet

Ce

second

cas

peut

poser

un

probl?eme

d'atomicit

e

des

mises

a

jour

sur

le

journal

comme

nous

l'avons

vu

dans

la

description

de

KFS

lorsque

un

ensemble

d'enregistrements

doit

etre

ecrit

d'une

mani?ere

atomique

Une

solution

consiste

a

disposer

d'une

op?eration

flush

-LRB-

-RRB-

permettant

de

forcer

les

ecritures

de

mani?ere

logique

Les

donn?ees

au

moment

du

d?eclenchement

de

l'op

eration

peuvent

etre

d?ej?a

ecrites

sur

le

suppport

de

stockage

mais

le

gestionnaire

de

journal

a

m?emoris?e

que

l'ordre

n

a

pas

et?e

donn?e

de

forcer

les

ecriture

Il

peut

alors

en

cas

de

panne

de

l'application

cliente

d?eclarer

les

enregistrements

obsol?etes

Dans

le

prototype

actuel

l'application

peut

relire

les

derniers

enregistrements

d'un

journal

logique

et

les

effacer

afin

de

garantir

cette

atomicit?e

toutefois

elle

devra

garder

les

informations

n?ecessaires

pour

d?eterminer

la

liste

des

enregistrements

qui

doivent

etre

effac?es

Enregistrements

obsol?etes

Un

certain

nombre

de

modifications

peuvent

etre

apport?ees

a

la

m?ethode

de

d?eclaration

des

enregistrements

obsol?etes

Enregistrements

valides

La

d?eclaration

de

la

liste

des

enregistrements

valides

d'un

journal

logique

plut

ot

que

celle

des

enregistrements

obsol?etes

pourrait

etre

int?eressante

pour

les

applications

qui

souhaitent

d?eclarer

effa?cables

de

grandes

listes

d'enregistrements

en

un

seul

coup

ou

pour

celles

qui

conservent

ces

listes

comme

KFS

-LCB-

-LCB-

Chapitre

VI

Bilan

Pour

le

service

de

journalisation

cette

m?ethode

aurait

l'avantage

de

faciliter

la

coh?erence

de

copies

multiples

d'un

m

eme

journal

logique

-LRB-

cf.

chapitre

V

-RRB-

et

permettrait

de

r?ealiser

plus

simplement

le

flush

-LRB-

-RRB-

logique

Appels

ascendants

Lorsque

le

support

de

stockage

se

remplit

et

que

le

compactage

ne

suffit

pas

a

lib?erer

de

la

place

il

serait

souhaitable

de

pouvoir

demander

aux

clients

de

la

journalisation

de

donner

des

informations

permettant

le

compactage

Les

services

de

journalisation

de

Camelot

-LSB-

Daniels

-RSB-

et

QuickSilver

-LSB-

Haskin

et

al.

-RSB-

peuvent

utiliser

un

tel

proc?ed?e

parce

que

leurs

clients

sont

sp?ecifiques

et

sont

structur?es

sous

forme

de

serveurs

Une

solution

envisag?ee

est

de

permettre

aux

applications

structur?ees

sous

la

forme

de

serveur

de

donner

l'adresse

d'une

proc?edure

a

appeler

pour

leur

signaler

un

besoin

d'information

Cette

solution

doit

etre

compl?et?ee

par

un

syst?eme

d'appels

ascendants

des

objets

du

graphe

-LSB-

Shapiro

et

al.

Druschel

et

al.

-RSB-

Un

appel

ascendant

-LRB-

upcall

-RRB-

consiste

pour

un

objet

a

pouvoir

invoquer

des

op?erations

de

son

pr?ed?ecesseur

Les

objets

ont

ainsi

deux

interfaces

une

interface

d'appels

descendants

et

une

interface

d'appels

ascendants

Ceci

permet

de

faire

remonter

des

invocations

des

feuilles

du

graphe

vers

son

sommet

Le

seul

v?eritable

probl?eme

de

cette

r?ealisation

est

de

traverser

les

espaces

d'adressage

En

effet

pour

qu'un

client

puisse

recevoir

des

invocations

ou

des

requ

etes

il

est

n?ecessaire

s

il

n'est

pas

structur?e

sous

la

forme

d'un

serveur

de

lui

adjoindre

une

partie

capable

de

recevoir

des

invocations

Lorsqu'il

est

d?ej?a

structur?e

en

serveur

il

faut

pouvoir

lui

donner

une

proc?edure

ou

une

s?erie

de

proc?edures

de

la

librairie

cliente

a

appeler

en

cas

de

demande

d'invocation

ascendante

des

objets

du

graphe

Journaux

logiques

corr?el?es

Les

applications

peuvent

souhaiter

disposer

de

plusieurs

journaux

logiques

ayant

un

lien

s?emantique

entre

eux

On

peut

par

exemple

imaginer

un

journal

logique

de

donn?ees

et

un

journal

logique

de

contr

ole

Le

principal

int?er

et

provient

de

la

s?eparation

des

journaux

pour

certaines

op?erations

et

leur

traitement

global

pour

d'autres

op?erations

le

cas

le

plus

evident

etant

l'invalidation

d'enregistrements

Un

exemple

simple

dans

le

cas

de

la

journalisation

de

message

consiste

a

isoler

dans

un

journal

logique

les

messages

d'un

processus

dans

un

autre

les

points

de

sauvegarde

La

recherche

d'enregistrements

ou

de

points

de

sauvegarde

successifs

serait

simplifi?ee

par

cette

s?eparation

alors

que

l'invalidation

des

enregistrements

des

deux

journaux

ant?erieurs

a

un

point

de

sauvegarde

est

simplifi?ee

par

la

corr?elation

des

deux

journaux

logiques

Une

solution

simple

consiste

a

ce

que

tous

les

enregistrements

d'un

journal

logique

donn?e

puissent

appartenir

a

diff?erents

journaux

logiques

comme

le

propose

Clio

-LSB-

Finlayson

et

Cheriton

Finlayson

-RSB-

Ce

qui

revient

a

hi?erarchiser

les

journaux

logiques

-LCB-

-LCB-

Approche

application

Cette

solution

est

assez

simple

a

r?ealiser

sans

surco

ut

excessif

il

suffit

de

stocker

l'information

d'appartenance

aux

diff?erents

journaux

dans

un

journal

de

m?eta

donn?ees

suppl?ementaire

Cette

hi?erarchisation

des

journaux

logiques

r?esout

de

nombreux

probl?emes

Elle

permettrait

notamment

dans

le

cas

des

transactions

embo

t?ees

de

faire

appartenir

tous

les

enregistrements

des

diff?erentes

sous-transactions

d'une

m

eme

transaction

m?ere

a

un

journal

logique

commun

tout

en

disposant

d'un

journal

logique

par

sous-transaction

-LRB-

inclu

dans

le

journal

de

la

transaction

m?ere

-RRB-

Les

enregistrements

de

toutes

les

soustransactions

pourraient

etre

invalid?es

par

destruction

du

journal

logique

de

la

transaction

m?ere

si

celle-ci

est

abandonn?ee

Alors

que

la

s?eparation

du

journal

d'une

sous-transaction

permettrait

une

lecture

plus

simple

des

enregistrements

qui

lui

sont

propres

Approche

application

Deux

approches

etaient

possibles

lors

de

la

conception

de

KitLog

l'

approche

application

et

l'

approche

programmation

L'

approche

application

consiste

a

fournir

un

outil

simple

a

manipuler

avec

une

interface

d'utilisation

ne

demandant

pas

une

grande

connaissance

des

m?ecanismes

de

fonctionnement

du

service

Elle

est

caract?eris?ee

par

des

librairies

d'interfaces

clients

et

des

fichiers

de

configuration

C'est

l'approche

choisie

par

KitLog

ou

GATOS

-LSB-

Boutaba

et

Folliot

-RSB-

par

exemple

L'

approche

programmation

consiste

a

fournir

un

ensemble

d'outils

dont

le

client

doit

contr

oler

et

g?erer

le

fonctionnement

en

cours

d'ex

ecution

eventuellement

aid?e

par

un

langage

de

programmation

Dans

le

cas

des

objets

cette

approche

est

caract?eris?ee

par

des

librairies

d'objets

pr?ed?efinis

que

l'application

doit

cr?eer

et

d?etruire

elle

m

eme

Cette

approche

a

et?e

choisie

par

des

syst?emes

tels

que

BOAR

-LSB-

Makpangou

et

al.

-RSB-

ou

Arjuna

-LSB-

Shrivastava

et

al.

-RSB-

Dans

le

cas

de

KitLog

l'approche

programmation

aurait

consist?e

a

fournir

une

biblioth?eque

d'objets

a

l'application

Celle-ci

aurait

d

u

ecrire

le

code

n?ecessaire

a

l'instanciation

l'initialisation

et

la

liaison

des

objets

composant

son

graphe

entre

eux

L'

approche

application

consiste

a

fournir

le

mini-langage

de

description

de

graphe

et

une

librairie

client

et

de

se

charger

des

op?erations

de

manipulation

des

objets

L'

approche

application

est

plus

complexe

a

r?ealiser

puisqu'il

faut

effectuer

la

gestion

des

objets

mais

elle

est

plus

simple

d'utilisation

L'

approche

programmation

est

plus

adapt?ee

dans

un

syst?eme

a

objets

dont

la

gestion

est

d?ej?a

r?ealis?ee

par

le

syst?eme

Nous

avons

choisi

l'

approche

application

pour

sa

simplicit?e

d'utilisation

et

pour

l'ind

ependance

qu'elle

apporte

a

KitLog

il

n

y

a

pas

de

mod?ele

d'objet

particulier

ni

de

langage

de

programmation

li?e

aux

objets

utilis?es

-LCB-

-LCB-

Chapitre

VII

Conclusion

En

premier

lieu

nous

montrons

dans

quelle

mesure

nos

objectifs

ont

et?e

atteints

puis

nous

r?esumons

l'

etat

du

prototype

Nous

indiquons

ensuite

les

perspectives

de

KitLog

avant

de

conclure

R?ealisation

des

objectifs

Les

objectifs

que

nous

nous

etions

fix?es

ont

et?e

atteints

dans

une

large

mesure

d'une

part

KitLog

est

un

bon

outil

d'aide

pour

la

fiabilit?e

d'une

application

d'autre

part

il

est

caract?eris?e

par

une

grande

g?en?ericit?e

Un

outil

pour

la

fiabilit?e

A

l'exception

d'Isis

-LSB-

Birman

et

Joseph

-RSB-

et

de

KitLog

il

n'existe

pas

a

notre

connaissance

d'outil

g?en?eral

ind?ependant

des

m?ecanismes

sp?ecifiques

a

un

langage

ou

un

syst?eme

aidant

une

application

a

assurer

sa

fiabilit?e

Alors

qu'Isis

propose

principalement

un

ensemble

de

protocoles

de

diffusion

r?ealisant

diff?erents

niveaux

de

fiabilit?e

des

communications

KitLog

a

une

approche

compl?ementaire

permettant

diff?erents

niveaux

de

fiabilit?e

du

stockage

Une

application

qui

baserait

la

totalit?e

de

son

stockage

sur

KitLog

-LRB-

tel

que

KFS

-RRB-

pourait

choisir

ses

caract?eristiques

en

mati?ere

de

fiabilit?e

Les

restrictions

serait

limit?ees

aux

hypoth?eses

de

fonctionnement

de

KitLog

et

a

l'ensemble

des

protocoles

disponibles

encapsul?es

par

les

blocs

r?ealis?es

De

plus

l'aspect

g?en?erique

de

KitLog

en

fait

un

bon

laboratoire

pour

exp?erimenter

de

nouveaux

protocoles

pour

la

fiabilit?e

Il

est

toutefois

probable

qu

a

l'usage

des

limitations

li?ees

au

mod?ele

apparaissent

pour

la

r?ealisation

de

protocoles

sp?ecifiques

-LCB-

-LCB-

Chapitre

VII

Conclusion

G?en?ericit?e

La

g?en?ericit?e

du

mod?ele

KitLog

est

assur?ee

par

ses

caract?eristiques

d'ouverture

de

modularit?e

de

flexibilit?e

et

de

reconfiguration

dynamique

du

service

Ces

caract?eristiques

sont

en

partie

h?eritables

par

les

applications

clientes

de

KitLog

L'ouverture

du

service

est

la

r?esultante

des

notions

de

type

de

bloc

et

de

classe

qui

peuvent

etre

adjoints

au

service

et

cohabiter

durant

une

m

eme

ex?ecution

La

modularit?e

provient

de

la

notion

de

bloc

qui

d?ecompose

les

caract?eristiques

des

journaux

La

flexibilit?e

est

assur?ee

par

l'encapsulation

dans

des

classes

de

la

r?ealisation

des

blocs

La

reconfiguration

dynamique

est

rendue

possible

par

la

composition

des

objets

et

la

modularit?e

KitLog

propose

trois

niveaux

de

choix

a

ses

clients

pour

la

constitution

de

leurs

journaux

Le

premier

r?eside

dans

le

choix

de

la

m?ethode

de

journalisation

symbolis?ee

par

un

type

abstrait

de

blocs

Le

choix

du

type

des

blocs

d?efinit

celui

des

diff?erents

algorithmes

de

journalisation

Une

fois

le

type

choisi

il

faut

d?ecider

des

classes

des

blocs

afin

de

d?eterminer

les

protocoles

utilis?es

pour

r?ealiser

les

caract?eristiques

des

journaux

Enfin

la

constitution

du

graphe

de

l'application

lui

permet

de

d?efinir

un

ensemble

de

caract?eristiques

pour

ses

journaux

appropri?ees

a

ses

besoins

La

g?en?ericit?e

peut

encore

etre

am?elior?ee

puisqu'il

est

par

exemple

n?ecessaire

d'effectuer

une

recompilation

lors

de

l'ajout

de

classes

de

blocs

et

de

types

Comme

le

montre

l'exemple

de

KFS

une

application

utilisant

KitLog

h?erite

d'une

partie

de

la

g?en?ericit?e

de

celui-ci

En

effet

les

diff?erents

ensembles

de

donn?ees

trait?ees

par

une

application

peuvent

utiliser

diff?erents

graphes

d'objets

en

fonction

de

la

fiabilit?e

que

l'on

souhaite

associer

a

chaque

ensemble

de

donn?ees

Les

possibilit?es

offertes

au

niveau

des

graphes

par

KitLog

-LRB-

reconfiguration

dynamique

par

exemple

-RRB-

sont

directement

h?eritables

par

un

service

de

plus

haut

niveau

L'originalit

e

de

la

g?en?ericit?e

de

KitLog

par

rapport

aux

autres

travaux

dans

ce

domaine

provient

principalement

du

choix

des

caract?eristiques

du

service

qui

ont

et?e

isol?ees

et

de

leur

ind?ependance

vis

a-vis

de

la

nature

des

donn?ees

manipul?ees

L'encapsulation

dans

des

objets

et

la

composition

d'objets

donnent

une

grande

souplesse

au

mod?ele

et

assurent

une

grande

part

de

sa

g?en?ericit?e

Etat

du

prototype

Le

prototype

de

KitLog

dans

son

etat

actuel

compte

environ

lignes

de

C/C

-LRB-

commentaires

compris

-RRB-

Ce

compte

comprend

le

code

source

du

serveur

de

la

librairie

des

clients

et

des

programmes

de

contr

ole

Le

prototype

fonctionne

dans

un

environnement

constitu?e

de

stations

de

travail

Sun

et

Sun

pour

les

versions

de

syst?eme

d'exploitation

SunOS

ou

suivantes

Une

classe

de

chaque

bloc

est

r?ealis?ee

Seule

la

classe

disque

a

et?e

impl?ement?ee

en

ce

qui

concerne

les

supports

de

stockage

Le

compactage

n'est

pas

encore

r?ealis?e

Le

manuel

de

programmation

et

d'utilisation

reste

a

ecrire

-LCB-

-LCB-

Perspectives

Perspectives

Beaucoup

reste

a

faire

autour

de

KitLog

des

am?eliorations

sont

a

apporter

au

prototype

des

etudes

pouvant

d?eboucher

sur

des

am?eliorations

de

la

conception

de

KitLog

peuvent

etre

faites

et

un

certain

nombre

d'extensions

sont

possibles

L'ordre

de

pr?esentation

des

diff?erents

travaux

a

effectuer

n'est

pas

n?ecessairement

celui

de

leur

importance

la

premi?ere

t

ache

a

effectuer

consistant

a

porter

des

applications

sur

KitLog

a

effectuer

des

mesures

de

performances

et

a

r?ediger

le

manuel

d'utilisation

Am?eliorations

du

prototype

La

premi?ere

am?elioration

a

apporter

a

KitLog

consiste

a

r?ealiser

le

mod?ele

dans

sa

totalit?e

c'est

a-dire

principalement

a

repousser

certains

objets

dans

l'espace

d'adressage

des

clients

afin

de

prot?eger

et

d?echarger

les

serveurs

de

ces

objets

et

a

permettre

au

contraire

aux

clients

dignes

de

confiance

de

s

ex?ecuter

dans

le

m

eme

espace

Les

am?eliorations

correspondant

a

une

op?eration

permettant

de

forcer

les

ecritures

de

mani?ere

logique

a

la

d?eclaration

des

enregistrements

obsol?etes

et

a

la

corr?elation

de

journaux

logiques

permettraient

de

disposer

d'un

outil

vraiment

complet

Etudes

De

nouvelles

classes

sont

a

d?efinir

permettant

de

r?ealiser

diff?erents

protocoles

pour

les

diff?erents

blocs

L'

etude

de

nouveaux

blocs

et

de

nouveaux

types

abstraits

permettrait

d'accro

tre

les

possibilit?es

du

mod?ele

De

nouveaux

types

posent

des

probl?emes

de

compatibilit?e

voire

de

conversions

de

types

a

analyser

Pour

cela

il

sera

n?ecessaire

de

modifier

le

langage

de

description

des

graphes

comme

nous

l'avons

indiqu?e

au

du

chapitre

V.

La

mod?ele

de

panne

de

KitLog

peut

etre

affin?e

Pour

cela

une

etude

int?eressante

est

a

faire

afin

de

d?etecter

de

mani?ere

plus

fine

la

nature

des

pannes

ce

qui

permettrait

un

traitement

des

erreurs

plus

pr?ecis

La

cons?equence

d'une

telle

etude

devrait

etre

un

rel

achement

de

certaines

des

hypoth?eses

de

fonctionnement

Enfin

l'

approche

application

peut

etre

am?elior?ee

par

une

nouvelle

conception

du

langage

de

description

des

graphes

et

par

le

d?eveloppement

de

nouveaux

outils

de

haut

niveau

-LRB-

par

exemple

l'outil

d'aide

a

la

conception

des

graphes

pr?esent?e

au

du

chapitre

V

-RRB-

Extensions

Le

portage

et

le

d?eveloppement

d'applications

vari?ees

est

important

pour

confirmer

l'ad

equation

du

mod?ele

a

un

grand

ensemble

de

clients

aux

besoins

diff?erents

KFS

sera

le

premier

client

potentiel

de

KitLog

Le

projet

SOR

projette

egalement

le

d?eveloppement

d'un

outil

de

d?ebogage

de

programmes

parall?eles

utilisant

la

journalisation

de

KitLog

-LCB-

-LCB-

Chapitre

VII

Conclusion

Dans

son

etat

actuel

KitLog

n'est

pas

pr?evu

pour

fonctionner

dans

un

environnement

constitu?e

d'un

tr?es

grand

nombre

de

machines

et

de

r?eseaux

autres

qu'un

r?eseau

local

Un

grand

nombre

de

machines

n?ecessite

d'introduire

une

hi?erarchisation

des

machines

en

domaines

et

ne

constituerait

pas

une

difficult?e

majeure

En

revanche

des

r?eseaux

a

connectique

complexe

posent

de

nouveaux

probl?emes

de

fiabilit?e

entra

nant

un

changement

des

hypoth?eses

de

fonctionnement

pour

tenir

compte

par

exemple

des

cons?equences

des

pannes

de

passerelles

de

communication

ou

de

l'utilisation

de

r?eseaux

de

vitesses

tr?es

variables

Enfin

des

outils

pour

la

gestion

de

la

journalisation

et

le

contr

ole

de

son

fonctionnement

devrait

permettre

de

faciliter

l'utilisation

de

KitLog

ainsi

que

l'

etude

de

son

comportement

L'

etude

d'une

application

r?epartie

complexe

est

indispensable

pour

en

affiner

les

choix

Conclusion

g?en?erale

Comme

nous

l'avons

montr?e

au

chapitre

II

beaucoup

d'applications

ont

besoin

de

journaux

Leurs

besoins

peuvent

etre

class?es

en

deux

grandes

cat?egories

un

besoin

de

fiabilit?e

l'usage

de

journaux

etant

le

plus

grand

d?enominateur

commun

de

la

plupart

des

m?ecanismes

assurant

la

fiabilit?e

et

un

besoin

li?e

a

la

s?emantique

de

stockage

de

la

journalisation

pour

la

rapidit?e

des

ecritures

de

la

journalisation

ou

pour

garder

des

traces

d'ex

ecution

-LRB-

s?ecurit?e

et

d?ebogage

-RRB-

Le

m?ecanisme

de

la

journalisation

commence

a

appara

tre

clairement

comme

un

besoin

indispensable

des

syst?emes

-LSB-

Satyanarayanan

et

al.

Daniels

et

al.

-RSB-

Or

les

journaux

existants

sont

sp?ecifiques

et

difficilement

portables

KitLog

comble

ce

vide

en

fournissant

un

service

de

journalisation

qui

allie

une

grande

g?en?ericit?e

a

une

ind?ependance

de

tout

autre

m?ecanisme

tout

en

fonctionnant

dans

un

environnement

largement

r?epandu

-LCB-

-LCB-

Glossaire

Cet

appendice

regroupe

les

d?efinitions

et

explications

du

vocabulaire

technique

important

utilis?e

dans

ce

document

Elles

sont

autant

que

possible

proches

du

sens

commun

attribu?e

aux

termes

d?efinis

Le

but

de

ce

glossaire

est

de

lever

les

ambiguit?es

eventuelles

li?ees

a

un

vocabulaire

non

normalis?e

Pour

chaque

terme

la

traduction

anglaise

est

donn?ee

-LRB-

si

possible

-RRB-

Action

-LRB-

action

-RRB-

Op?eration

modifiant

des

donn?ees

ou

agissant

sur

des

ressources

-LRB-

impression

affichage

a

l'

ecran

-RRB-

Application

-LRB-

application

-RRB-

Vue

d'un

service

syst?eme

une

application

est

un

programme

ou

un

ensemble

de

programmes

utilisant

ce

service

Un

service

syst?eme

utilisant

d'autres

services

syst?eme

sera

vu

de

leur

part

comme

une

application

Atomicit?e

-LRB-

Atomicity

-RRB-

Assure

que

les

sous-actions

d'une

action

vues

par

une

autre

action

sont

indivisibles

C'est

a-dire

que

soit

toutes

les

sous-actions

d'une

action

sont

effectu?ees

soit

aucune

ne

l'est

En

pratique

si

une

panne

survient

alors

que

seule

une

partie

des

sous-actions

a

et?e

effectu?ee

toutes

ces

actions

seront

d?efaites

Bloc

de

base

ou

bloc

-LRB-

building

block

ou

block

-RRB-

Un

bloc

de

base

est

un

ensemble

de

classes

d'objets

r?ealisant

une

m

eme

fonction

de

journalisation

parmi

les

cinq

d?efinies

dans

le

mod?ele

KitLog

Les

classes

r?ealisant

les

cinq

blocs

se

conforment

au

type

des

blocs

Chasser

les

informations

sur

le

journal

-LRB-

log

force

-RRB-

Action

qui

assure

que

tous

les

enregistrements

d'un

journal

ont

et?e

effectivement

ecrits

sur

son

support

de

stockage

Coh?erence

des

transactions

-LRB-

transaction

consistency

-RRB-

La

propri?et?e

de

coh?erence

des

transactions

sp?ecifie

qu'une

transaction

appliqu?ee

a

un

ensemble

de

donn?ees

coh?erentes

rend

cet

ensemble

dans

un

etat

coh?erent

Communication

Asynchrone

-LRB-

asynchronous

communication

-RRB-

Une

communication

asynchrone

entre

deux

processus

A

et

B

implique

que

le

processus

emetteur

A

ne

soit

pas

bloqu?e

a

partir

du

moment

o?u

le

syst?eme

de

communication

a

pris

en

charge

le

message

Toutefois

le

processus

A

pourra

etre

bloqu?e

durant

certaines

phases

du

traitement

de

la

communication

Une

communication

asynchrone

fiable

est

susceptible

soit

de

bloquer

le

processus

emetteur

A

en

attente

d'un

accus?e

de

r?eception

ou

d'un

message

d'erreur

en

provenance

du

service

de

communication

soit

de

lui

permettre

de

consulter

l'

etat

de

son

envoi

par

la

suite

-LCB-

-LCB-

Glossaire

D?efaillances

erreurs

fautes

-LRB-

failures

errors

faults

-RRB-

Les

d?efinitions

des

termes

d?efaillance

faute

et

erreur

sont

calqu?ees

sur

celles

de

-LSB-

Powell

-RSB-

Une

d?efaillance

survient

lorsqu'un

syst?eme

se

comporte

de

mani?ere

erron?ee

par

rapport

a

ses

sp?ecifications

Une

erreur

est

la

partie

de

l'

etat

du

syst?eme

susceptible

d'entra

ner

une

d?efaillance

Une

faute

est

la

cause

d'une

erreur

mais

aussi

la

cons?equence

d'une

d?efaillance

Elle

peut

etre

dormante

ou

active

Une

faute

active

produit

des

erreurs

qui

peuvent

produire

a

leur

tour

de

nouvelles

d?efaillances

On

obtient

ainsi

le

sch?ema

suivant

faute

erreur

d?ef

aillance

faute

erreur

d?ef

aillance

Enregistrement

-LRB-

record

-RRB-

L'unit

e

d'

ecriture

sur

le

journal

Il

est

compos?e

d'un

corps

d'une

taille

quelconque

qui

est

l'information

que

l'on

souhaite

stocker

sur

le

journal

et

d'un

descripteur

correspondant

a

des

informations

permettant

de

retrouver

sa

provenance

Dans

le

code

de

KitLog

le

descripteur

stock?e

apr?es

le

corps

est

appel?e

un

trailer

Fiabilit?e

-LRB-

reliability

-RRB-

Aptitude

d'un

syst?eme

d'un

mat?eriel

a

fonctionner

sans

incident

pendant

un

temps

donn?e

-LRB-

Petit

Robert

-RRB-

En

fait

il

faut

apporter

une

nuance

a

cette

d?efinition

On

consid?ere

que

les

causes

d'incidents

possibles

ne

sont

pas

le

fruit

de

la

malveillance

d'usagers

-LRB-

programmeurs

ou

autres

-RRB-

Le

degr?e

de

la

fiabilit?e

d'un

syst?eme

est

fonction

de

la

dur?ee

probable

et

des

conditions

de

fonctionnement

sans

incident

de

ce

syst?eme

G?en?erique

-LRB-

generic

-RRB-

Se

dit

d'un

syst?eme

-LRB-

ou

d'un

service

-RRB-

non-d

edi?e

a

une

utilisation

particuli?ere

Un

syst?eme

g?en?erique

offre

un

ensemble

de

fonctions

permettant

de

satisfaire

les

besoins

de

la

majorit?e

des

diff?erentes

vari?et?es

d'applications

en

limitant

le

surco

ut

d

u

a

l'existence

de

fonctions

non

utilis?ees

Journal

-LRB-

log

-RRB-

Un

journal

est

une

s?emantique

de

stockage

particuli?ere

Les

ecritures

se

font

par

concat?enation

d'enregistrements

en

fin

de

journal

Certains

enregistrements

du

journal

peuvent

devenir

obsol?etes

-LRB-

ils

sont

eventuellement

effac?es

par

compactage

-RRB-

aucun

autre

type

d'

ecriture

n'est

possible

La

lecture

est

g?en?eralement

s?equentielle

La

lecture

en

arri?ere

-LRB-

backward

read

-RRB-

consiste

a

lire

le

dernier

enregistrement

du

journal

et

de

proche

en

proche

a

lire

les

enregistrements

pr?ec?edents

La

lecture

en

avant

-LRB-

forward

read

-RRB-

commence

par

la

lecture

d'un

enregistrement

quelconque

du

journal

et

continue

par

la

lecture

des

enregistrements

suivants

De

plus

une

op?eration

particuli?ere

flush

garantit

une

fois

ex?ecut?ee

que

tous

les

enregistrements

ont

et?e

effectivement

ecrits

de

fa?con

durable

sur

le

support

physique

stockant

le

journal

Journal

logique

-LRB-

logical

log

-RRB-

Le

journal

tel

qu'il

est

vu

par

une

application

Il

est

compos?e

d'enregistrements

ayant

un

lien

logique

entre

eux

Dans

KitLog

il

est

symbolis?e

par

un

identificateur

unique

de

journal

-LRB-

Lid

pour

Log

identifier

<=-RRB-

La

nature

du

lien

entre

enregistrements

n'est

connu

que

par

l'application

Journal

physique

-LRB-

physical

log

-RRB-

Un

journal

physique

correspond

a

un

ensemble

d'enregistrements

-LRB-

pouvant

appartenir

a

diff?erents

journaux

logiques

qui

ont

et?e

multiplex?es

-RRB-

qui

se

suivent

s?equentiellement

sur

un

m

eme

support

de

stockage

physique

-LCB-

-LCB-

Glossaire

Panne

-LRB-

failure

-RRB-

classe

de

d?efaillances

particuli?eres

ayant

pour

origine

suppos?ee

une

erreur

mat?erielle

ou

physique

-LRB-

d?ebranchement

d'un

cable

Ethernet

par

exemple

-RRB-

et

dont

la

cons?equence

est

la

perte

ou

l'indisponibilit

e

de

donn?ees

Permanence

ou

Durabilit?e

-LRB-

persistency

ou

durability

-RRB-

Propri?et?e

qui

assure

qu'une

action

faite

le

sera

pour

toujours

quoiqu'il

advienne

au

syst?eme

Pr?ed?ecesseur

d'un

objet

-LRB-

object

predecessor

-RRB-

Dans

la

composition

d'objets

un

pr?ed?ecesseur

d'un

objet

est

soit

un

objet

du

graphe

directement

connect?e

a

l'objet

courant

-LRB-

le

pr?ed?ecesseur

est

alors

appell?e

pr?ed?ecesseur

direct

de

l'objet

courant

-RRB-

soit

par

transitivit?e

un

des

pr?ed?ecesseurs

des

pr?ed?ecesseurs

directs

de

l'objet

courant

Recouvrement

-LRB-

recovery

-RRB-

Action

de

recouvrer

Reprise

apr?es

panne

ou

bien

action

de

d?efaire

et/ou

refaire

des

actions

ponctuelles

en

fonctionnement

sans

panne

-LRB-

dans

le

cadre

du

contr

ole

des

acc?es

concurrents

-RRB-

R?eplication

-LRB-

replication

-RRB-

Copie

des

donn?ees

en

un

certain

nombre

d'exemplaires

par

comparaison

la

duplication

limite

le

nombre

d'exemplaires

a

deux

Reprise

apr?es

panne

Actions

a

entreprendre

au

red?emarrage

a

la

suite

d'une

panne

afin

de

restaurer

un

etat

coh?erent

S?erialisabilit?e

ou

isolation

-LRB-

serialisability

ou

isolation

-RRB-

Technique

qui

ordonne

les

acc?es

aux

donn?ees

en

cas

de

parall?elisme

Bien

que

les

actions

puissent

s

ex?ecuter

concurremment

les

effets

d'une

action

doivent

etre

per?cus

comme

si

elle

s

etait

ex?ecut?ee

en

s?erie

avec

les

autres

actions

en

cours

Une

ex?ecution

d'un

ensemble

d'actions

est

s?erialisable

s

il

existe

une

ex?ecution

en

s?erie

de

ces

m

emes

actions

qui

produit

le

m

eme

effet

Stockage

fiable

ou

stockage

non-volatil

-LRB-

reliable

storage

-RRB-

Il

s

agit

d'un

stockage

r?esistant

aux

pannes

de

site

mais

sujet

aux

pannes

du

support

de

stockage

-LRB-

disques

et

autres

supports

magn?etiques

ou

optiques

-RRB-

Stockage

stable

-LRB-

Stable

storage

-RRB-

C'est

un

stockage

totalement

fiable

r?ealis?e

par

la

duplication

de

stockage

fiable

l'archivage

etc.

Bien

entendu

il

n'existe

pas

de

stockage

stable

mais

on

arrive

a

r?ealiser

des

formes

de

stockage

qui

sont

de

bonnes

approximations

du

stockage

stable

-LRB-

i.e.

la

probabilit?e

de

perte

d'informations

avoisine

z?ero

-RRB-

Stockage

volatil

-LRB-

volatil

storage

-RRB-

C'est

la

partie

du

stockage

perdue

en

cas

de

panne

d'une

machine

-LRB-

m?emoire

vive

-RRB-

Successeur

d'un

objet

-LRB-

object

successor

-RRB-

Dans

la

composition

d'objets

un

successeur

d'un

objet

est

soit

un

objet

du

graphe

directement

connect?e

a

l'objet

courant

qu'on

appellera

successeur

direct

soit

par

transitivit?e

un

des

successeurs

des

successeurs

directs

de

l'objet

courant

Support

de

stockage

-LRB-

storage

medium

-RRB-

Ressource

capable

de

stocker

des

donn?ees

m?emoire

disque

bande

magn?etique

etc.

S

uret?e

de

fonctionnement

La

s

uret?e

de

fonctionnement

est

ce

qui

permet

dans

un

syst?eme

r?eparti

de

palier

aux

comportements

ind?esirables

r?esultants

des

d?efail

-LCB-

-LCB-

Glossaire

lances

des

erreurs

du

parall?elisme

et

de

la

malveillance

Syst?eme

d'exploitation

non

d?edi?e

-LRB-

general-purpose

operating

system

-RRB-

ou

syst?eme

d'exploitation

a

but

g?en?eral

Syst?eme

d'exploitation

dont

les

services

permettent

de

contenter

la

majorit?e

des

besoins

des

applications

traditionnelles

Par

opposition

les

syst?emes

temps-r

eels

synchrones

sont

des

syst?emes

d?edi?es

dans

la

mesure

o?u

ils

ont

et?e

con?cus

pour

satisfaire

des

besoins

tr?es

sp?ecifiques

Transaction

-LRB-

transaction

-RRB-

Collection

d'op

erations

commen?cant

par

une

marque

indiquant

son

d?ebut

et

finissant

par

une

marque

de

fin

de

succ?es

ou

d'

echec

Une

transaction

v?erifie

les

propri?et?e

de

coh?erence

d'atomicit

e

face

aux

pannes

de

s?erialisabilit?e

et

de

permanence

-LRB-

egalement

connues

sous

le

sigle

ACID

atomicit?e

isolation

coh?erence

et

durabilit?e

-RRB-

Type

abstrait

des

blocs

-LRB-

abstract

block

type

-RRB-

Le

type

des

blocs

de

KitLog

correspond

a

la

notion

de

type

abstrait

d'Emerald

Un

type

abstrait

d?efinit

l'interface

d'un

objet

c'est

a-dire

l'ensemble

des

op?erations

support?ees

leur

signature

et

-LRB-

en

principe

-RRB-

leur

s?emantique

La

signature

d'une

op?eration

comprend

le

nom

de

l'op

eration

et

les

types

des

arguments

et

des

r?esultats

-LCB-

-LCB-

R?ef?erences

-LSB-

Bach

-RSB-

Maurice

J.

Bach

The

design

of

the

Unix

operating

system

Prentice-Hall

International

Editions

Description

des

principes

de

conception

du

syst?eme

Unix

-LSB-

Backus

-RSB-

J.

W.

Backus

The

syntax

and

semantics

of

the

proposed

international

algebraic

language

of

the

Zurich

ACM-GAMM

Conference

Proceedings

of

the

International

Conference

on

Information

Processing

Unesco

Paris

-LRB-

France

-RRB-

pages

-LCB-

-LCB-

juin

Description

du

langage

IAL

ou

ALGOL

a

l'aide

du

Backus-Naur

Formalism

-LRB-

BNF

-RRB-

-LSB-

Baer

et

al.

-RSB-

J.

L.

Baer

G.

Gardarin

C.

Girault

G.

Roucairol

The

Two-Step

Commitment

Protocol

Modeling

Specification

and

Proof

Methodology

Proceedings

of

the

fifth

IEEE

International

Conference

on

Software

Engineering

San

Diego

CA

-LRB-

USA

-RRB-

-LCB-

mars

Une

mod?elisation

par

r?eseaux

de

Petri

d'une

variante

de

la

validation

a

deux

phases

-LSB-

Ban

atre

et

al.

-RSB-

Jean-Pierre

Ban

atre

Michel

Ban

atre

Gilles

Muller

Florimond

Ployette

Quelques

aspects

du

syst?eme

GOTHIC

Technique

et

Science

Informatiques

Vol

pages

-LCB-

Un

aper?cu

du

syst?eme

Gothic

-LSB-

Ban

atre

et

al.

-RSB-

Michel

Ban

atre

Gilles

Muller

Brunot

Rochat

Patrick

Sanchez

Design

decisions

for

the

FTM

A

General

Purpose

Fault

Tolerant

Machine

INRIA

-LRB-

France

-RRB-

Rapport

de

Recherche

Mars

Une

solution

mat?erielle

pour

la

r?ealisation

d'une

machine

tol?erante

aux

pannes

bas?ee

sur

la

redondance

compl?ete

du

mat?eriel

-LSB-

Bernstein

et

Goodman

-RSB-

Philip

A.

Bernstein

Nathan

Goodman

TimestampBased

Algorithms

for

Concurrency

Control

in

Distributed

Database

Systems

Proceedings

of

the

Sixth

International

Conference

on

Very

Large

Data

Bases

Montreal

-LRB-

Canada

-RRB-

pages

-LCB-

Octobre

Un

ensemble

d'algorithmes

bas?es

sur

l'estampillage

pour

le

contr

ole

de

concurrence

-LSB-

Bernstein

et

Goodman

-RSB-

Philip

A.

Bernstein

Nathan

Goodman

Concurrency

Control

in

Distributed

Database

Systems

ACM

Computing

Surveys

Vol

pages

-LCB-

Juin

Plus

de

algorithmes

de

contr

ole

de

concurrence

et

leur

comparaison

-LSB-

Berstel

et

Perrot

-RSB-

J.

Berstel

J.

F.

Perrot

Multics

Guide

de

l'usager

Editions

Masson

Description

des

grands

principes

du

syst?eme

Multics

et

du

mode

d'utilisation

du

syst?eme

-LSB-

Bhide

et

al.

-RSB-

Anupam

Bhide

Elmootazbellah

N.

Elnozahy

Stephen

P.

Morgan

Implicit

Replication

in

a

Network

File

Server

Proceedings

of

the

Workshop

on

the

Management

of

Replicated

Data

Houston

TX

-LRB-

USA

-RRB-

pages

-LCB-

-LCB-

novembre

Algorithme

de

r?eplication

utilis?e

par

HA-NFS

un

FS

a

grande

disponibilit?e

-LCB-

-LCB-

R?ef?erences

-LSB-

Birman

-RSB-

Kenneth

P.

Birman

Replication

and

Fault

Tolerance

in

the

Isis

System

Cornell

University

Ithaca

NY

-LRB-

USA

-RRB-

Technical

Report

-LCB-

Mars

D?ecrit

le

principe

des

objets

r?esistants

et

les

protocoles

de

diffusion

d'ISIS

et

donne

quelques

mesures

-LSB-

Birman

et

Joseph

-RSB-

Kenneth

P.

Birman

Thomas

A.

Joseph

Reliable

Communication

in

an

Unreliable

Environment

ACM

Transactions

on

Computing

Systems

Vol

pages

-LCB-

F?evrier

Description

des

protocoles

de

diffusion

d'Isis

et

leur

utilisation

dans

la

r?eplication

pour

assurer

la

fiabilit?e

-LSB-

Bjork

-RSB-

Lawrence

A.

Bjork

Recovery

Scenario

for

a

DB/DC

System

Proceedings

ACM

National

Conference

Atlanta

GA

-LRB-

USA

-RRB-

Ao

ut

Article

a

lire

apr?es

-LSB-

Davies

-RSB-

Un

exemple

de

sc?enario

de

recouvrement

tr?es

g?en?eral

-LSB-

Black

et

al.

-RSB-

A.

Black

N.

C.

Hutchinson

E.

Jul

H.

M.

Levy

L.

Carter

Distribution

and

abstract

types

in

Emerald

IEEE

Transactions

on

Software

Engineering

Vol

pages

-LCB-

Janvier

La

d?efinition

des

types

abstraits

d'Emerald

et

la

gestion

de

la

r?epartition

des

objets

-LSB-

Black

et

al.

-RSB-

David

L.

Black

David

B.

Golub

Daniel

P.

Julien

Richard

F.

Rashid

Richard

P.

Draves

Randall

W.

Dean

Alessandro

Forin

Joseph

Barrera

Hideyuki

Tokuda

Gerald

Malan

David

Bohman

Microkernel

Operating

System

Architecture

and

Mach

USENIX

Workshop

on

Micro-Kernels

and

other

Kernel

Architectures

Seattle

WA

-LRB-

USA

-RRB-

pages

-LCB-

Avril

Description

de

Mach

et

de

la

realisation

de

syst?emes

au

dessus

de

Mach

-LSB-

Blain

-RSB-

Laurent

Blain

La

tol?erance

aux

fautes

pour

la

gestion

de

la

s?ecurit?e

dans

les

syst?emes

r?epartis

Th?ese

de

l'Institut

National

Polytechnique

de

Toulouse

-LRB-

France

-RRB-

LAAS

-LRB-

France

-RRB-

Rapport

de

Recherche

janvier

Un

serveur

de

s?ecurit?e

pour

Delta

bas?e

sur

la

technique

de

fragmentation-redondancediss

emination

-LSB-

Boksenbaum

et

al.

-RSB-

C.

Boksenbaum

M.

Cart

J.

Ferrier

J.

F.

Pons

Le

contr

ole

de

coh?erence

dans

les

bases

de

donn?ees

distribu?ees

Centre

de

Recherche

en

Informatique

de

Montpellier

-LRB-

France

-RRB-

Rapport

Technique

Novembre

Une

synth?ese

assez

th?eorique

du

contr

ole

de

concurrence

-LSB-

Borg

et

al.

-RSB-

Anita

Borg

Jim

Baumbach

Sam

Glazer

A

Message

System

Supporting

Fault

Tolerance

Proceedings

of

the

Ninth

ACM

Symposium

on

Operating

Systems

Principles

Bretton

Woods

NH

-LRB-

USA

-RRB-

Operating

Systems

Review

Vol

pages

-LCB-

-LCB-

octobre

Auragen

un

syst?eme

g?erant

la

reprise

apr?es

panne

par

copie

des

messages

et

de

l'

etat

des

processus

-LSB-

Boutaba

et

Folliot

-RSB-

Raouf

Boutaba

Bertil

Folliot

Load

Balancing

in

Local

Area

Networks

Laboratoire

MASI

Institut

Blaise

Pascal

Universit?e

Paris

VI

Paris

-LRB-

France

-RRB-

Rapport

Technique

Juin

Description

d'algorithmes

de

r?epartition

de

charge

dans

GATOS

-LSB-

Br?es

-RSB-

Guillaume

Br?es

Panorama

sur

les

g?en?eraux

Byzantins

Technique

et

Science

Informatiques

Vol

pages

-LCB-

Mai

Etude

des

pannes

byzantines

dans

les

syst?emes

distribu?es

-LSB-

Cristian

et

al.

-RSB-

Flaviu

Cristian

Houtan

Aghili

Ray

Strong

Danny

Dolev

Atomic

Broadcast

From

simple

message

Diffusion

to

Byzantine

Agreement

Proceedings

of

the

Fifteenth

Annual

International

Symposium

on

Fault-Tolerant

Computing

Ann

Arbor

MI

-LRB-

USA

-RRB-

pages

-LCB-

-LCB-

juin

Taxonomie

des

pannes

protocoles

de

diffusions

r?esistant

a

diff?erentes

sortes

de

pannes

-LCB-

-LCB-

R?ef?erences

-LSB-

Crowcroft

et

Onions

-RSB-

J.

Crowcroft

J.

Onions

Network

Time

Protocol

-LRB-

NTP

-RRB-

over

the

OSI

Remote

Operations

Service

Request

For

Comments

Juin

Description

officielle

du

protocole

NTP

de

remise

a

jour

des

horloges

en

r?eparti

-LSB-

Curtis

et

Wittie

-RSB-

R.

Curtis

L.

Wittie

Bugnet

a

Debugging

System

for

Parallel

Programming

Environments

Proceedings

of

the

Third

International

Conference

on

Distributed

Computing

Systems

Miami

FL

-LRB-

USA

-RRB-

pages

-LCB-

-LCB-

octobre

Bugnet

un

outil

pour

le

d?ebogage

r?eparti

bas?e

sur

la

journalisation

de

messages

-LSB-

Daniels

-RSB-

Dean

Spencer

Daniels

Distributed

Logging

for

Transaction

Processing

PhD

thesis

Carnegie-Mellon

University

Pittsburgh

PA

-LRB-

USA

-RRB-

Technical

Report

CMU

D?ecembre

Etude

des

diff?erents

choix

de

conception

et

r?ealisation

des

journaux

etude

du

journal

de

Camelot

-LSB-

Daniels

et

al.

-RSB-

Dean

S.

Daniels

Alfred

Z.

Spector

Dean

S.

Thompson

Distributed

Logging

for

Transaction

Processing

Proceedings

of

the

ACM

Special

Interest

Group

on

Management

of

Data

San

Francisco

CA

-LRB-

USA

-RRB-

Mai

SIGMOD

Record

Vol

pages

-LCB-

D?ecembre

Algorithme

de

gestion

de

la

r?eplication

r?epartie

du

journal

de

Camelot

-LSB-

Daniels

et

al.

-RSB-

Dean

Daniels

Roger

Haskin

Jon

Reinke

Wayne

Sawdon

Shared

Logging

Services

for

Fault

Tolerant

Distributed

Computing

Proceedings

of

the

fourth

ACM

SIGOPS

European

Workshop

Bologna

-LRB-

Italy

-RRB-

-LCB-

septembre

Operating

Systems

Review

Vol

pages

Janvier

Pourquoi

il

est

important

d'avoir

un

service

syst?eme

de

journalisation

-LSB-

Davidson

-RSB-

Susan

B.

Davidson

An

advanced

Course

on

Distributed

Computing

Chapitre

Replicated

data

and

Partition

Failures

Fingerlakes

authorized

preprint

edited

by

Sape

J.

Mullender

pages

-LCB-

Juillet

Une

synth?ese

tr?es

claire

sur

les

techniques

de

r?eplication

et

le

partitionnement

-LSB-

Davidson

et

al.

-RSB-

Susan

B.

Davidson

Hector

Garcia-Molina

Dale

Skeen

Consistency

in

Partitioned

Networks

ACM

Computing

Surveys

Vol

pages

-LCB-

Septembre

Une

synth?ese

sur

les

techniques

de

maintien

de

la

coh?erence

en

cas

de

partitionment

de

r?eseau

-LSB-

Davies

-RSB-

Charles

T.

Davies

Recovery

Semantics

for

a

DB/DC

System

Proceedings

ACM

National

Conference

Atlanta

GA

-LRB-

USA

-RRB-

Ao

ut

La

d?efinition

des

notions

de

base

du

recouvrement

-LSB-

Deswarte

-RSB-

Yves

Deswarte

Fragmentation-Redundancy-Scatering

a

means

to

tolerate

accidental

faults

and

intrusions

in

distributed

systems

Proceedings

of

the

Ercim

Workshop

on

Distributed

Systems

INESC

Lisbon

-LRB-

Portugal

-RRB-

pages

-LCB-

-LCB-

Novembre

Un

tr?es

court

article

qui

explique

bien

les

probl?emes

de

s?ecurit?e

et

propose

une

solution

-LSB-

Dixon

et

al.

-RSB-

G.

N.

Dixon

G.

D.

Parrington

S.

K.

Shrivastava

S.

M.

Wheater

The

Treatment

of

Persistant

Objects

in

Arjurna

ECOOP

European

Workshop

on

Object-Oriented

Programming

Nottingham

-LRB-

UK

-RRB-

Juillet

Une

description

g?en?erale

des

principes

de

base

d'Arjuna

-LSB-

Douglis

et

Ousterhout

-RSB-

Fred

Douglis

John

Ousterhout

Log-Structured

File

Systems

Intellectual

leverage

COMPCON

Spring

thirty-fourth

IEEE

Computer

Society

International

Conference

San

Francisco

CA

-LRB-

USA

-RRB-

F?evrier

-LCB-

Mars

Description

d'un

syst?eme

de

fichiers

enti?erement

journalis?e

-LCB-

-LCB-

R?ef?erences

-LSB-

Druschel

et

al.

-RSB-

Peter

Druschel

Larry

L.

Peterson

Norman

C.

Hutchinson

Lipto

A

Dynamically

Configurable

Object-Oriented

Kernel

Newsletter

of

the

IEEE

Computer

Society

Technical

Committee

on

Operating

Systems

and

Application

Environments

Vol

pages

-LCB-

Description

succincte

de

Lipto

le

successeur

de

x-Kernel

-LSB-

Druschel

et

al.

-RSB-

Peter

Druschel

Larry

L.

Peterson

Norman

C.

Hutchinson

Decoupling

Modularity

and

Protection

in

Lipto

University

of

Arizona

Tucson

AZ

-LRB-

USA

-RRB-

Technical

Report

f?evrier

Lipto

description

de

la

gestion

d'objets

la

s?eparation

syst?eme

application

et

quelques

mesures

de

performances

-LSB-

Ellis

et

Stroustrup

-RSB-

Margaret

A.

Ellis

Bjarne

Stroustrup

The

Annotated

C++

Reference

Manual

ANSI

Base

Document

Addison-Wesley

Publishing

Company

Sp?ecification

officielle

du

langage

C++

-LSB-

Elnozahy

et

Zwaenepoel

-RSB-

Elmootazbellah

N.

Elnozahy

Willy

Zwaenepoel

Manetho

Transparent

Rollback

Recovery

with

Low-Overhead

Limited

RollBack

and

Fast

Output

IEEE

Transactions

on

Computers

Mai

Ajoute

aux

algorithmes

tels

que

-LSB-

Strom

et

al.

-RSB-

l'utilisation

de

graphes

d'ant

ec?edences

-LSB-

Eswaran

et

al.

-RSB-

K.

P.

Eswaran

J.

N.

Gray

R.

A.

Lorie

I.

L.

Traiger

The

notions

of

Consistency

and

Predicate

Locks

in

a

Database

System

Communication

of

the

ACM

Vol

pages

-LCB-

Novembre

Verrouillage

a

deux

phases

et

coh?erence

-LSB-

Finlayson

-RSB-

Ross

Stuart

Finlayson

A

Log

File

Service

Exploiting

Write-once

Storage

PhD

thesis

Stanford

University

Stanford

CA

-LRB-

USA

-RRB-

Technical

Report

STAN

Juillet

Description

d?etaill?ee

du

syst?eme

de

fichiers

de

Clio

enti?erement

journalis?e

-LSB-

Finlayson

et

Cheriton

-RSB-

Ross

S.

Finlayson

David

R.

Cheriton

Log

Files

An

Extended

File

Service

Write-Once

Storage

Proceedings

of

the

Eleventh

ACM

Symposium

on

Operating

Systems

Principles

Austin

TX

-LRB-

USA

-RRB-

Operating

Systems

Review

Vol

pages

-LCB-

Novembre

Etude

d'une

repr?esentation

physique

de

journal

et

de

fichiers

enti?erement

journalis?es

-LSB-

Folliot

et

Ruffin

-RSB-

Bertil

Folliot

Michel

Ruffin

G?erant

de

T

aches

Objets

dans

un

Syst?eme

Distribu?e

Convention

UNIX

Actes

des

Conf?erences

Techniques

Paris

-LRB-

France

-RRB-

pages

-LCB-

-LCB-

mars

Un

r?epartiteur

de

t

aches

automatique

au

dessus

d'UNIX

-LSB-

Franklin

et

al.

-RSB-

Michael

J.

Franklin

Michael

J.

Zwilling

C.

K.

Tan

Michael

J.

Carey

David

J.

DeWitt

Crash

Recovery

in

Client-Server

Exodus

Proceedings

of

the

ACM

Special

Interest

Group

on

Management

of

Data

San

Diego

CA

-LRB-

USA

-RRB-

ACM

SIGMOD

record

Vol

pages

-LCB-

-LCB-

Juin

Le

recouvrement

dans

Exodus

un

syst?eme

d'objets

persistants

-LSB-

Gardarin

-RSB-

Georges

Gardarin

Bases

de

Donn?ees

les

syst?emes

et

leurs

Langages

Editions

Eyrolles

Pr?esentation

g?en?erale

des

bases

de

donn?ees

et

des

m?ecanismes

aff?erents

-LSB-

Gardarin

et

Valduriez

-RSB-

Georges

Gardarin

Patrick

Valduriez

Relationnal

Databases

and

Knowledge

Bases

Chapitre

Reliability

Addison-Wesley

Publishing

Company

pages

-LCB-

Un

aper?cu

des

techniques

de

recouvrement

-LSB-

Gharachorloo

et

al.

-RSB-

Kourosh

Gharachorloo

Daniel

Lenoski

James

Laudon

Phillip

Gibbons

Anoop

Gupta

John

Hennessy

Memory

Consistency

and

-LCB-

-LCB-

R?ef?erences

Event

Ordering

in

Scalable

Shared-Memory

Multiprocessors

Proceedings

of

the

Seventeenth

Annual

International

Symposium

on

Computer

Architectures

Seattle

WA

-LRB-

USA

-RRB-

Vol

pages

-LCB-

Mai

Diff?erentes

politiques

de

gestion

de

la

coh?erence

d?efinition

de

la

coh?erence

rel

ach?ee

-LSB-

Gourhant

-RSB-

Yvon

Gourhant

Outils

pour

la

programmation

d'objets

fragment?es

Th?ese

de

Doctorat

de

L'universit

e

Paris

VI

Paris

-LRB-

France

-RRB-

juin

Concept

d'objet

fragment?es

description

d'un

langage

d'une

biblioth?eque

d'objets

fragment?es

et

d'un

compilateur

-LSB-

Gray

-RSB-

J.

N.

Gray

Notes

on

Database

Operating

Systems

Lecture

Notes

in

Computer

Science

Vol

Operating

Systems

An

Advanced

Course

Edited

by

R.

Bayer

R.

M.

Graham

and

G.

Seegm?uller

Springer

Verlag

Berlin

Heidelberg

New

York

pages

-LCB-

Une

synth?ese

sur

les

techniques

transactionnelles

dans

les

bases

de

donn?ees

tr?es

compl?ete

-LSB-

Gray

et

al.

-RSB-

Jim

Gray

Paul

McJones

Mike

Blasgen

Bruce

Lindsay

Raymond

Lorie

Tom

Price

Franco

Putzoli

Irving

Traiger

The

Recovery

Manager

of

the

System

R

Database

Manager

ACM

Computing

Surveys

Vol

pages

-LCB-

Juin

Description

d?etaill?ee

du

syst?eme

R

et

des

besoins

de

s

uret?e

de

fonctionnement

des

bases

de

donn?ees

-LSB-

Guy

-RSB-

Richard

G.

Guy

Ficus

a

Very

Large

Scale

Reliable

Distributed

File

System

PhD

thesis

University

of

California

Los

Angeles

CA

-LRB-

USA

-RRB-

Technical

Report

UCLA

Juin

Description

d?etaill?ee

de

Ficus

-LSB-

Haerder

et

Reuter

-RSB-

Theo

Haerder

Andreas

Reuter

Principles

of

TransactionOriented

Database

Recovery

ACM

Computing

Surveys

Vol

pages

-LCB-

D?ecembre

Une

synth?ese

des

techniques

de

recouvrement

-LSB-

Hagmann

-RSB-

Robert

Hagmann

Reimplementing

the

Cedar

File

System

Using

Logging

and

Group

Commit

Proceedings

of

the

Eleventh

ACM

Symposium

on

Operating

Systems

Principles

Austin

TX

-LRB-

USA

-RRB-

Operating

Systems

Review

Vol

pages

-LCB-

-LCB-

Novembre

Description

du

FS

Cedar

et

de

son

successeur

fiabilis?e

par

journalisation

des

m?etadonn?ees

-LSB-

Haskin

et

al.

-RSB-

Roger

Haskin

Yoni

Malachi

Wayne

Sawdon

Gregory

Chan

Recovery

Management

in

QuickSilver

Proceedings

of

the

Eleventh

ACM

Symposium

on

Operating

Systems

Principles

Austin

TX

-LRB-

USA

-RRB-

Operating

Systems

Review

Vol

pages

-LCB-

Novembre

Description

d'une

approche

de

recouvrement

originale

celle

de

QuickSilver

o?u

le

minimum

est

fait

par

le

syst?eme

et

le

reste

est

ecrit

par

l'usager

-LSB-

Heidemann

et

Popek

-RSB-

John

S.

Heidemann

Gerald

J.

Popek

A

Layered

Approach

to

File

System

Development

University

of

California

Los

Angeles

CA

-LRB-

USA

-RRB-

Technical

Report

Mars

D?ecomposition

en

couches

composables

des

diff?erentes

fonctions

d'un

syst?eme

de

fichiers

-LSB-

Hisgen

et

al.

-RSB-

Andy

Hisgen

Andrew

Birrel

Chuck

Jerian

Timothy

Mann

Michael

Schroeder

Garret

Swart

Granularity

and

Semantic

Level

of

Replication

in

the

Echo

Distributed

File

System

Proceedings

of

the

Workshop

on

the

Management

of

Replicated

Data

Houston

TX

-LRB-

USA

-RRB-

pages

-LCB-

-LCB-

Novembre

Utilise

des

RAIDs

-LSB-

Patterson

et

al.

-RSB-

multiconnect?es

fait

de

la

r?eplication

a

coh?erence

forte

avec

une

technique

utilisant

un

primaire

-LCB-

-LCB-

R?ef?erences

-LSB-

Holt

-RSB-

Richard

C.

Holt

Some

Deadlock

Properties

of

Computer

Systems

ACM

Computing

Surveys

Vol

pages

-LCB-

Septembre

Int?eressante

d?efinition

des

syst?emes

Algorithmes

de

d?etection

et

de

correction

d'interblocages

-LSB-

Hutchinson

et

Peterson

-RSB-

Norman

C.

Hutchinson

Larry

L.

Peterson

Design

of

the

x-Kernel

Proceedings

of

the

SIGCOMM

Symposium

Stanford

CA

-LRB-

USA

-RRB-

pages

-LCB-

Ao

ut

Encapsulation

des

diff?erentes

couches

de

communication

dans

des

objets

que

l'on

compose

-LSB-

Isis

-RSB-

Isis

Distributed

Systems

The

Isis

Distributed

Toolkit

Version

User

Reference

Manuel

Chapitre

Logging

and

spooling

Manuel

d'utilisation

et

de

programmation

du

service

de

journalisation

d'ISIS

-LSB-

Johnson

et

Zwaenepoel

-RSB-

David

B.

Johnson

Willy

Zwaenepoel

Sender-Based

Message

Logging

Proceedings

of

the

Seventeenth

Annual

International

Symposium

on

Fault-Tolerant

Computing

Pittsburgh

PA

-LRB-

USA

-RRB-

pages

-LCB-

-LCB-

juillet

R?eduction

des

surco

uts

en

fonctionnement

normal

mais

plus

grande

complexit?e

de

reprise

apr?es

panne

-LSB-

Johnson

et

Zwaenepoel

-RSB-

David

B.

Johnson

Willy

Zwaenepoel

Recovery

in

Distributed

Systems

Using

Optimistic

Message

Logging

and

Checkpointing

Proceedings

of

the

Seventh

Annual

ACM

Symposium

on

Principles

of

Distributed

Computing

Toronto

-LRB-

Canada

-RRB-

pages

-LCB-

Ao

ut

Une

m?ethode

optimiste

pour

la

reprise

apr?es

panne

bas?ee

sur

la

journalisation

de

message

et

le

calcul

d'

etat

global

coh?erent

-LSB-

Kane

-RSB-

Keneth

P.

Kane

Log-Based

Recovery

in

Asynchronous

Distributed

Systems

PhD

thesis

Cornell

University

Ithaca

NY

-LRB-

USA

-RRB-

Technical

Report

D?ecembre

M?ethode

de

recouvrement

d'Isis

bas?ee

sur

la

journalisation

de

messages

-LSB-

Kazar

et

al.

-RSB-

Michael

L.

Kazar

Bruce

W.

Leverett

Owen

T.

Anderson

Vasilis

Apostolides

Beth

A.

Bottos

Sailesh

Chutani

Craig

F.

Everhart

W.

Anthony

Mason

Shu-Tsui

Tu

Edward

R.

Zayas

DEcorum

File

System

Architectural

Overview

Proceedings

of

the

USENIX

Summer

Conference

Anaheim

CA

-LRB-

USA

-RRB-

-LCB-

juin

Journalise

les

m?eta

donn?ees

du

FS

par

un

m?ecanisme

transactionnel

R?eplication

paresseuse

limit?ee

aux

lectures

Coh?erence

de

cache

assur?ee

par

un

algorithme

de

jetons

-LSB-

Keleher

et

al.

-RSB-

Peter

Keleher

Alan

L.

Cox

Willy

Zwaenepoel

Lazy

Release

Consistency

for

Software

Distributed

Shared

Memory

Proceedings

of

the

ninenteenth

International

Symposium

on

Computing

Architectures

Gold

Cost

-LRB-

Australia

-RRB-

pages

-LCB-

May

Une

variante

plus

paresseuse

du

protocole

de

maintien

de

la

coh?erence

de

-LSB-

Gharachorloo

et

al.

-RSB-

-LSB-

King

et

Collmeyer

-RSB-

Paul

F.

King

Arthur

J.

Collmeyer

Database

sharing

-LCB-

An

efficient

mechanism

for

supporting

concurrent

processes

National

Computer

Conference

New

York

NY

-LRB-

USA

-RRB-

AFIPS

Conference

Proceedings

Vol

-LCB-

juin

Description

d'un

graphe

des

attentes

un

peu

particulier

et

d'une

m?ethode

de

d?etection

d'interblocages

-LSB-

Kisler

et

Satyanarayanan

-RSB-

James

J.

Kisler

M.

Satyanarayanan

Disconnected

Operation

in

the

Coda

File

System

Proceedings

of

the

thirteenth

ACM

Symposium

on

Operating

Systems

Principles

Pacific

Grove

CA

-LRB-

USA

-RRB-

Operating

Systems

Review

Vol

pages

-LCB-

-LCB-

octobre

La

m?ethode

du

syst?eme

de

fichier

Coda

pour

r?esister

a

la

d?econnexion

du

r?eseau

d'une

machine

-LCB-

-LCB-

R?ef?erences

-LSB-

Kumar

et

Satyanarayanan

-RSB-

Puneet

Kumar

M.

Satyanarayanan

Log-Based

Directory

Resolution

in

the

Coda

File

System

Carnegie-Mellon

University

Pittsburgh

PA

-LRB-

USA

-RRB-

Technical

Report

d?ecembre

Description

du

maintien

de

la

coh?erence

d'un

syst?eme

de

r?epertoires

r?eparti

a

la

suite

de

partitionnements

-LSB-

Lamport

et

al.

-RSB-

Leslie

Lamport

Robert

Shostak

Marshall

Pease

The

byzantyne

Generals

Problem

ACM

Transactions

on

Programming

Language

and

Systems

Vol

pages

-LCB-

Juillet

Une

s?erie

d'algorithmes

pour

la

r?esolution

du

probl?eme

des

g?en?eraux

byzantins

-LSB-

LeBlanc

et

Mellor-Crummey

-RSB-

Thomas

J.

LeBlanc

and

John

M.

Mellor-Crummey

Debugging

Parallel

Programs

with

Instant

Replay

IEEE

Transactions

on

Computers

Vol

pages

-LCB-

Avril

Description

d'un

d?ebogueur

qui

permet

de

rejouer

des

sessions

de

d?ebogage

-LSB-

LeBlanc

et

Robbins

-RSB-

Richard

J.

LeBlanc

Arnold

D.

Robbins

Event-Driven

Monitoring

of

Distributed

Programs

Proceedings

of

the

fifth

International

Conference

on

Distributed

Computing

Systems

Denver

CO

-LRB-

USA

-RRB-

pages

-LCB-

-LCB-

mai

Description

d'un

moniteur

de

programmes

r?epartis

Radar

coupl?e

a

un

language

Pronet

qui

permet

d'examiner

les

ev?enements

d'une

ex?ecution

parall?ele

pass?ee

-LSB-

Lindsay

et

al.

-RSB-

Bruce

G.

Lindsay

Laura

M.

Haas

C.

Mohan

Paul

F.

Wilms

Robert

A.

Yost

Computation

and

communication

in

R

A

distributed

database

Manager

ACM

Transactions

on

Computing

Systems

Vol

pages

-LCB-

F?evrier

Description

de

R

l'extension

r?epartie

de

syst?eme

R.

-LSB-

Liskov

et

al.

-RSB-

Barbara

Liskov

Dorothy

Curtis

Paul

Johnson

Robert

Scheifler

Implementation

of

Argus

ACM

Operating

Systems

Review

Vol

pages

-LCB-

Novembre

Description

tr?es

d?etaill?ee

d'Argus

-LSB-

Liskov

et

al.

-RSB-

B.

Liskov

S.

Ghemawat

R.

Gruber

P.

Johnson

L.

Shrira

M.

Williams

Replication

in

the

Harp

File

System

Massachusetts

Institut

of

Technology

Cambridge

MA

-LRB-

USA

-RRB-

Technical

Report

Ao

ut

Un

syst?eme

de

fichiers

r?esistant

aux

pannes

et

au

partitionnement

a

coh?erence

forte

-LSB-

Liskov

et

al.

-RSB-

Barbara

Liskov

Marc

Day

Liuba

Shrira

Distributed

Object

Management

in

Thor

Proceedings

of

the

International

Workshop

on

Distributed

Object

Management

Edmonton

-LRB-

Canada

-RRB-

pages

-LCB-

Ao

ut

Description

assez

g?en?erale

de

la

conception

du

syst?eme

Thor

-LSB-

Liskov

et

Scheifler

-RSB-

Barbara

Liskov

Robert

Scheifler

Guardians

and

Actions

Linguistic

Support

for

Robust

Distributed

Programs

ACM

Transactions

on

Programming

Language

and

Systems

Vol

pages

-LCB-

Juillet

Pr?esentation

g?en?erale

d'Argus

-LSB-

Liskov

et

Weihl

-RSB-

Barbara

Liskov

William

Weihl

Programming

Methodology

Group

Progress

Report

Massachusetts

Institute

of

Technology

Pittsburgh

PA

-LRB-

USA

-RRB-

Laboratory

for

Computer

Science

Programming

Methodology

Group

Memo

Ao

ut

Argus

applications

r?eparties

sur

Argus

et

une

etude

sur

la

disponibilit?e

due

a

la

duplication

d'informations

-LSB-

Lorie

-RSB-

Raymond

A.

Lorie

Physical

Integrity

in

a

Large

Segmented

Database

ACM

Transactions

on

Database

Systems

Vol

pages

-LCB-

Mars

Description

d?etaill?ee

du

m?ecanisme

des

pages-ombre

-LCB-

-LCB-

R?ef?erences

-LSB-

Makpangou

et

al.

-RSB-

Mesaac

Makpangou

Yvon

Gourhant

Marc

Shapiro

BOAR

A

Library

of

Fragmented

Object

Types

for

Distributed

Abstractions

Proceedings

of

the

International

Workshop

on

Object-Orientation

in

Operating

Systems

Palo

Alto

CA

-LRB-

USA

-RRB-

Octobre

Une

tr?es

courte

pr?esentation

de

BOAR

-LSB-

Mashburn

and

Satyanarayanan

-RSB-

Henry

H.

Mashburn

Mahadev

Satyanarayanan

RVM

Recoverable

Virtual

Memory

Carnegie-Mellon

University

Pittsburgh

PA

-LRB-

USA

-RRB-

non

publi?e

April

Description

d?etaill?ee

de

la

m?emoire

virtuelle

recouvrable

dans

Coda

-LSB-

Morris

et

al.

-RSB-

James

H.

Morris

Mahadev

Satyanarayanan

Michael

H.

Conner

John

H.

Howard

David

S.

Rosenthal

F.

Donelson

Smith

Andrew

a

Distributed

Personal

Computing

Environment

Communication

of

the

ACM

Vol

pages

-LCB-

Mars

Description

tr?es

d?etaill?ee

du

syst?eme

Andrew

-LSB-

Mullender

et

Schroeder

-RSB-

Sape

J.

Mullender

M.

D.

Schroeder

An

advanced

Course

on

Distributed

Computing

Chapitre

Introduction

Fingerlakes

authorized

preprint

edited

by

Sape

J.

Mullender

pages

-LCB-

Juillet

Une

introduction

aux

syst?emes

r?epartis

Tr?es

bonne

d?efinition

de

ceux-ci

-LSB-

Needham

-RSB-

Roger

M.

Needham

An

advanced

Course

on

Distributed

Computing

Chapitre

Using

Cryptography

for

Authentification

Fingerlakes

authorized

preprint

edited

by

Sape

J.

Mullender

pages

-LCB-

Juillet

Une

synth?ese

tr?es

claire

sur

les

techniques

de

cryptographie

-LSB-

Nelson

-RSB-

Bruce

J.

Nelson

Remote

Procedure

Call

PhD

thesis

Carnegie-Mellon

University

Pittsburgh

PA

-LRB-

USA

-RRB-

May

Tout

sur

les

RPC

-LSB-

Oki

et

al.

-RSB-

Brian

M.

Oki

Barbara

H.

Liskov

Robert

W.

Scheifler

Reliable

Object

Storage

to

Support

Atomic

Actions

Proceedings

of

the

Tenth

ACM

Symposium

on

Operating

Systems

Principles

Orcas

Island

WA

-LRB-

USA

-RRB-

Operating

Systems

Review

Vol

pages

-LCB-

-LCB-

D?ecembre

Gestion

du

stockage

d'objets

dans

Argus

algorithmes

pour

l'

ecriture

atomique

r?epartie

d'objets

en

stockage

fiable

-LSB-

Page

et

al.

-RSB-

Thomas

W.

Page

Jr.

Gerald

J.

Popek

Richard

G.

Guy

John

S.

Heidemann

The

Ficus

Distributed

File

System

Replication

via

Stackable

Layers

University

of

California

Los

Angeles

CA

-LRB-

USA

-RRB-

Technical

Report

Avril

G?en?ericit?e

et

r?eplication

dans

Ficus

-LSB-

Page

et

al.

-RSB-

Thomas

W.

Page

Jr.

Richard

G.

Guy

Gerald

J.

Popek

Architecture

of

the

Ficus

Scalable

Replicated

File

System

University

of

California

Los

Angeles

CA

-LRB-

USA

-RRB-

Technical

Report

Mars

Description

de

Ficus

un

syst?eme

de

fichiers

grande

echelle

fiable

et

en

parti

g?en?erique

-LSB-

Papadimitriou

-RSB-

Christos

H.

Papadimitriou

The

serialisability

of

Concurrent

Database

Updates

Journal

of

the

ACM

Vol

pages

-LCB-

Octobre

Etude

du

probl?eme

de

la

s?erialisabilit?e

proposition

d'un

formalisme

pour

le

contr

ole

de

concurrence

-LSB-

Parrington

et

Shrivastava

-RSB-

Graham

D.

Parrington

Santosh

K.

Shrivastava

Implementing

Concurrency

Control

in

Reliable

Distributed

Object-Oriented

Systems

Computing

Laboratory

University

of

Newcastle

upon

tyne

Newcasle

upon

tyne

-LRB-

UK

-RRB-

Comment

ecrire

en

C++

un

ensemble

de

classes

permettant

le

contr

ole

de

concurrence

par

verrouillage

-LCB-

-LCB-

R?ef?erences

-LSB-

Patterson

et

al.

-RSB-

David

A.

Patterson

Peter

Chen

Garth

Gibson

Randy

H.

Katz

Introduction

to

Redondant

Arrays

of

Inexpensive

Disks

-LRB-

RAID

-RRB-

IEEE

Intellectual

leverage

COMPCON

Spring

San

Francisco

CA

-LRB-

USA

-RRB-

pages

-LCB-

Description

des

RAIDs

activation

des

ecritures

sur

disques

par

leur

parall?elisation

sur

diff?erents

disques

et

r?eplication

-LSB-

Postel

-RSB-

J.

Postel

Internet

Protocol

DARPA

Internet

Program

Protocol

Specification

Request

For

Comments

Septembre

Description

officielle

du

protocole

IP

-LSB-

Postel

-RSB-

J.

Postel

Transmission

Control

Protocol

DARPA

Internet

Program

Protocol

Specification

Request

For

Comments

Septembre

Description

officielle

du

protocole

TCP

-LSB-

Powell

-RSB-

David

Powell

La

Tol?erance

aux

fautes

dans

les

Syst?emes

R?epartis

les

Hypoth?eses

d'erreur

et

leur

Importance

Actes

du

S?eminaire

Franco-Br

esilien

sur

les

Syst?emes

Informatiques

R?epartis

Florianopolis-SC

-LRB-

Br?esil

-RRB-

pages

-LCB-

LAAS

-LRB-

France

-RRB-

Rapport

de

Recherche

D?efinition

des

fautes

des

erreurs

et

des

d?efaillances

Taxonomie

des

erreurs

Etude

de

la

couverture

des

hypoth?eses

d'erreur

-LSB-

Powell

et

Presotto

-RSB-

Michael

L.

Powell

David

L.

Presotto

Publishing

A

reliable

Brodcast

Communication

Mechanism

Proceedings

of

the

Ninth

ACM

Symposium

on

Operating

Systems

Principles

BrettonWoods

Operating

Systems

Review

Vol

pages

-LCB-

-LCB-

octobre

Reprise

apr?es

panne

a

l'aide

de

la

journalisation

de

messages

d'une

mani?ere

transparente

aux

processus

-LSB-

Ritchie

-RSB-

Dennis

M.

Ritchie

A

stream

input-output

system

AT&T

Bell

Laboratories

Technical

Journal

Vol

pages

-LCB-

Octobre

Description

du

m?ecanisme

des

flots

d'Unix

System

V.

-LSB-

Rosenblum

et

Ousterhout

-RSB-

Mendel

Rosenblum

John

K.

Ousterhout

Design

and

Implementation

of

a

Log-structured

File

System

Proceedings

of

the

Thirteenth

ACM

Symposium

on

Operating

Systems

Principles

Pacific

Grove

CA

-LRB-

USA

-RRB-

Operating

Systems

Review

Vol

pages

-LCB-

-LCB-

octobre

Description

du

syst?eme

de

fichiers

de

Sprite

enti?erement

stock?e

sous

la

forme

d'un

journal

-LSB-

Rosenkrantz

et

al.

-RSB-

Daniel

J.

Rosenkrantz

Richard

E.

Stearns

Philip

M.

Lewis

II

System

Level

Concurrency

Control

for

Distributed

Database

Systems

ACM

Transactions

on

Database

Systems

Vol

pages

-LCB-

Juin

Deux

algorithmes

de

pr?evention

des

interblocages

Wait-Die

et

Wound-Wait

-LSB-

Rosenthal

-RSB-

David

S.

H.

Rosenthal

Evolving

the

Vnode

Interface

Proceedings

of

the

USENIX

Summer

Conference

Anaheim

CA

-LRB-

USA

-RRB-

pages

-LCB-

juin

Description

d'une

nouvelle

interface

de

Vnode

pour

un

syst?eme

de

fichiers

g?en?erique

-LSB-

Rozier

et

al.

-RSB-

Marc

Rozier

Vadim

Abrossimov

Fran?cois

Armand

Ivan

Boule

Michel

Gien

Marc

Guillemont

Fr?ed?eric

Herrmann

Claude

Kaiser

Sylvain

Langlois

Pierre

L?eonard

Willi

Neuhauser

Chorus

distributed

operating

systems

Chorus

Syst?emes

-LRB-

France

-RRB-

Technical

Report

Novembre

Description

d?etaill?ee

de

Chorus

-LSB-

Sandberg

et

al.

-RSB-

Russel

Sandberg

David

Goldberg

Steve

Kleiman

Dan

Walsh

Bob

Lyon

Design

and

implementation

of

the

Sun

Network

Filesystem

Sun

Microsystem

Technical

Report

Aussi

disponible

sous

le

nom

The

Sun

Network

Filesystem

-LCB-

-LCB-

R?ef?erences

Implementation

and

experience

Proceedings

of

the

Spring

Conference

of

European

Unix

Users

Group

Florence

-LRB-

Italy

-RRB-

pages

-LCB-

Avril

L'une

des

tr?es

rares

publications

sur

NFS

par

ses

concepteurs

d?ecrivant

sa

r?ealisation

-LSB-

Satyanarayanan

-RSB-

M.

Satyanarayanan

Integrating

Security

in

a

Large

Distributed

System

Carnegie-Mellon

University

Pittsburgh

PA

-LRB-

USA

-RRB-

Technical

Report

CMU

Novembre

L'aspect

s?ecurit?e

dans

le

syst?eme

r?eparti

Andrew

-LSB-

Satyanarayanan

et

al.

-RSB-

M.

Satyanarayanan

John

H.

Howard

David

A.

Nickols

Robert

Sidebotham

Alfred

Z.

Spector

Michael

J.

West

The

ITC

Distributed

File

System

Principles

and

Design

Proceedings

of

the

Tenth

ACM

Symposium

on

Operating

Systems

Principles

Orcas

Island

WA

-LRB-

USA

-RRB-

Operating

Systems

Review

Vol

pages

-LCB-

D?ecembre

Description

d'un

syst?eme

de

fichiers

a

grande

echelle

-LSB-

Satyanarayanan

et

al.

-RSB-

M.

Satyanarayanan

James

J.

Kistler

Puneet

Kumar

Hank

Mashburn

On

the

Ubiquity

of

Logging

in

Distributed

File

Systems

Proceedings

of

the

Third

Workshop

on

Workstation

Operating

Systems

Key

Biscayne

FL

-LRB-

USA

-RRB-

-LCB-

avril

Les

journaux

sont

indispensables

a

la

fiabilit?e

des

syst?emes

de

fichiers

l'exemple

de

Coda

-LSB-

Schlichting

et

Schneider

-RSB-

Rick

Schlichting

Fred

B.

Schneider

Fail-Stop

Processors

An

Approach

to

Designing

Fault-Tolerant

Computing

Systems

ACM

Transactions

on

Computing

Systems

Vol

pages

-LCB-

Ao

ut

La

definition

de

fail-stop

Une

methode

pour

approximer

des

processeurs

a

panne

franche

-LSB-

Schneider

-RSB-

Fred

B.

Schneider

Byzantine

Generals

in

Action

Implementing

FailStop

Processors

ACM

Transactions

on

Computing

Systems

Vol

pages

-LCB-

Mai

Description

d'une

m?ethode

moins

co

uteuse

que

-LSB-

Schlichting

et

Schneider

-RSB-

pour

approximer

des

processeurs

a

panne

franche

-LSB-

Shapiro

et

al.

-RSB-

Marc

Shapiro

Yvon

Gourhant

Sabine

Habert

Laurence

Mosseri

Michel

Ruffin

C?eline

Valot

SOS

An

Object-Oriented

Operating

System

Assessment

and

Perspectives

Computing

Systems

Vol

pages

-LCB-

D?ecembre

Un

bilan

complet

sur

le

syst?eme

d'exploitation

a

objet

SOS

-LSB-

Shrivastava

et

al.

-RSB-

S.

K.

Shrivastava

G.

N.

Dixon

G.

D.

Parrington

F.

Hedayati

S.

M.

Wheater

and

M.

C.

Little

The

Design

and

Implementation

of

Arjuna

University

of

Newcastle

upon

tyne

Newcasle

upon

tyne

-LRB-

UK

-RRB-

Technical

Report

Mars

Description

d'Arjuna

et

quelques

mesures

de

performance

-LSB-

Skeen

-RSB-

Dale

Skeen

Nonblocking

Commit

Protocols

Proceedings

of

the

ACM

SIGMOD

International

Conference

Ann

Arbor

MI

-LRB-

USA

-RRB-

pages

-LCB-

Juin

Validation

a

deux

et

trois

phases

-LRB-

non-bloquante

-RRB-

centralis?ee

ou

non

une

approche

formelle

-LSB-

Smith

-RSB-

Edward

T.

Smith

Debugging

Tools

for

Message-Based

Communicating

Processes

Proceedings

of

the

Fourth

International

Conference

on

Distributed

Systems

San

Francisco

CA

-LRB-

USA

-RRB-

pages

-LCB-

-LCB-

mai

Un

outil

assez

sophistiqu?e

pour

le

d?ebogage

multi-processus

li?e

a

un

mod?ele

d'ex

ecution

un

peu

particulier

-LSB-

Spector

-RSB-

Alfred

Z.

Spector

Distributed

Transaction

Processing

and

The

Camelot

System

Carnegie-Mellon

University

Pittsburgh

PA

-LRB-

USA

-RRB-

Technical

Report

CMU

Janvier

Rappel

sur

les

transactions

et

description

assez

d?etaill?ee

de

Camelot

-LCB-

-LCB-

R?ef?erences

-LSB-

Spector

et

al.

-RSB-

Alfred

Z.

Spector

Dean

Daniels

Daniel

Duchamp

Jeffrey

L.

Eppinger

Randy

Paush

Distributed

Transactions

for

Reliable

Systems

Proceedings

of

the

Tenth

ACM

Symposium

on

Operating

Systems

Principles

Orcas

Island

WA

-LRB-

USA

-RRB-

Operating

Systems

Review

Vol

pages

-LCB-

D?ecembre

Also

available

as

Carnegie-Mellon

University

Pittsburgh

PA

-LRB-

USA

-RRB-

Technical

Report

Septembre

Description

d?etaill?ee

de

TABS

et

mesures

de

performances

-LSB-

Strom

et

al.

-RSB-

Robert

E.

Strom

David

F.

Bacon

Shaula

A.

Yemini

Volatile

Logging

in

n-Fault-Tolerant

Distributed

Systems

Proceedings

of

the

Eighteenth

Annual

International

Symposium

on

Fault-Tolerant

Computing

Tokyo

-LRB-

Japan

-RRB-

pages

-LCB-

-LCB-

juin

Une

extention

de

-LSB-

Johnson

et

Zwaenepoel

-RSB-

aux

pannes

multiples

avec

un

assouplissement

de

la

journalisation

-LSB-

Strom

et

Yemini

-RSB-

Robert

E.

Strom

Shaula

Yemini

Optimistic

Recovery

in

Distributed

Systems

ACM

Transactions

on

Computing

Systems

Vol

pages

Ao

ut

Un

algorithme

optimiste

de

reprise

apr?es

panne

par

journalisation

de

messages

-LSB-

Stroustrup

-RSB-

Bjarne

Stroustrup

The

C++

Programming

Language

AddisonWesley

Publishing

Company

Premi?ere

edition

de

la

description

de

C++

-LSB-

Sun

Microsystems

Inc.

-RSB-

Sun

Microsystems

Inc.

XDR

External

Data

Representation

Standard

Request

For

Comments

Juin

Description

officielle

des

XDR

-LSB-

Sun

Microsystems

Inc.

-RSB-

Sun

Microsystems

Inc.

NFS

Network

File

System

Protocol

Specification

Request

For

Comments

Mars

Specifications

officielles

du

protocole

NFS

-LSB-

SunOS/RPC

-RSB-

Sun

microsystems

Network

Programming

Guide

Remote

Procedure

Call

Chapitre

RPC

Programming

Guide

Chapitre

RPC

Protocol

specification

Revision

A

mars

Description

du

protocole

RPC

et

de

son

mode

d'utilisation

sous

SunOS

-LSB-

SunOS/XDR

-RSB-

Sun

microsystems

Network

Programming

Guide

External

Data

Representation

Chapitre

XDR

Sun

Technical

Notes

Chapitre

XDR

Protocol

Specification

Revision

A

mars

Description

du

protocole

XDR

et

de

son

mode

d'utilisation

sous

SunOS

-LSB-

Verhofstad

-RSB-

Joost

S.

M.

Verhofstad

Recovery

Techniques

for

Database

Systems

ACM

Computing

Surveys

Vol

pages

-LCB-

Juin

Description

de

techniques

de

propagation

de

mises

a

jour

et

leurs

techniques

de

recouvrement

associ?ees

Ces

techniques

ne

sont

pas

orthogonales

mais

souvent

compl?ementaires

-LSB-

Walker

et

al.

-RSB-

Bruce

Walker

Gerald

Popek

Robert

English

Charles

Kline

Greg

Thiel

The

Locus

Distributed

Operation

System

Proceedings

of

the

Ninth

ACM

Symposium

on

Operating

Systems

Principles

Bretton

Woods

NH

-LRB-

USA

-RRB-

Operating

Systems

Review

Vol

pages

-LCB-

-LCB-

octobre

Aper?cu

de

Locus

mais

surtout

replication

partitionnement

r?econciliation

-LSB-

Weihl

-RSB-

William

E.

Weihl

Atomic

Data

Types

Massachusetts

Institut

of

Technology

Cambridge

MA

-LRB-

USA

-RRB-

Technical

Report

MIT-LCS

Article

assez

th?eorique

sur

l'atomicit

e

et

les

objets

-LCB-

-LCB-

R?esum?e

De

nombreuses

applications

utilisent

un

journal

pour

stocker

des

etats

soit

pour

refaire

des

actions

pass?ees

soit

pour

corriger

les

effets

de

pannes

d'erreurs

ou

de

pertes

de

coh?erence

dues

au

parall?elisme

Un

service

g?en?erique

de

journalisation

doit

s

adapter

aux

besoins

variables

voire

antagonistes

des

applications

sans

imposer

un

surco

ut

aux

applications

qui

n'utilisent

pas

toutes

ses

fonctions

KitLog

fournit

une

solution

originale

a

ce

probl?eme

en

d?ecomposant

et

en

encapsulant

les

diff?erentes

fonctions

de

la

journalisation

Cinq

principaux

m?ecanismes

sont

distingu?es

la

politique

de

gestion

des

tampons

la

distribution

d'enregistrements

leur

r?eplication

le

partage

du

journal

et

la

gestion

des

ressources

physiques

Chaque

m?ecanisme

est

repr?esent?e

par

une

classe

d'objet

Pour

chaque

classe

diff?erentes

r?ealisations

peuvent

etre

fournies

Les

instances

de

ces

classes

sont

composables

dans

n'importe

quel

ordre

appropri?e

et

en

n'importe

quel

nombre

Un

programmeur

d'applications

adapte

son

journal

logique

a

un

ensemble

d'hypoth

eses

de

pannes

en

choisissant

les

classes

ad?equates

en

les

instanciant

et

en

inter-connectant

les

instances

Mots-cl

es

Journalisation

service

g?en?erique

composition

d'objets

KitLog

Abstract

Many

applications

use

a

log

to

store

state

either

to

redo

past

actions

or

to

correct

possible

faults

errors

or

loss

of

consistency

A

generic

logging

service

should

cater

to

the

variable

and

even

antagonistic

needs

of

applications

without

imposing

overhead

on

applications

which

do

not

use

all

its

functions

KitLog

provides

an

original

solution

to

this

problem

by

decomposing

and

encapsulating

logging

functions

Five

main

mechanisms

are

distinguished

buffering

policy

distribution

of

records

replication

of

records

log

sharing

and

management

of

physical

media

Each

mechanism

is

embodied

in

an

object

class

For

each

class

multiple

policy

implementations

can

be

provided

Instances

of

these

classes

are

stackable

in

any

appropriate

number

or

order

An

application

programmer

customizes

his

logical

log

to

a

set

of

failure

assumptions

by

selecting

adequate

classes

instantiating

them

and

connecting

the

instances

together

generic service
log management
object composition