AmigaOne : FFS Instable
-
Hip !!
Hinhin !!
Erreur, erreur !!
Les systèmes modernes proposent des préférences graphiques aux utilisateurs… Donc on aurait pu y règler simplement, à grand coup de case à cocher et champ numérique !!
[edit]Et en plus, je vois pas le rapport… Comment ils font dans sfs pour utiliser les caches ?[/edit]
Erreur, Erreur !!
Argument incorrect !!
!! qiH
« Vu que PFS3 fonctionne (en émulation of course) sous MOS, je vois pas pourquoi il fonctionnerait pas sur AOS4 … à tester bien sûr. »
Parce que pour autant que je me rappelle, on a éjecté des fonctions de support pour le code BCPL qu’utilise PFS3 (mais qui ne font pas joli dans le décor d’un DOS rénové).
Quant à la question de savoir pourquoi le cache est un plugin pour FFS2, c’est simplement parce que FFS2 a été pensé pluginable, et que le premier plugin qu’olaf a créé pour démontrer la validité du concept, c’est un plugin de cache. Le suivant a été l’encryption plugin, et il y en a d’autres en préparation.
Rappelons à ce point, que les blocks de « buffers » qu’on alloue à un filesystem (soit à la définition des partitions soit a posteriori en utilisant AddBuffers) sont uniquement des blocs de cache des directories, pas des fichiers.
Sous OS4 :
– SFS fonctionne avec la « diskcache.library » qui comme sous Unix, utilise (une partie de) la mémoire libre pour cacher les blocs de données des fichiers. Lorsque c’est nécessaire, diskcache.library « rend » la mémoire au système.
– FFS2 fait la même chose quand on utilise son fs_plugin_cache (utilisation de la moitié de la mémoire libre, de façon dynamiquement ajustée).
– SFS s’appuie sur le (bon) fonctionement du cache d’écriture du disque, qu’il flushe de temps à autres (à la façon d’un cache ‘writeback’), alors que FFS est plus parano et flushe tout le temps (à la façon d’un cache ‘writethrough’). C’est pourquoi en écriture, même avec fs_cache_plugin, FFS2 reste beaucoup plus lent que SFS… Mais on peut forcer FFS2 en mode ‘writeback’, en ajoutant « fs_set_flush_strategy dhx: 1 » dans la user-startup pour les partitions désirées.
– les drivers IDE OS4 (VIA, SI680 et SI3112) testent le bon fonctionnement du write cache de chaque disque, et le désactivent complètement s’il ne marche pas bien, car sinon, SFS ne peut pas être fiable. Si vous avez des performances disque extrêmement faibles avec FFS2, spécialement en écriture, cela vient à 99% des cas du fait que le write cache de votre disque a été détecté comme non fiable par les drivers IDE (une solution consiste à passer de FFS2 à SFS, car SFS est quand même capable de fonctionner rapidement sur un disque sans write cache, alors que FFS2 rame dans ce cas, tant que vous n’avez pas changé le mode de gestion du cache en writeback, voir ci-dessus). Pour le savoir, vous pouvez regarder ce que les drivcers IDE sortent comme trace sur le port série au boot, ou encore les interroger une fois l’OS chargé avec idetool.
Dans tous les cas, par construction, FFS2 reste plus lent que SFS, quelles que soient les options.
Amicalement,
—
Stéphane Guillard
Question conne mais je m’interroge :
Pourquoi, puisque FFS se traîne des tares dues à son grand âge et la tentative désespérée de le garder rétro compatible, pourquoi ne pas avoir simplement porté FFS sous AOS 4 pour garder la compatibilité avec les disques venant des OS précédents et avoir à la place, en guise de FS par défaut, créé (ou porté), un système de fichier plus performant/efficace/fiable ?
PFS3 par exemple est vraiment une brute de guerre, MuFS permet la gestion multi-user, SFS est un bon compromis, etc etc … pourquoi ne pas avoir pris SFS par exemple comme FS par défaut et non comme contrib ?
Après tout, AHI, MUI, P96 n’étaient que des contribs en leur temps, aujourd’hui, ce sont des composants « officiels » du système alors pourquoi perdre du temps et se prendre la tête à maintenir et tenter d’améliorer quelque chose dont le design original est de toute façon limitant ?
Sinon, un truc intéressant avec cette histoire de plugins … est ce que ça sous entendrait qu’il pourrait y avoir un « fs_multi_user » plugin par exemple pour ajouter une gestion multi user à FFS ou la structure du FS l’en empêche ?
A+
@Hybrid :
Ben, si FFS2 a été conçu, c’est justement pour faire sauter les
brides, alors, bien sûr que c’est possible d’avoir un plug-in
multi-youzeur.
Et puis tiens, pkoi pas un plug-in « je colle virtuellement des
fichiers de 2Go de façon transparente (au lieu de l’imposer aux
concepteurs des applis, comme si c’était leur boulot de se soucier
de ce genre de truc), pour l’utilisateur pour faire croire que c’est
un gros, pour gérer des fichiers énormes », en attendant une refonte
totale du DOS (qui, si ça se trouve, a déjà été faite…) ?
{{ } { } } <-- pour compenser l'usage massif des parenthèses.
bhein
fs_multi_user: sans protection mémoire cela n’a aucun intérêt.
bhein moi je trouvais MuFS bien pratique sous OS3.0 pour par exemple avoir un système qui me permettait de protéger les fichiers systèmes contre l’effacement par ma copine ou même auparavant mes frêres… Pour moi le truc avec MuFS ce n’est pas (en core) forcément la possibilité d’avoir plusieurs sessions utilisateurs actives en même temps mais bien de pouvoir protéger des fichiers contre des erreurs de manipulations (voir même des virus, il suffit de se connecter avec des droits moindres (pas en administrateur hein) et pouf c’est réglé : les seuls fichiers pouvant être infectés sont des fichiers utilisateurs qui ne sont pas forcément sensibles au bon focntionnement…
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Général › AmigaOne : FFS Instable
