PFS3
Le Professional File System 3, aussi connu sous l'acronyme PFS3, est un système de fichiers. Il a été l'évolution logique du système de fichiers FFS de l'Amiga, avec la monté en capacité des disques, poussant les limites à une taille de partition de 104Go et la gestion des disques de 2To.
Pour plus de détails sur PFS3, relire l'article de Laurent Belloni Obligement 19 - janvier 2000.
Comme il existe plusieurs versions, par processeur et TD (commandes TrackDisk standard ou TD64) et DS (commandes "Direct SCSI"), vous comprendrez la complexité à choisir et le risque de plantage à l'installation de ce système de fichiers, sachant qu'il faut au minimum une ROM 2.04.
Du paquet PFS3, il est intéressant de garder HDInstTools, pour le partitionnement, et Tools/PFSDoctor pour réparer d'éventuels problèmes.

PFS3aio (aio = all in one, tout en un) est la synthèse des deux versions (TD64 (Phase 5) et DS (Direct SCSI)), et a l'avantage de rester compatible avec les systèmes 1.2,1.3/2.x/3.x du 68000 au 68060 (voir même le 68080 :) ).

Petits rappels:
TD64 (1995) est une extension définie par Phase 5, développée après la faillite de Commodore.
NSD new style devices (1997), est une extension définie par les repreneurs de l'AmigaOS, bien sûr différente et non compatible avec TD64 (et pourtant TD64 et NSD utilisent la même astuce... décrite plus bas).
DS Direct SCSI, sont des commandes reconnues uniquement par les disques de type SCSI.
La version 5.3 de PFS3 (version du système de fichiers numéroté 18.3) est une version commerciale écrite en C avec un peu d'assembleur 680x0 par Michiel Pelt.
Toutes les versions suivantes sont maintenues par Toni Wilen et la version officielle se trouve sur aminet PFS3aio
PFS3aio a besoin des commandes TD64 ou DS.

Schéma du principe
Utilisateur
Applications (fread(), fwrite()... )
dos.library (Read(), Write()... transforme les ordres des fonctions en messages dospackets)
système de fichiers (transforme les dospackets en iorequest)
device (transforme les iorequests en commandes SCSI READ (10), WRITE (10), ...)
Matériel (reçoit les commandes et agit sur le support... clef, disque)

Si l'utilisateur lance une application qui lit des données sur disque, par exemple un programme en C qui lit 512 octets d'un fichier, fread(&buffer, 1, 512, f) ; cette fonction passera en réalité par une fonction DOS Read(f, &buffer, 512) ; qui va transformer cet ordre en message au système de fichiers (plus précisément un dospacket ACTION_READ).
Pour notre cas ce sera PFS3, qui le décomposera en iorequest compréhensible par le device (message de demande d'entrée/sortie TD_READ64).
Le iorequest est une structure qui comprend un champ io_Offset, entier long 32 bits non signé, qui sert à repérer la position des blocs sur le disque.
Malheureusement, ce nombre n'est pas un numéro de bloc, mais sa position, il faut multiplier le numéro de bloc par sa taille en octets pour obtenir cet io_Offset.
io_Offset = numéro de bloc * 512.
On arrive vite à la barrière des 2Go.
Il faut donc passer à une numérotation sur 64 bits pour cet io_Offset.
TD64 et NSD utilisent la même astuce: le champ io_Actual sert à stocker les 32 bits haut, et io_Offset les 32 bits bas.
Le nombre indiquant la position du bloc peut ainsi dépasser la barrière des 2Go.
Le pilote de bas niveau (appelé device) traduira cette position de bloc (io_Actual:io_Offset) sur 64 bits, en divisant par 512 (décalage à droite de 9 bits) en numéro de bloc utilisable par la commande SCSI "READ (10)", commande scsi de 10 octets, qui selon la documentation des commandes SCSI peut adresser 232-1 blocs de 512 octets, soit 2To.
Il existe un READ (16) et un READ (32) qui peuvent adresser 264-1 blocs de 512 octets, mais je doute que l'Amiga puisse faire quelque chose de correct avec ces commandes.
Pour l'écriture, c'est le même principe, la commande iorequest TD_WRITE64 sera traduite en "WRITE (10)" en divisant la position de bloc (io_Actual:io_Offset) sur 64 bits par 512.

Le device
Utilisez l'utilitaire check4gb pour tester si le device peut supporter les gros disques.
Exemples:

>Check4GB usbscsi.device 0
usbscsi.device unit 0 supports TD64 commands
C'est rassurant, il en fait le minimum...
>Check4GB uaehf.device 0
uaehf.device unit 0 supports NSD commands
uaehf.device unit 0 supports TD64 commands
Le device de WinUAE supporte tous les modes connus pour les disques de taille supérieure à 4Go.
>Check4GB trackdisk.device 0
trackdisk.device unit 0 does not support harddrives larger than 4GB
Comme on pouvait s'y attendre, le trackdisk.device, n'est pas éligible.
>Check4GB scsi.device 0
scsi.device unit 0 does not support harddrives larger than 4GB
Et le scsi.device non plus...
Alors que faire si son device n'est éligible ?
Il doit exister des mises à jour de ROM... ... ... on pourrait aussi patcher le scsi.device au premier démarrage, mais la première partition amorçable devra être en FFS dans les 2 premiers Go.

Les versions
La dernière version PFS III est la 5.3.
Pourtant la version du système de fichiers est 18.3
PFS3aio est en version 3.0.
Pourtant la version du système de fichiers est 19.0
et les versions expérimentales ont toutes le même numéro... donc soyez vigilants quand vous modifiez le RDB (Rigid Disk Block, endroit du disque où sont stockés les partitions et les systèmes de fichiers) ou copiez ce fichier dans le répertoire système L:

HDInstTools

Modifier l'icône DEVICE= avec le nom du device.
Exemple:
DEVICE=usbscsi.device
Vous pouvez ainsi installer des systèmes de fichiers et partitionner le disque indiqué.
Un précédent épisode a montré comment se servir de HDInstTools pour transférer des données entre un PC et un vrai Amiga

Problèmes (avec la version d'origine de PFS3 et la version 18.4 de pfs3aio)
Si vous décompressez une archive .lha (.lzh ou .zip c'est le même problème, il faut créer beaucoup de fichiers rapidement) directement sur une partition PFS de plus de 5Go avec PFS3 18.3 (ou PFS3 18.4), vous risquez d'avoir des messages d'erreurs dans le genre wrong block id et ne plus pouvoir écrire sur le disque.
Heureusement il y a PFSDoctor

Alors on clique

On attend

Et après quelques minutes d'angoisse, c'est réparé.

Sous 1.3
C'est visuel...

Quelle est donc cette partition fantôme ?

Démontage de partition...
Un autre bug, le dospacket ACTION_DIE, pour signifier que l'on souhaite démonter une partition, provoque un gourou sous 1.3 (un #3) et de temps en temps sous AmigaOS 3.1... Toni a passé beaucoup de temps avec la commande unmount de ce paquet pour liquider ce problème (pour une fois ce n'était pas de mon sort... la commande unmount fonctionne parfaitement avec fat95, un autre système de fichiers (et pas du tout avec le FFS original))

La version 19.0 de PFS3aio
Heureusement il y a des mises à jour, qui corrigent les problèmes.
Une mise à jour du RDB par le nouveau PFS3 version 19.0, un redémarrage et le problème disparait.
Pour mettre à jour, c'est relativement simple, avec HDInstTool (HDInstTools fonctionne aussi sous 1.3, mais les couleurs de l'interface sont affreuses)
On va faire un tour dans "File System..."

Notre PFS3 est un 18.4 (c'est en fait un 18.3 maintenu par Toni Wilen)
"Update..." pour mise à jour.

Sélectionner le nouveau système de fichiers
C'est bien la version 19.0.


On sauve les changements.

Et on peut redémarrer.

Je mets la version 18.4 à gauche et la version 19.0 à droite, pour comparaison.
Non seulement la partition fantôme a disparu, mais en plus on a économisé de la RAM (5712 octets :) ).

Conclusion
J'ai réalisé ces manipulations avec WinUAE et un fichier image de 120Go (via uaehf.device) avant de mettre à jour pour de vrai le disque usb de 120Go (via usbscsi.device et ANAIIS) qui sert de dd à mon A2000 (qui a 30 ans cette année !).
Les 3 défauts constatés ont disparu dans les deux contextes.
PFS3aio est un système de fichiers permettant d'utiliser de gros disques récents sur un vieux système de 33 ans... et en plus de cela il est rapide et très fiable, par rapport au FFS. Je n'ai encore rien perdu, PFSDoctor a toujours tout retrouvé...