Correction

L'algorithme le plus simple pour minimiser les temps de recherche totaux dans une file
d'attente de disque est l'algorithme de SCAN (ou algorithme d'analyse).

Cet algorithme déplace la tête de lecture du disque du cylindre de départ dans une direction
donnée jusqu'à atteindre l'extrémité du disque, puis revient dans l'autre direction, traitant ainsi
toutes les requêtes sur son chemin.

Dans votre cas, avec la file d'attente suivante : 98, 183, 37, 122, 14, 124, 65, 67 et un cylindre
de départ à 53, voici comment l'algorithme SCAN serait appliqué :

1. Trier la file d'attente dans l'ordre croissant des numéros de cylindres : 14, 37, 65, 67, 98,
122, 124, 183.
2. Déterminer la direction de la recherche :
 La tête de lecture se déplace du cylindre de départ (53) vers le plus petit numéro de
cylindre (37).
3. Exécuter les requêtes dans l'ordre déterminé :
5337140656798122124183
4. Calculer le temps total de recherche.
 Somme des déplacements effectués.
S=|53-37|+|37-14|+|14-0|+|65-67|+|98-67|+||122-98|+|124-122|+|183-124|=
Notez que cet algorithme ne garantit pas le temps de recherche optimal dans tous les cas, mais
il offre une solution rapide et simple. D'autres algorithmes plus complexes, tels que
l'algorithme C-SCAN, peuvent être utilisés pour améliorer davantage les performances dans
certaines situations.

1. Taille minimale de bloc physique en Kioctets pour indexer tout l'espace disque :
Pour calculer la taille minimale de bloc physique en kilooctets (Ko) nécessaire pour indexer
tout l'espace disque, nous devons prendre en compte la taille maximale d'une partition FAT-
32. La taille maximale d'une partition FAT-32 est déterminée par le nombre maximal de
clusters que le système de fichiers peut gérer.

En FAT-32, la taille d'un cluster est fixée en fonction de la capacité de la partition. Voici les
étapes pour calculer la taille minimale de bloc physique en kilooctets :

Identifier la capacité maximale de la partition FAT-32 :

 Pour un disque dur de 256 Go, utilisez la formule suivante pour convertir la capacité
en mégaoctets (Mo) :
 256 Go = 256 * 1024 Mo.
 256Go×1024Mo/Go=256×1024Mo=262,144Mo
Trouver le nombre maximal de clusters que FAT-32 peut gérer :
 La taille maximale d'une partition FAT-32 est limitée par le nombre maximal de
clusters qu'elle peut adresser.
 Pour FAT-32, le nombre maximal de clusters est généralement 228_1.
2 −1≈268,435,455
28

Calculer la taille d'un cluster :

 Divisez la capacité maximale de la partition par le nombre maximal de clusters
pour obtenir la taille d'un cluster.
Taille d'un cluster (en Mo) : 262,144Mo/268,435,455≈0.9766Mo
Taille d'un cluster (en Ko) :
0.9766Mo×1024Ko/Mo≈999.76Ko

2. La taille minimale d'un fichier dans un système de fichiers FAT-32 est déterminée
par la taille d'un cluster, car les fichiers sont stockés par clusters. La taille minimale
d'un fichier est donc la taille d'un cluster.
3. Calcul de la taille totale de la table FAT en octets :
Taille totale de la table FAT=Nombre maximal de clusters×4 octets
Taille totale de la table FAT=268,435,455×4 octets≈1,073,741,820 octets
Convertir la taille totale de la table FAT en kilooctets :
Taille totale de la table FAT en Ko≈1,073,741,820 octets/1024≈1,048,574 Ko
Calculer le nombre de blocs nécessaires pour stocker la table FAT :
Nombre de blocs neˊcessaires≈1,048,574 Ko / 999.76 Ko/bloc≈1049 blocs

2. Calcul de la taille de la table de bits en octets :

Taille de la table de bits en octets=Nombre total de blocs/ 8

Ensuite, la taille de la table de bits en octets serait :

N/8=262,503/8 ≈32,813.875
 Cela signifie que la taille de la table de bits serait d'environ 32,813 octets et
nécessiterait environ 32.85 blocs, mais la taille de la table de bits doit toujours être
arrondie à l'entier supérieur pour être un nombre entier d'octets. Ainsi, la taille de la
table de bits en blocs serait probablement de 33 blocs.

Il est fortement déconseillé de formater un disque dur de 256 Go en FAT-16 avec des blocs
physiques de 32 kilooctets pour plusieurs raisons :

1. Taille maximale de la partition FAT-16 : FAT-16 est limité en termes de taille maximale de
partition qu'il peut gérer. Pour FAT-16, la taille maximale d'une partition est d'environ 4 Go.
Ainsi, un disque dur de 256 Go ne pourrait pas être pleinement exploité avec FAT-16, et une
grande partie de l'espace serait inutilisable.
2. Gaspillage d'espace disque : En utilisant des blocs physiques de 32 kilooctets, il y aurait un
gaspillage significatif d'espace disque. Des blocs plus grands signifient qu'un fichier occupe
au moins la taille d'un bloc, même s'il n'utilise qu'une petite partie de cet espace. Cela
entraînerait un gaspillage d'espace considérable, ce qui n'est pas efficace.
3. Inefficacité dans la gestion des petits fichiers : FAT-16 avec des blocs de 32 Ko serait
inefficace pour stocker de petits fichiers. Les petits fichiers qui n'occupent qu'une fraction de
la taille d'un bloc entraîneraient une utilisation inefficace de l'espace disque.
4. Performances : Des blocs plus grands peuvent également entraîner des problèmes de
performances, en particulier lorsque vous travaillez avec de petits fichiers ou lorsque le
système de fichiers est fragmenté. La gestion des fichiers devient moins efficace, et le temps
d'accès aux fichiers peut augmenter.
5. Compatibilité : FAT-16 est un système de fichiers ancien et obsolète, et de nombreux
systèmes d'exploitation modernes ne le prennent pas en charge correctement. Il serait plus
judicieux d'utiliser un système de fichiers plus récent et plus performant, comme FAT-32,
exFAT ou NTFS, en fonction des besoins spécifiques.

En résumé, le formatage d'un disque dur de 256 Go en FAT-16 avec des blocs physiques de
32 kilooctets serait inefficace, gaspillerait de l'espace disque et entraînerait des problèmes de
performances. Il est recommandé d'utiliser un système de fichiers plus moderne et mieux
adapté à la capacité du disque dur.
 La taille minimale d'un fichier sous Unix dépend de la façon dont l'i-node est utilisé pour
stocker les données du fichier. Les différentes parties de la structure i-node, à savoir les
pointeurs directs, le pointeur indirect simple, le pointeur indirect double et le pointeur indirect
triple, peuvent être utilisées pour référencer les blocs de données du fichier.

Supposons que chaque pointeur dans la structure i-node pointe vers un bloc de 512 octets, et
la taille d'un index est de 4 octets. Voici comment vous pourriez calculer la taille minimale
d'un fichier :

1. Pointeurs directs : Il y a 10 pointeurs directs, chacun pointant vers un bloc de données.

Donc, la taille directe maximale serait 10×512octets.
2. Pointeur indirect simple : Le pointeur indirect simple peut pointer vers un bloc contenant
des pointeurs directs supplémentaires. Donc, il peut y avoir 512/4=128pointeurs directs
supplémentaires, ce qui donne une taille maximale de 128×512octets.
3. Pointeur indirect double : Le pointeur indirect double peut pointer vers des blocs contenant
des pointeurs indirects simples. Ainsi, il peut y avoir 512/4blocs de pointeurs indirects
simples supplémentaires, ce qui donne une taille maximale de 128×128×512octets.
4. Pointeur indirect triple : Le pointeur indirect triple peut pointer vers des blocs contenant des
pointeurs indirects doubles. Par conséquent, il peut y avoir 512/4=128blocs de pointeurs
indirects doubles supplémentaires, ce qui donne une taille maximale de
128×128×128×512octets.

Taille minimale du fichier (pointeurs directs) :

Taille minimale du fichier=Nombre de pointeurs directs×Taille d’un blocTaille minimale du =
10×512
Taille minimale du fichier=5120 octets
Cette formule représente la taille minimale d'un fichier, où les premières données du fichier
peuvent être directement référencées à partir des 10 pointeurs directs dans la structure i-node.
Taille maximale du fichier=(Nombre de pointeurs directs+Nombre de pointe
urs indirects simples+Nombre de pointeurs indirects doubles+Nombre de po
inteurs indirects triples)×Taille d’un bloc
 Td

a) Diagrammes de Gantt :

 Instant t=0 :
 CPU1 exécute A (4 unités de CPU) [0, A, 4]
 CPU2 attend
 Instant t=4 :
 A demande une E/S (2 unités d'E/S)
 CPU1 exécute B (3 unités de CPU) [4, B, 3]
 CPU2 attend
 Instant t=7 :
  Fin du quantum pour CPU1
 B en attente de CPU
 CPU2 exécute A (1 unité de CPU) [7, A, 1]
 Instant t=8 :
 A en attente d'E/S
 CPU2 exécute A (2 unités de CPU) [8, A, 2]
 Instant t=10 :
 Fin de l'E/S pour A
 A en attente de CPU
 CPU2 exécute B (1 unité de CPU) [10, B, 1]
 Instant t=11 :
 Fin de la CPU pour B
 B en attente d'E/S
 CPU1 exécute C (3 unités de CPU) [11, C, 3]
 Instant t=14 :
 Fin du quantum pour CPU2
 C en attente de CPU
 CPU1 exécute B (2 unités de CPU) [14, B, 2]
 Instant t=16 :
 Fin de la CPU pour B
 B en attente d'E/S
 CPU2 exécute C (1 unité de CPU) [16, C, 1]
 Instant t=17 :
 Fin de la CPU pour C
 C en attente d'E/S
 CPU1 exécute B (1 unité de CPU) [17, B, 1]
 Instant t=18 :
 Fin de la CPU pour B
 B en attente d'E/S
 CPU2 attend
 Instant t=21 :
 Fin de la CPU pour A
 A en attente de CPU
 CPU1 exécute C (3 unités de CPU) [21, C, 3]
 Instant t=24 :
 Fin de la CPU pour C
 C en attente d'E/S
 CPU2 exécute A (1 unité de CPU) [24, A, 1]
 Instant t=25 :
 Fin de la CPU pour A
 A en attente d'E/S
 CPU2 exécute C (2 unités de CPU) [25, C, 2]
 Instant t=27.5 :
 Fin de la CPU pour C
 C en attente d'E/S
 CPU1 exécute A (1 unité de CPU) [27.5, A, 1]
 Instant t=28.5 :
 Fin de la CPU pour A
 A en attente d'E/S
 CPU2 attend
 b) Calcul du temps moyen de virement (temps moyen de séjour) :
Temps moyen de virement=Temps total passeˊ dans le systeˋmeNombre total de processusTemps mo
yen de virement=Nombre total de processusTemps total passeˊ dans le systeˋme

Temps total passé dans le système :

 A : 4+1+2+1+1=94+1+2+1+1=9 unités de temps

 B : 3+1+2+1+1=83+1+2+1+1=8 unités de temps
 C : 3+1+2+3+1+2=123+1+2+3+1+2=12 unités de temps

Nombre total de processus : 3

Temps moyen de virement :

Temps moyen de virement=9+8+123=293≈9.67 uniteˊs de tempsTemps moyen de virement=39+8+12
=329≈9.67 uniteˊs de temps

Le temps moyen de virement est d'environ 9.67 unités de temps.

1. Diagrammes de Gantt :

a) Threads supportés par le noyau avec l'algorithme du tourniquet :

 Instant t=0 :
 T11 (1 unité de CPU)
 T12 (2 unités de CPU) [0, T11, 1]
 Instant t=3 :
 T21 (2 unités de CPU) [3, T12, 2]
 T22 (2 unités de CPU)
 Instant t=5 :
 T23 (1 unité de CPU) [5, T21, 2]
 T11 (1 unité de CPU)

b) Threads implémentés au niveau utilisateur avec l'algorithme du tourniquet :

 Instant t=0 :
 T11 (1 unité de CPU)
 T21 (1 unité de CPU) [0, T11, 1]
 Instant t=2 :
 T12 (2 unités de CPU) [2, T21, 1]
 T22 (1 unité de CPU)
 Instant t=4 :
 T23 (1 unité de CPU) [4, T12, 2]
 T11 (1 unité de CPU)
2. Calcul du temps de virement (temps de séjour) pour chaque processus :

a) Threads supportés par le noyau avec l'algorithme du tourniquet :

 Temps de virement pour P1 : 1+2+1=41+2+1=4 unités de temps
 Temps de virement pour P2 : 2+2+1=52+2+1=5 unités de temps

b) Threads implémentés au niveau utilisateur avec l'algorithme du tourniquet :

 Temps de virement pour P1 : 1+2+1=41+2+1=4 unités de temps

 Temps de virement pour P2 : 1+1+2+1=51+1+2+1=5 unités de temps

Comparaison et commentaires : Les temps de virement pour P1 sont les mêmes dans les deux cas,
mais pour P2, le temps de virement est légèrement plus élevé dans le cas b) où les threads sont
implémentés au niveau utilisateur. Cela peut s'expliquer par le fait que dans le cas a), un thread d'un
processus peut céder son quantum non utilisé à un thread d'un autre processus, tandis que dans le
cas b), le quantum non utilisé reste au niveau du processus même si d'autres threads du même
processus pourraient l'utiliser. En d'autres termes, l'algorithme du tourniquet au niveau utilisateur
peut entraîner une utilisation suboptimale des ressources par rapport à celui du noyau.

Pour le premier problème avec l'ordonnanceur à priorité préemptive :

Le temps d'attente pour un processus dans un ordonnanceur à priorité préemptive est la somme des
temps pendant lesquels le processus est en attente avant son exécution. On peut calculer cela en
utilisant la formule : Temps d'attente = Temps d'exécution total - Temps d'exécution du processus.

Calculons le temps d'attente pour le processus P1 :

 Temps d'exécution total : 11 (Pl) + 5 (P2) + 28 (P3) + 12 (P4) + 16 (P5) = 72
 Temps d'exécution du processus P1 : 11 (Pl)

Temps d'attente de P1 = 72 - 11 = 61

Donc, le temps d'attente pour le processus P1 est de 61 unités de temps.

Pour le deuxième problème avec l'ordonnancement SRTF (Shortest Remaining Time First) :

Les processus arrivent aux instants 0, 2, et 6, et ont des temps d'exécution de 10, 20, et 30 unités,
respectivement.

L'ordonnancement SRTF choisit le processus avec le temps d'exécution restant le plus court. Voici
comment cela se déroule :

 À t=0, le processus P1 (10 unités) est en cours d'exécution.

 À t=2, le processus P2 (20 unités) arrive, mais P1 a un temps restant plus court, donc pas de
changement de contexte.
 À t=6, le processus P3 (30 unités) arrive, et P1 a un temps restant plus court, donc pas de
changement de contexte.
 À t=10, P1 termine son exécution, et le processus P2 est choisi.
 À t=22, P2 termine son exécution, et le processus P3 est choisi.

Ainsi, 2 changements de contexte sont nécessaires.

Pour le troisième problème avec l'ordonnancement LRTF (Longest Remaining Time First) :

Les processus ont des temps d'exécution de 2, 4, et 8 unités, respectivement. Les processus arrivent
tous à t=0.

 À t=0, le processus P2 (4 unités) est choisi.

 À t=4, le processus P1 (2 unités) arrive, mais P2 a un temps restant plus long, donc pas de
changement de contexte.
 À t=6, le processus P3 (8 unités) arrive, et P2 a un temps restant plus court, donc le changement de
contexte se produit.
 À t=14, P2 termine son exécution, et P3 est choisi.
 À t=22, P3 termine son exécution, et P1 est choisi.

Le temps total d'exécution est de 22 unités. Le temps moyen d'exécution est donc de 22/3 = 7.33
unités de temps.

Pour récapituler :

1. Temps d'attente pour P1 dans l'ordonnanceur à priorité préemptive : 61 unités de temps.

2. Changements de contexte nécessaires avec SRTF : 2.
3. Temps moyen d'exécution avec LRTF : 7.33 unités de temps.
 a) Diagrammes de Gantt :

 Instant t=0 :
 CPU 1 exécute A (4 unités de CPU) [0, A, 4]
 CPU 2 attend
 File d'attente des processus prêts : vide
 File d'attente des processus en attente de l'unité d'E/S : vide
 Instant t=4 :
 A demande une E/S (2 unités d'E/S)
 CPU 1 exécute B (3 unités de CPU) [4, B, 7]
 CPU 2 attend
 File d'attente des processus prêts : A
 File d'attente des processus en attente de l'unité d'E/S : vide
 Instant t=7 :
 Fin du quantum pour CPU 1
 B en attente de CPU
 CPU 2 exécute A (1 unité de CPU) [7, A, 8]
 File d'attente des processus prêts : B
 File d'attente des processus en attente de l'unité d'E/S : vide
 Instant t=8 :
 A en attente d'E/S
 CPU 2 exécute B (2 unités de CPU) [8, B, 10]
 File d'attente des processus prêts : vide
  File d'attente des processus en attente de l'unité d'E/S : A
 Instant t=10 :
 Fin de l'E/S pour A
 A en attente de CPU
 CPU 2 exécute B (1 unité de CPU) [10, B, 11]
 File d'attente des processus prêts : A
 File d'attente des processus en attente de l'unité d'E/S : vide
 Instant t=11 :
 Fin de la CPU pour B
 B en attente d'E/S
 CPU 1 exécute C (3 unités de CPU) [11, C, 14]
 File d'attente des processus prêts : A
 File d'attente des processus en attente de l'unité d'E/S : B
 Instant t=14 :
 Fin du quantum pour CPU 2
 C en attente de CPU
 CPU 1 exécute A (3 unités de CPU) [14, A, 17]
 File d'attente des processus prêts : B
 File d'attente des processus en attente de l'unité d'E/S : C
 Instant t=17 :
 Fin de la CPU pour A
 A en attente d'E/S
 CPU 1 exécute B (2 unités de CPU) [17, B, 19]
 File d'attente des processus prêts : C
 File d'attente des processus en attente de l'unité d'E/S : A
 Instant t=19 :
 Fin de la CPU pour B
 B en attente d'E/S
 CPU 2 exécute C (1 unité de CPU) [19, C, 20]
 File d'attente des processus prêts : A
 File d'attente des processus en attente de l'unité d'E/S : B
 Instant t=20 :
 Fin de la CPU pour C
 C en attente d'E/S
 CPU 1 exécute A (1 unité de CPU) [20, A, 21]
 File d'attente des processus prêts : B
 File d'attente des processus en attente de l'unité d'E/S : C
 Instant t=21 :
 Fin de la CPU pour A
 A en attente d'E/S
 CPU 2 attend
 File d'attente des processus prêts : B
 File d'attente des processus en attente de l'unité d'E/S : C, A
 Instant t=28 :
 Fin de la CPU pour C
 C en attente d'E/S
 CPU 2 exécute B (1 unité de CPU) [28, B, 29]
 File d'attente des processus prêts : A
 File d'attente des processus en attente de l'unité d'E/S : C
 Instant t=29 :
 Fin de la CPU pour B
 B en attente d'E/S
 CPU 1 exécute A (1 unité de CPU) [29, A, 30]
 File d'attente des processus prêts : C
 File d'attente des processus en attente de l'unité d'E/S : B

b) Calcul du temps moyen de virement (temps moyen de séjour) :

Le temps de virement pour chaque processus est la somme des temps passés dans le
système (temps d'attente + temps d'exécution). Le temps moyen de virement est la
moyenne de ces temps pour tous les processus.

 Temps de virement pour A : 17+4=2117+4=21 unités de temps

 Temps de virement pour B : 11+4+3=1811+4+3=18 unités de temps
 Temps de virement pour C : 7+4+6=177+4+6=17 unités de temps

Temps moyen de virement :

Temps moyen de virement=21+18+173=563≈18.67 uniteˊs de tempsTemps
moyen de virement=321+18+17=356≈18.67 uniteˊs de temps

Donc, le temps moyen de virement est d'en

1. La priorité d'un processus est inversement proportionnelle à sa période dans
l'algorithme RMS afin de donner une priorité plus élevée aux tâches ayant des
périodes plus courtes. Cela garantit que les tâches avec des contraintes temporelles
plus strictes (périodes plus courtes) sont traitées en priorité, ce qui aide à respecter
les échéances et à garantir le bon fonctionnement du système temps-réel.
2. Les priorités des processus A, B et C selon l'algorithme RMS sont déterminées en
utilisant la formule de priorité RMS : Prioriteˊ=1PeˊriodePrioriteˊ=Peˊriode1.
 Priorité(A) = 129291
 Priorité(B) = 1551
 Priorité(C) = 110101
3. Diagramme de Gantt pour les 30 premières unités de temps d'ordonnancement RMS,
préemptif :
 Diagramme de Gantt pour les 30 premières unités de temps d'ordonnancement RMS, non
préemptif :

1. Dans le cas RMS préemptif, tous les processus respectent leurs contraintes
temporelles sur les 30 premières millisecondes. Cela est dû au respect de
l'ordre de priorité basé sur les périodes, garantissant que les tâches à période
plus courte sont traitées en premier.
2. Dans le cas RMS non préemptif, tous les processus respectent également leurs
contraintes temporelles sur les 30 premières millisecondes. Cependant, cela est
assuré par la nature non préemptive de l'algorithme, où chaque tâche est
exécutée dans son intégralité sans interruption, ce qui garantit que chaque
tâche termine avant le début de la tâche suivante.

a) Diagrammes de Gantt :
 Instant t=0 :
 CPU 1 exécute A (4 unités de CPU) [0, A, 4]
 CPU 2 attend
 File d'attente des processus prêts : vide
 File d'attente des processus en attente de l'unité d'E/S : vide
 Instant t=4 :
 A demande une E/S (2 unités d'E/S)
 CPU 1 exécute B (3 unités de CPU) [4, B, 7]
 CPU 2 attend
 File d'attente des processus prêts : A
 File d'attente des processus en attente de l'unité d'E/S : vide
 Instant t=7 :
 Fin du quantum pour CPU 1
 B en attente de CPU
 CPU 2 exécute A (1 unité de CPU) [7, A, 8]
 File d'attente des processus prêts : B
 File d'attente des processus en attente de l'unité d'E/S : vide
 Instant t=8 :
 A en attente d'E/S
 CPU 2 exécute B (2 unités de CPU) [8, B, 10]
 File d'attente des processus prêts : vide
 File d'attente des processus en attente de l'unité d'E/S : A
 Instant t=10 :
 Fin de l'E/S pour A
 A en attente de CPU
 CPU 2 exécute B (1 unité de CPU) [10, B, 11]
 File d'attente des processus prêts : A
 File d'attente des processus en attente de l'unité d'E/S : vide
 Instant t=11 :
 Fin de la CPU pour B
 B en attente d'E/S
 CPU 1 exécute C (3 unités de CPU) [11, C, 14]
 File d'attente des processus prêts : A
 File d'attente des processus en attente de l'unité d'E/S : B
 Instant t=14 :
 Fin du quantum pour CPU 2
 C en attente de CPU
 CPU 1 exécute A (3 unités de CPU) [14, A, 17]
 File d'attente des processus prêts : B
 File d'attente des processus en attente de l'unité d'E/S : C
 Instant t=17 :
 Fin de la CPU pour A
 A en attente d'E/S
  CPU 1 exécute B (2 unités de CPU) [17, B, 19]
 File d'attente des processus prêts : C
 File d'attente des processus en attente de l'unité d'E/S : A
 Instant t=19 :
 Fin de la CPU pour B
 B en attente d'E/S
 CPU 2 exécute C (1 unité de CPU) [19, C, 20]
 File d'attente des processus prêts : A
 File d'attente des processus en attente de l'unité d'E/S : B
 Instant t=20 :
 Fin de la CPU pour C
 C en attente d'E/S
 CPU 1 exécute A (1 unité de CPU) [20, A, 21]
 File d'attente des processus prêts : B
 File d'attente des processus en attente de l'unité d'E/S : C
 Instant t=21 :
 Fin de la CPU pour A
 A en attente d'E/S
 CPU 2 attend
 File d'attente des processus prêts : B
 File d'attente des processus en attente de l'unité d'E/S : C, A
 Instant t=28 :
 Fin de la CPU pour C
 C en attente d'E/S
 CPU 2 exécute B (1 unité de CPU) [28, B, 29]
 File d'attente des processus prêts : A
 File d'attente des processus en attente de l'unité d'E/S : C
 Instant t=29 :
 Fin de la CPU pour B
 TD SGF

Pour calculer le temps total de traitement et le nombre moyen de pistes par

accès pour les différentes politiques d'ordonnancement de requêtes, nous devons
simuler le mouvement de la tête de lecture/écriture sur le disque pour chaque
politique. Les politiques examinées sont :

1. FCFS (First-Come, First-Served)

2. SSTF (Shortest Seek Time First)
3. SCAN
4. C-SCAN (Circular SCAN)
5. C-LOOK (Circular LOOK)

On suppose que chaque déplacement de la tête d'une piste à l'autre prend 1 unité de
temps.

Calculs :

1. FCFS (First-Come, First-Served):

 Temps total de traitement :
∣53−98∣+∣98−183∣+∣183−37∣+∣37−122∣+∣122−14∣+∣14−124∣+∣124−65∣
+∣65−67∣∣53−98∣+∣98−183∣+∣183−37∣+∣37−122∣+∣122−14∣+∣14−124∣+
∣124−65∣+∣65−67∣
Nombre moyen de pistes par accès : Moyenne des déplacements entre chaque
paire consécutive.
2. SSTF (Shortest Seek Time First):
  Choix de la prochaine requête en fonction de la distance de recherche la plus
courte à partir de la tête actuelle.
 Calcul similaire à FCFS.
3. SCAN:
 La tête se déplace vers l'extrémité du disque en cours, puis rebondit.
 Calcul similaire à FCFS.
4. C-SCAN (Circular SCAN):
 La tête se déplace vers l'extrémité du disque, puis revient à l'extrémité
opposée sans rebond.
 Calcul similaire à FCFS.
5. C-LOOK (Circular LOOK):
 La tête se déplace vers l'extrémité du disque en cours, puis revient sans
rebond.
 Calcul similaire à FCFS.

Pour effectuer les calculs précis, nous devons simuler chaque politique en détail. Les
distances entre les requêtes adjacentes sont utilisées pour calculer les temps de
déplacement. Après simulation, nous pouvons calculer le temps total de traitement et
le nombre moyen de pistes par accès pour chaque politique. Si vous souhaitez que je
simule ces politiques en détail, veuillez le spécifier.

1) Taille minimale de bloc physique en Kilooctets pour indexer tout

l'espace disque (pour FAT-32) :

Le système de fichiers FAT-32 utilise une table d'allocation de fichiers (FAT)

pour suivre l'utilisation de l'espace disque. La taille minimale d'un bloc
physique dépend du nombre de clusters nécessaires pour indexer tout
l'espace disque.
La taille d'un cluster (ou bloc) est déterminée par le nombre total de clusters
(blocs) nécessaires pour indexer la capacité totale du disque. Pour FAT-32,
le nombre maximal de clusters est de 228228 (268 435 456), car chaque
entrée de la FAT est de 32 bits (4 octets) et il y a deux entrées par cluster.

Donc, la taille minimale d'un bloc physique (cluster) est calculée comme suit
:

Taille minimale d’un cluster=Capaciteˊ totale du disqueNombre ma

ximal de clustersTaille minimale d’un cluster=Nombre maximal de clustersC
apaciteˊ totale du disque

Taille minimale d’un cluster=256 Go×1024 Mo/Go×1024

Ko/Mo228Taille minimale d’un cluster=228256Go×1024Mo/Go×1024Ko/Mo

2) Taille minimale d'un fichier dans un tel système :

La taille minimale d'un fichier dépend de la taille d'un cluster, car l'espace
disque est alloué par clusters. La taille minimale d'un fichier est égale à la
taille d'un cluster.

3) Nombre de blocs nécessaires pour stocker la table FAT sur le disque

(pour FAT-32) :

Le nombre de blocs nécessaires pour stocker la table FAT dépend de la

taille de la table et de la taille d'un cluster. La table FAT stocke les
informations d'allocation de chaque cluster.

4) Taille de la table de bits (bitmap) en blocs :

La taille de la table de bits (bitmap) dépend également de la taille d'un

cluster, car chaque bit dans la table de bits représente un cluster. La taille de
la table de bits est donc égale au nombre total de clusters divisé par le
nombre de bits par octet (8).

Taille de la table de bits=Nombre total de clusters8Taille de la table

de bits=8Nombre total de clusters

5) Formatage en FAT-16 avec des blocs physiques de 32 Kilooctets :

 Le formatage en FAT-16 avec des blocs physiques de 32 Kilooctets est
fortement déconseillé car FAT-16 a des limitations, notamment en termes
de taille maximale de partition et de taille maximale de fichier. FAT-16 ne
peut gérer que des partitions jusqu'à 4 Go et des fichiers jusqu'à 2 Go. En
choisissant des blocs physiques de 32 Ko, le nombre de clusters augmente,
ce qui peut dépasser les limites de FAT-16, rendant une partie du disque
inaccessible ou limitant la taille des fichiers. Il est préférable d'utiliser FAT-32
pour tirer pleinement parti de la capacité du disque dur de 256 Go.

Pour répondre à ces questions, nous devons comprendre comment fonctionne la

structure d'un i-node sous Unix.

Un i-node (index node) est une structure de données qui contient des métadonnées
sur un fichier particulier. Ces métadonnées comprennent des informations telles que
les permissions du fichier, le propriétaire, la taille, les timestamps, les pointeurs vers
les blocs de données, etc.

La taille minimale et maximale d'un fichier dépendent de la manière dont les blocs de
données sont organisés et de la taille de chaque bloc.

Données fournies :

 Taille d'un bloc : 512 octets

 Taille d'un index : 4 octets

Calculs :

1) Taille minimale d'un fichier : La taille minimale d'un fichier est déterminée par la
taille d'un bloc, car même le fichier le plus petit doit occuper au moins un bloc. La
taille minimale d'un fichier est donc égale à la taille d'un bloc.

En nombre de blocs : 11 En octets : 512512 octets

2) Taille maximale d'un fichier : La taille maximale d'un fichier dépend du nombre
d'adresses d'index que le i-node peut contenir et de la taille d'un bloc.
 Taille d'un index : 44 octets
 Taille d'une adresse d'index : Taille d’un index8=48=0.58Taille d’un index=84=0.5
octets (car un index est généralement une adresse de 4 octets)
 Nombre d'adresses d'index dans un bloc :
Taille d’un blocTaille d’une adresse d’index=5120.5=1024Taille d’une adresse d’inde
xTaille d’un bloc=0.5512=1024 adresses d'index par bloc

Chaque adresse d'index peut pointer vers un autre bloc de données. Par conséquent,
la taille maximale d'un fichier est obtenue en multipliant le nombre maximal
d'adresses d'index dans un bloc par la taille d'un bloc.

En nombre de blocs : 10241024 En octets : 1024×5121024×512 octets

Note : Ces calculs supposent un index simple. Si l'i-node utilise des indices indirects
doubles ou triples, la taille maximale du fichier serait plus grande, mais cela dépend
de la mise en œuvre spécifique du système de fichiers Unix.

Dans le scénario décrit, où une copie de la table de bits est maintenue en mémoire
centrale et périodiquement mise à jour sur le disque, la question de la récupération
du contenu de la table de bits après une panne du système dépend de la manière
dont les mises à jour sont gérées.

Si le système d'exploitation suit une approche où chaque mise à jour de la table de

bits en mémoire centrale est immédiatement écrite sur le disque après la
modification, alors en cas de panne du système avant la dernière écriture sur disque,
il sera possible de récupérer le contenu de la table de bits. Cela est dû au fait que
chaque mise à jour est effectuée de manière atomique, et une copie cohérente de la
table de bits est présente sur le disque à chaque instant d'écriture.
Cependant, si le système d'exploitation utilise un mécanisme de mise en mémoire
tampon (buffering) où les mises à jour de la table de bits en mémoire centrale sont
accumulées dans une mémoire tampon avant d'être écrites sur le disque, alors une
panne du système avant la dernière écriture sur disque pourrait entraîner une perte
de données.

Dans le deuxième cas, la mémoire tampon pourrait contenir des mises à jour qui
n'ont pas encore été écrites sur le disque, et ces mises à jour pourraient être perdues
en cas de panne du système. Cela entraînerait une incohérence entre la copie en
mémoire centrale et la copie sur disque de la table de bits.

En résumé, la récupération du contenu de la table de bits après une panne dépend

de la politique d'écriture utilisée par le système d'exploitation. Si les mises à jour sont
immédiatement écrites sur le disque, la récupération est possible. Si les mises à jour
sont accumulées dans une mémoire tampon, il pourrait y avoir une perte de données
en cas de panne.
 1. Fragmentation interne totale :

La fragmentation interne est le gaspillage d'espace disque causé par l'occupation

partielle du dernier bloc utilisé par un fichier. Dans le cas de ce système de fichiers
Unix, examinons comment l'image couleur de résolution 1024×7681024×768 avec
des pixels codés sur 32 bits serait stockée.

La taille d'un bloc est de 1 Kilooctet, ce qui équivaut à 1024 octets.

La taille de l'image en octets serait : 1024×768×321024×768×32 bits ==

1024×768×41024×768×4 octets

Maintenant, divisons la taille totale par la taille d'un bloc pour obtenir le nombre total
de blocs nécessaires.

Nombre total de blocs neˊcessaires=Taille totale de l’imageTaille d’un blocN

ombre total de blocs neˊcessaires=Taille d’un blocTaille totale de l’image

La fragmentation interne totale serait le reste du dernier bloc utilisé. Illustrons cela
par un exemple numérique :

Taille totale de l’image=1024×768×4 octetsTaille totale de l’imag

e=1024×768×4octets Taille d’un bloc=1024
octetsTaille d’un bloc=1024octets

Nombre total de blocs neˊcessaires=1024×768×41024=3072 blocsNombre tot

al de blocs neˊcessaires=10241024×768×4=3072blocs

Cependant, l'image pourrait ne pas parfaitement occuper un nombre entier de blocs.

Supposons que cela occupe 30723072 blocs et qu'il reste 512512 octets dans le
dernier bloc non utilisé, ce qui représente la fragmentation interne.

2. Tailles minimale et maximale pour un fichier de 92 blocs de liens :

Le fichier est représenté par l'i-noeud, qui a 1010 liens directs, 11 lien indirect
simple, 11 lien indirect double, et 11 lien indirect triple.

 Taille minimale possible : Si les 9292 blocs nécessaires pour représenter le fichier
peuvent tous être référencés par les liens directs, alors la taille minimale est 9292
blocs.
 Taille maximale possible : Si tous les liens directs sont utilisés, et que l'on atteint le
lien indirect triple, on peut avoir
10+1024+1024×1024+1024×1024×102410+1024+1024×1024+1024×1024×
 1024 blocs (les 10241024 représentent le nombre de blocs que chaque niveau
d'indirection peut adresser).

Ces valeurs dépendent de la manière dont les liens sont utilisés, mais l'illustration des
liens peut aider à visualiser ces concepts.

Pour déterminer la taille maximale possible d'un fichier dans ce système de fichiers,
examinons la structure des blocs d'indirection.

Le descripteur de fichier indique :

 8 pointeurs directs vers des blocs de données,

 1 pointeur vers un bloc d'indirection simple, et
 1 pointeur vers un bloc d'indirection double.

La taille de chaque bloc est de 128 octets, et la taille de chaque adresse de bloc est
de 8 octets.

Calculons la taille maximale possible d'un fichier :

1. Blocs de données directs : 88 blocs ×× 128128 octets/bloc = 10241024 octets.

2. Bloc d'indirection simple : 128128 octets / 88 octets/adresse = 1616 adresses
d'indirection.
 Ces adresses d'indirection peuvent pointer vers 1616 blocs de données
supplémentaires.
 1616 blocs ×× 128128 octets/bloc = 20482048 octets.
3. Bloc d'indirection double : 128128 octets / 88 octets/adresse = 1616 adresses
d'indirection.
 Chaque adresse d'indirection double peut pointer vers un bloc d'indirection
simple, soit 1616 blocs ×× 20482048 octets/bloc = 3276832768 octets.
 Ces 1616 blocs d'indirection simple peuvent pointer vers 16×1616×16 blocs
de données supplémentaires.
 16×1616×16 blocs ×× 128128 octets/bloc = 3276832768 octets.

La taille maximale possible d'un fichier serait la somme des tailles des blocs de
données directs, du bloc d'indirection simple et du bloc d'indirection double :
1024+2048+32768+32768=68608 octets1024+2048+32768+32768=68608 o
ctets

Cela équivaut à 68 Kbytes68 Kbytes, ce qui se situe entre les options fournies. Par
conséquent, la réponse correcte est 68 Kbytes68 Kbytes.