Le système de fichiers est l’un de ces multiples éléments invisibles qui permettent à un appareil disposant d’un stockage de fonctionner. Mais en quoi consistent-ils ? Quelles sont leurs fonctions ? Ont-ils évolué ? Voici l’essentiel de ce qu’il faut savoir sur le sujet.
Un système de fichiers s’intercale entre le système d’exploitation et le matériel. On le définit habituellement comme un système de classement des données, ce qui suppose que tout a été pensé : la structure des informations, leur organisation, la manière dont l’écriture et la modification vont se faire, ce qui se passe en cas de suppression, etc.
Surtout, un système de fichiers – que l’on retrouve souvent sous le sigle anglais FS, pour file system – va permettre à une personne d’accéder à ses données. Et non seulement elle doit pouvoir y accéder, mais cette livraison d’informations doit se faire le plus vite possible.
La question des performances est certes importante, mais pas nécessairement prioritaire. Comme on le verra, il existe des systèmes spécialisés ayant des spécificités, par exemple sur l’intégrité ou la sécurité des données. En outre, certains sont propriétaires, d'autres libres, avec parfois des questions de redevance, comme ce fut le cas pour exFAT jusqu'en 2019.
Mais avant d’aller plus loin, revenons aux bases.
Lire notre dossier sur les systèmes de fichiers :
- Qu'est-ce qu'un système de fichiers ?
- Systèmes de fichiers : FAT12 à 32 et exFAT, conçus pour le grand public
- Systèmes de fichiers : NTFS et ReFS, pensés d’abord pour l’entreprise
- Systèmes de fichiers : de HFS et ses évolutions à APFS chez Apple
- Systèmes de fichiers : ext4 et Btrfs, les « frères ennemis » du monde Linux
- Systèmes de fichiers : (Open)ZFS, ses grandes capacités et ses mystères
Et la mémoire de masse fut
Si l’on pouvait, toutes les données seraient dans la mémoire vive. Les opérations y sont bien plus rapides. Pour des questions évidentes de coût, ce n’est pas possible. Il faut donc un autre type de stockage, une mémoire persistante, secondaire, dans lequel on va pouvoir entreposer la masse toujours croissante de données pour y accéder en cas de besoin.
Pour résumer à grands traits, ce fut le rôle des disquettes, puis des disques durs et plus récemment des SSD (ainsi que des CD, DVD et autres). La technologie utilisée n’a pas d’importance ici, on retiendra surtout ceci : pour gérer ces grands espaces, il fallait une organisation capable de répondre à tous les scénarios. En plus des éléments cités plus haut, un « FS » s’occupe ainsi de la convention de nommage, c’est-à-dire la manière dont sont nommés les fichiers. Les permissions, règles d’accès, quotas, privilèges ou encore les métadonnées sont aussi de son ressort.
C’est donc une composante primordiale d’un appareil et l’une des plus discrètes. L’analogie la plus simple est celle d’une grande salle d’archivage. Et qui dit archivage dit index, pour retrouver les documents dès que l’on en a besoin.
Dans la grande majorité des cas, on parle donc de fichiers et de dossiers comme organisation élémentaire, ce qui apparaît devant nos yeux comme des arborescences de dossiers dans le gestionnaire de fichiers du système d’exploitation. Il s’agit d’une vue abstraite et on ne la voit pas toujours, car tous les appareils ne laissent pas forcément un accès direct à cette structure. Un exemple ? iOS ne le permettait pas avant sa version 11 et l’apparition de Fichiers.
Sachez d'ailleurs que les dossiers n'ont pas existé tout de suite. Chez Microsoft par exemple, ils sont arrivés avec MS-DOS 2.0.
Le lien avec le matériel
De nombreux utilisateurs connaissent bien l’expression « formater » un disque. Pour beaucoup, c’est le synonyme de « tout effacer et recommencer », avec l’installation d’un système d’exploitation neuf. Ce n’est toutefois pas le sens premier du verbe, mais sa conséquence.
« Formater » signifie littéralement « mettre au format ». C’est l’action qui consiste à établir sur le disque de stockage la structure qui va ensuite accueillir les informations. Parmi les caractéristiques de ce format, on retrouve notamment la taille du bloc, c’est-à-dire la taille de la plus petite unité que le FS va gérer.
À la manière d’une HAL (hardware abstraction layer), le système de fichiers est une abstraction du matériel. Les utilisateurs interviennent très peu souvent sur la taille des blocs (appelés clusters en anglais). Le cas le plus fréquent est sans doute le formatage d’une clé USB. Sous Windows par exemple, le choix par défaut est la FAT32, qui propose des blocs de 16 ko. Mais on peut également la formater en NTFS ou exFAT, qui donnent respectivement des blocs de 4 ou 32 ko par défaut. Dans tous les cas, le panneau Formater permet de choisir une autre taille.
La taille de ces blocs a une importance capitale et celle par défaut l’est parce qu’elle représente le meilleur compromis entre performances et consommation de l’espace. Elle peut changer également en fonction de l’espace adressé. Avec NTFS par exemple, la taille par défaut est de 4 ko, mais elle est de 2 ko pour les espaces de moins de 2 Go et de 8 ko pour 16 To ou plus.
Pour comprendre l’importance d’un bloc, gardons l’exemple du NTFS et de ses blocs de 4 ko. Si vous avez un petit fichier de 1 ko, il occupera un bloc, ce qui représente 3 ko « perdus », mais qui seront utilisés si le fichier grossit. Si vous avez un fichier de 11 ko, il utilisera trois blocs : deux complets et un troisième rempli aux trois quarts (3 ko utilisés sur 4 disponibles). Un fichier occupera toujours un nombre entier de blocs.
Selon le système de fichiers et avec le temps, les données peuvent être écrites « là où il y a de la place ». Les blocs d’un fichier peuvent donc être situés aux quatre coins d’un disque, phénomène que l’on nomme fragmentation et qui a fait les beaux jours de certains outils à une époque. Pour un disque dur, c’était un vrai problème : la tête de lecture devait se balader un peu partout pour recoller les morceaux, faisant baisser les performances générales. Un problème en grande partie révolu avec les SSD.
De manière générale, la taille des blocs grandit avec l’espace à adresser, que l’on appelle le plus souvent partition ou volume en fonction des cas (mais ce n’est pas toujours si simple). Il y a toutefois des exceptions. L’exFAT a ainsi des blocs de 32 ko parce qu’elle a été spécifiquement conçue pour les cartes SD des appareils photo numériques. Les photos sont souvent des tailles importantes et des petits blocs ne sont pas nécessaires.
On en revient donc au compromis. Une grande taille de bloc permettra une écriture plus rapide des données puisque le nombre de blocs à gérer pour un gros fichier sera plus petit, avec une fragmentation nécessairement plus faible. En revanche, si l’on utilise souvent des petits fichiers, l’espace perdu sera plus important. Une problématique que nous avons déjà abordée avec la taille des blocs « physiques » des disques durs (512 o ou 4 ko).
Il faut donc bien distinguer deux choses. D’un côté l’écriture « logique » quand le système d’exploitation place les données sur la partition, avec son système de fichier. De l’autre, l’écriture physique quand le périphérique de stockage place les données sur ses plateaux.
Partition et volume, sans musique
Comme beaucoup le savent, il est possible de découper un disque en plusieurs parties. Dans la grande majorité des cas, on parle de partitions : une division logique du disque physique. Il est très courant par exemple de diviser un gros disque dur en plusieurs partitions (primaire, logique et étendue), chacune dédiée à un usage particulier. Chaque partition reçoit généralement une lettre (à partir de C) pour l’identifier et peut avoir un système de fichiers différent. Certaines peuvent être masquées, comme celles d'amorçage et de restauration, selon les systèmes d'exploitation.
Le volume, quant à lui, est une appellation plus souple désignant une unité logique de stockage de données. N’est-ce pas exactement la définition d’une partition ? Oui… et non. Le volume prend en fait place sur un disque dynamique, c’est-à-dire une structure logique pouvant intégrer plusieurs disques physiques. Leur espace est agrégé en une réserve commune, sur laquelle les volumes sont définis. Par exemple, si l’on a trois disques de 2 To, on peut créer un volume de 6 To, deux de 3 To, un de 4 To, etc. De nombreux systèmes modernes savent créer ce type de structure.
Il s’agit bien d’une virtualisation du stockage, avec tous les avantages de flexibilité que l’on peut en attendre. Par exemple, les disques peuvent être configurés en RAID, pour des besoins de sécurité et/ou de performances. Le mécanisme est également omniprésent dans les serveurs, puisque l’espace peut alors être distribué selon les besoins et de manière dynamique. Un volume étant une unité logique de stockage, on peut aussi y créer plusieurs partitions.
Volumes de disque sous Windows 11
Un mot enfin sur deux sigles que vous avez peut-être croisés au moment de partitionner : MBR et GPT.
Le premier signifie Master Boot Record et sert globalement d’index au début du disque dur pour renseigner notamment sur son découpage et l’amorce du système d’exploitation (boot loader). On peut y penser comme une forme de table des matières.
Seulement voilà, il s’agit d’une très ancienne norme, car elle a été créée par IBM en 1983. Le MBR a plusieurs limitations, dont une compatibilité limitée avec le matériel moderne, ne pouvant par exemple pas gérer de disque de plus de 2 To. Il ne peut gérer également que quatre partitions primaires. Si l’on en souhaite plus, il faut garder un des emplacements pour une partition étendue, dans laquelle on pourra créer autant de partitions logiques que souhaité.
La GPT signifie quant à elle GUID Partition Table. On peut créer théoriquement autant de partitions que l’on veut, chacune étant munie d’un identifiant unique appelé GUID, pour Globally Unique Identifier. En pratique, le nombre et la taille des partitions dépend des limitations de chaque système d’exploitation. Les cartes mères UEFI prennent en charge le partitionnement GPT.
Le grand bazar
Avec une telle quantité d’informations, comment s’y retrouver ? Cette partie est un peu plus technique, mais nous allons tâcher de la vulgariser autant que possible.
Dans les grandes lignes, il y a principalement deux méthodes. La première est sans doute la plus connue car utilisée par Microsoft : la table d’allocation des fichiers, la fameuse FAT (file allocation table) que l’on retrouve notamment dans les FAT16 et FAT32. Dans ce format, chaque fichier stocké dispose d’un numéro unique. La table agit comme un index et fait le lien entre ce numéro et l’identifiant du premier bloc du fichier. Cet index étant unique, il faut lui réserver un espace dédié sur le disque, expliquant pourquoi l’espace disponible d’un disque ainsi formaté est toujours inférieur.
Bon, mais puisque l’on a seulement l’identifiant du premier bloc, comment faire pour trouver le reste ? Il y a plusieurs manières de procéder, mais on retiendra la plus courante : chaque bloc contient à la fin l’identifiant du prochain bloc. S’il s’agit du dernier, il contient la valeur EOF, pour End of file, signalant qu’il n’y a plus d’autre bloc. La méthode a l’avantage d’être très simple dans son approche, mais très sensible à la fragmentation. Les anciens systèmes de fichiers comme FAT16 et FAT32 ne disposent pas de mécanismes dédiés à cette fragmentation. Ils sont arrivés plus tard dans les versions successives de NTFS. Sur les systèmes UNIX/Linux, les systèmes de fichiers ont depuis longtemps de tels mécanismes.
L’autre grande méthode pour retrouver ses données est le stockage indexé. Plus de table d’allocation ici, chaque fichier est constitué d’un bloc d’index servant à stocker les informations sur ceux de données. Avantage immédiat : plus besoin de déterminer à l’avance un grand index pour référencer les fichiers, l’espace formaté étant très proche de l’espace matériel total. Désavantage tout aussi immédiat : l’espace sera plus vite consommé, puisque chaque fichier a toujours besoin d’un bloc supplémentaire. Pour reprendre l’exemple du fichier de 1 ko sur des blocs de 4 ko, il faudrait alors deux blocs, donc 8 ko.
Bon, et c’est tout ?
Pas tout à fait, car sur les systèmes de fichiers modernes, les fonctions vont bien au-delà de la simple organisation des données. Nous en avons parlé par exemple, mais la convention de nommage fait partie des attributions des FS. La première FAT de Microsoft permettait par exemple des noms de fichiers composés de huit caractères, suivis d’un point puis d’une extension de trois caractères. Cette limitation a sauté avec la FAT32 (via LFN) et n’est plus d’actualité depuis bien longtemps dans aucun système courant.
Parmi les autres fonctions qu’un système de fichiers peut prendre en charge, on trouve :
- Le chiffrement, intégral ou non
- Les clichés instantanés (snapshots) pour les fichiers ou le disque entier, c’est-à-dire la sauvegarde à un instant T d’un lot de données en vue d’une éventuelle restauration
- La journalisation de tous les changements intervenant sur le disque, pour restaurer des données en cas de panne ou d’erreur
- La gestion des autorisations et permissions pour l’accès aux données
- Le clonage de fichiers, copie quasi instantanée sur laquelle seules les données modifiées par rapport au fichier d’origine sont sauvegardées
- La copie sur écriture, mécanisme lié au précédent, qui permet la création automatique d’une nouvelle copie du fichier dès que des modifications sont opérées
- Le partage d’espace, permettant à plusieurs volumes de croitre et décroitre dynamiquement selon les besoins, sans toucher aux partitions
- Le contrôle d’intégrité des données (via des cheksums)
Voilà pour les principales fonctions. Dans nos prochains articles, nous reviendrons plus spécifiquement sur certains systèmes de fichiers ou familles de systèmes, comme NTFS, ext4, BtrFS, APFS ou encore ZFS. Comme on verra, les approches peuvent changer radicalement de l’un à l’autre.
Commentaires (60)
#1
Joli ! Merci ;)
#2
Bonne introduction.
Il faudra aborder la journalisation, c’est très mal compris même par des informaticiens, et pourtant c’est ce qui permet d’avoir une confiance presque absolue dans le FS.
Et bêtement, parler des FS comme ceux des VAX, Palm (oui, les palm de mémoire sont proche d’un mainframe), mainframe IBM est intéressant: ils ont des notions de taille et extension du fichier qui ne sont plus du domaine de la BDD mais manquent parfois à nos FS.
Utiliser une VM stockée sur un FS “classique” a ses limites.
Je rapporcherais dans la liste des fonctionnalités les snapshots du clônage + copie sur écriture car ils fonctionnent sur ce principe! C’est pour cela qu’ils sont “instantanés”.
Et je m’amuse toujours à montrer que certaines “nouveautés” dans les FS sont en fait là depuis longtemps et disponible à tout le monde depuis 2000/XP (par exemple le snapshot, très utilisé par moi-même pour annuler des modifs depuis près de 20ans sous Windows) - ou le versioning de fichier quasi obligatoire sur ODS sur VAX.
Et mon petit chouchou: si, il fallait aussi défragmenter les disques sous Linux - et ça ne pouvait être fait que si le disque était en lecture seule contrairement à Windows qui le fait à chaud depuis longtemps (mais bon, c’est de l’histoire ancienne avec les SSD).
Il y a aussi le futur, avec les SSD en zoning histoire de ne plus se farcir l’historique des disques durs dans les SSD - et l’abstraction constante qui fait que même sur un disque dur moderne, l’écriture n’a pas lieu là où on le croit…
#2.1
Très curieux des snapshots dispos depuis Windows 2000/XP. Tu parles de VSS?
#2.2
Pour les snapshots (Shadow Copy), je suis d’accord, les points de restauration sauvent la mise !
Malheureusement, j’ai eu parfois la surprise de constater que l’espace alloué pour les points de restauration était défini à zéro pourcent… quand j’en avais le plus besoin, bien entendu… alors maintenant je prends l’habitude d’aller vérifier de temps en temps.
Concernant les versions précédentes, j’était convaincu pendant longtemps que ça devait se faire tout seul, activé par défaut, mais en fait, non, il faut le faire manuellement.
#2.3
Je confirme : j’ai toujours choisi ext4 parce que… c’est comme ça. Je vois bien que BtrFS c’est top (notamment dedup et snapshot), que ZFS c’est très bien aussi, mais j’ai toujours un article, une commentaire qui me freine et je laisse tomber. Finalement, il n’y a que ReFS comme FS moderne que j’utilise sur Windows.
#3
Un petit détail sur les FAT en 16/32Ko.
A une époque lointaine, on avait une perte énorme de place si on passait en 32ko, beaucoup de fichiers étant petits.
Les systèmes de compression de disque étaient d’autant plus efficaces qu’il récupéraient cette place perdue car ils savaient mettre les fichiers “bout à bout”.
C’est toujours le cas avec la compression de répertoire sous Windows - utile pour les petits fichiers en lecture seule et données froides.
#4
Super article :) !
#5
Je n’avais jamais réalisé à quel point les tailles de blocs par défaut sous Windows sont énormes. Sous Linux, c’est 4 ko par défaut.
#6
Uniquement pour Windows. Sur Linux (et probablement tous les Unix/Unix like), elles démarrent toujours à a.
Et l’explication vient du fait que A et B étaient destinés aux lecteurs de disquettes.
#6.1
sous linux c’est meme complétement différent. une partition ne reçoit pas de lettre pour y accéder mais on dispose d’une arborescende unique qui donne accès selon le répertoire à une partition sous-jacente.
Par exemple, on peut avoir une partition qui pointe sur / (racide du systeme), une autre (équivalenet du d: sous windows) pour /home pour les données utilisateur, etc.
par défaut la plupart des distributions vont faire choisir des points de montage dans la phase d’installation, ensuite les partitions vilatiles (genre clé usb) sont montées dans un dossier créé selon le nom de la clé.
#6.2
Ça c’est le point de montage c’est différent, mais les partition sont « numérotées » : /dev/sda1, /dev/sdb3 (la lettre “a”,“b” correspond au disque, le chiffre “1”, “3” à la partition sur le disque).
#6.3
merci pour la précision.
Effectivement meme si avec les nouveau disques (nvme) les dénominations historiques ont quand meme souvent été revues, ce qui fait que cette convention basée sur des lettres est de moins en moins visible
#6.4
Les device numbers ne correspondent pas à une partition à proprement parler. Ils sont l’équivalent justement d’un C:, D;, etc à la Windows mais en réalité l’identifiant de la partition est un UUID (inscrit sur le support pour le coup). Le device number n’est qu’une vue système.
C’est la raison pour laquelle il faut toujours faire un
lsblkAVANT et APRES avoir plug une clé USB pour faire un bon grosdddessus pour copier un ISO, car l’affectation /dev/sdX est susceptible de changer.C’est une bonne pratique justement d’utiliser le UUID dans
/etc/fstabplutôt que /dev/sdX car le mapping peut changer pour une raison X ou Y.#6.6
Lol, même si ça fait un bail que j’ai pas touché à un Linux, j’avais complètement raté ce point
, je pensais que la lettre a dans hda faisait parti de l’acronyme et que sa signification devait m’échapper pour une obscure raison… J’aurais appris un truc, merci 
#6.5
Sous Windows tu as toujours un lecteur obligatoire (je crois, et si pas obligatoire je pense que plusieurs programmes ne seront pas très content). Les autres partitions peuvent être montées dessus.
Les choses évoluent, c’était mal supporté par les installateurs qui te disaient “t’as pas assez de place” parce qu’ils se basaient sur la place dispo à la “racine”.
Une partition peut avoir plusieurs points de montage.
#7
Merci beaucoup. N’oubliez pas ReFS…
#8
Est-ce que tu vas parler de GPFS ?
#9
”,une mémoire persistante, secondaire,”
J’aurais écrit une mémoire secondaire persistante pour éviter la multiplication des virgules.
“Les photos sont souvent des tailles importantes”
ont ?
Ce dossier est très chouette, vivement la suite.
#10
Oui
Oui, c’était pilotable, à l’époque 64 versions maxi de mémoire, donc il fallait purger.
https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/aa394428(v=vs.85)
Là je regarde l’outil vssadmin, mais il ne propose plus d’ajouter des snapshots (c’est peut-être pas activé sur la machine).
#11
J’en rajoute une couche, dans /dev (DEVices), on trouvait ou trouve encore :
Au final, la logique n’a pas tellement changé, le nommage s’est juste adapté aux nouvelles interfaces.
#12
et BeFS.
Et du fait que les SSD doivent faire toute une gymnastique pour que les FS actuels ne les usent pas trop vite https://lwn.net/Articles/353411/.
Et du fait qu’on ne défragmente pas un disque SMR parce qu’on ne met pas n’importe quel FS sur n’importe quelle techno
Et des systèmes pour cartes flash du coup?
Et du fait qu’un FS ne correspondent pas forcément à du stockage (les UNIX avec le “tout est un fichier” y compris la mémoire, la carte son …)
#13
Excellent article sur un sujet sur lequel je voulais me pencher.
Merci Vincent.
#14
La suite est attendue !
#15
Effectivement, si on branche plusieurs clés, rien ne garanti quoique ce soit sur le fait qu’une clé soit toujours /dev/sdd1
On a le même “problème” avec les ports série ou les manettes USB par exemple. Leur n° change constamment.
#15.1
Windows aussi a(vait ?) le même problème. C’était un souci récurrent sur XP quand je faisais du support poste de travail.
“Ma clé USB apparaît pas !”, à cause de l’affectation prédéfinie des disques réseau qui parfois se marchaient dessus, résultat la lettre de la clé USB était prise par un autre lecteur et Windows ne la réassignait pas.
#16
Article très basique, mais au moins c’est une base. J’ai hâte d’en savoir plus sur les systèmes linux. J’avoue être un peu paumé étant sous Fedora (qui a fait assez récemment le pari de btrfs) et une notion différente de “volume”. C’était pour ma part plus simple avec les systèmes ext. Y compris en RAID.
#17
Je suis un peu déçu: la FAT12 des disquettes n’est pas citée!
On met de côté tout un pan de l’histoire des PC avant l’arrivée des disques durs.
Et le format des noms de fichiers 8.3 qui stocke le point et impose des majuscules au lieu d’autoriser simplement jusqu’à 12 caractères…. Limitation débile compliquant les choses.
#18
Juste pour rajouter un mot clé pour ceux que ça intéresse : faut regarder du côté des inodes (surtout pour les systèmes extX)
https://fr.wikipedia.org/wiki/N%C5%93ud_d%27index
#18.1
Hahahaha… Vieux souvenir d’astreinte pour “FS full” où au bout d’une demi heure à rager parce que tu comprends pas la cause t’as pas pensé à regarder les inodes.
#19
Sous Linux les partitions n’ont pas de nom tel que “a” ou “A” ou “C”. Tout au plus, elles ont un numéro d’ordre (celui du MBR ou du GPT), avec “/dev/sda1” puis “sda2” etc. pour le premier disque SATA.
Le nom est seulement décidé au montage avec le nom du répertoire sous lequel elle est montée (“/” ou “/boot” ou “/home” par exemple).
En fait à l’origine “s” de “sda” c’est pour les disque SCSI (j’ai commencé avec des disques SCSI quand j’ai installé mon premier Linux en 1998, c’était plus sérieux que le pauvre IDE), mais ça a été repris quand le SATA est apparu.
Pour moi c’est bon, mais “port 0” je ne crois pas car il y a un disque NVME par connecteur. Faudrait en effet voir ce que ça donne avec un 2e disque NVME, je pense que ça doit être nvme0n2 (sur un autre “port” physique donc).
#19.1
le “n”, sur la numérotation nvme, c’est le namespace. Je ne crois pas que ce soit possible de le faire sur des nvme grand publique, mais dans la norme, ca permet de découper un NVMe en plusieurs namespace. Chaque namespace peut avoir un formatage bas niveau différent, bloc de 512 ou 4k par exemple.
#20
Je ne suis pas d’accord, si tu parles de la partition “/dev/sda2” elle reste la 2e partition du 1er disque SATA (les connecteurs physiques sont numérotés sur la carte mère), l’UUID lui est inscrit de façon logicielle sur la partition du disque.
Alors ça ne m’a jamais fait ça, quand je branche une clé USB je fais juste un “df -h” pour voir où elle a été montée, dans mon cas c’est souvent le “/dev/sdX” suivant du dernier disque de ma machine (j’en ai actuellement 3 sur mon fixe (nvme0n1, sda, sdb), donc la clé est sur /dev/sdc .
Dans mon cas, là où ta recommandation est utile, c’est quand je débranche à chaud un disque (démonté) de ma baie JBOD connectée en USB que ça provoque un nouveau “scan” des disques dans la baie (il y en a 6) et ça réaffecte différemment
, je m’en suis rendu compte le jour où j’ai formaté non pas le disque que je venais d’ajouter, mais un disque existant de la baie. Aucune idée de pourquoi le boitier+OS font que les disques réapparaissent sous un “sdX” différent.
#20.1
Linux n’affecte pas le nom /dev/sdX en fonction du device et de la partition. Ceux-ci sont découverts par le Kernel avec udev au démarrage (et au branchement) et leur assignation est faite par les règles de l’outil.
Raison pour laquelle il existe justement des tutos proposant des règles pour fixer le device name, par exemple en utilisant le SERIAL qui indique justement le port physique de la carte mère
Exemple avec mon /dev/sda :
/devices/pci0000:00/0000:00:01.3⁄0000:03:00.1/ata1/host0/target0:0:0/0:0:0:0/block/sda )
Plus d’infos :
https://wiki.debian.org/udev
https://wiki.archlinux.org/title/udev
Soyons clairs, le changement soudain de /dev/sda vers /dev/sdb est extrêmement rare. Mais il faut toujours garder en tête que ces assignations sont une vue système au moment de la découverte des devices, et non une vue hardware. Le fait que l’ordre des disques / partitions corresponde à l’ordre des devices names et juste une coincidence, ce n’est pas déterminé.
Raison pour laquelle l’UUID est préconisé pour monter des partitions. Regarde /etc/fstab, il est clair sur le sujet :
Complété par le manuel de fstab :
#20.2
moi j’ai un /dev/disk rempli de sous-dossiers de raccourcis : by-id est pas mal, je trouve :)
par contre, ça ne fonctionne pas forcément dans fstab car udev n’est pas forcément déjà démarré et les alias ne sont pas forcément déjà là au mount.
le UUID c’est pas forcément la panacée, notamment quand tu changes de disques, avec un UUID ça ne boot plus, avec des sdx un simple dd suffit à rebooter sur le nouveau disque.
#21
Effectivement, on voit l’héritage “PCInpact”, alors que les filesystem Microsoft ont toujours été en retard sur le reste du monde informatique.
Je n’ai jamais compris pourquoi Microsoft a choisi le “\” (backslash) pour les répertoires, alors que sur les Unix et BSD c’était “/” depuis longtemps (et comme Internet est né sous Unix, les chemins dans les URL sont en “/” bien sûr).
Rien qu’en comparant le FAT de Windows et le filesystem ext2 de Linux dispo dans les années 90 (bravo le thésard Rémy Card qui a conçu “ext” puis “ext2”, c’était le responsable informatique de ma salle info remplie de stations Sun Sparc), qui ne fragmentait pas et permettait bien plus de choses (noms des fichiers, longueur, etc.). Windows était vraiment vu comme un OS “Fisher Price”.
Il y a aussi disponible sous Unix et Linux divers filesystem, le FFS/FFS2 de BSD, Hammer de Dragonfly BSD, JFS d’IBM, XFS issu de Silicon Graphics (quelles machines fabuleuses à l’époque), et divers autres, sans parler du très puissant ZFS.
À ce sujet, quand les disques ont commencés à faire plusieurs centaines de Go, j’ai commencé à ne plus utiliser le nombre d’inodes par défaut (sélectionnés par la commande mkfs), mais à les spécifier pour ne pas gâcher trop de place (avoir 2 millions d’inodes ne m’a jamais servi à rien). Je le fais toujours, selon le type de partition (système ou “/films” sur le HTPC).
#21.1
J’ai lu que c’était une incompatibilité délibérée de MS pour faire du vendor lockin, mais c’était sans doute de la mauvaise foi.
D’après https://www.os2museum.com/wp/why-does-windows-really-use-backslash-as-path-separator/ , la cause profonde serait le choix de ‘/’ comme séparateur d’options de commande, hérité de systèmes encore plus anciens (et pas CP/M).
Sous Unix, le séparateur d’option est plutôt “-”, donc pas de souci.
#22
De mémoire, un héritage… De CP/M ?
D’un autre côté Windows n’était pas un OS, seulement Windows NT, non ? Fat32 si tu regardes comment les noms de fichiers long sont stockés…. Ça cassait pas la compatibilité avec le MS-DOS sous-jacent.
#23
En effet my bad, je n’étais pas réveillé quand j’ai écrit mon message, c’était 1 pour la première partition et pas a qui désigne le lecteur
#24
Ca reste le cas, nombre de programmes ont encore des limites dans les tailles des noms de fichiers (exemple: … Microsoft Office qui pose souvent des problèmes avec les fichiers de + de 400 caractères, la définition de caractère étant floue maintenant…)
EXT2 qui ne fragmente pas… Ca vient d’où? Non seulement il fragmentait aussi sous la pression, mais en plus il avait le même problème que ODS sur OpenVMS: on pouvait avoir un espace libre fragmenté et ne pas pouvoir écrire un fichier plus gros que le plus gros espace libre contigu!
C’est clair, les FS c’est la boîte de Pandore. Entre les couches de FS du système et le FS présenté à l’utilisateur (et le “FS” du support physique - plutôt un layout avec une couche physique et une couche logique), il y a des piles à analyser.
Exemple: les systèmes comme “Drivespace/DoubleSpace” sous Dos/Windows 9X, avec une FAT “physique” en-dessous et des disques “logiques” visibles, ou les systèmes dédupliqués (BTRFS, NTFS, …).
NTFS par exemple en dédupliqué est intéressant, il reprend un peu le système d’une avec des secteurs de taille variable et partagés entre les fichiers, mais la dédup s’effectue en différé donc le FS gère un système en partie “normal” et “dédupliqué” de façon transparente.
#25
Merci, j’ignorais qu’on peut avoir besoin de noms de fichiers aussi longs.
#25.1
Attention, c’est pas le nom de fichier qui peut faire 400 caractères, c’est l’arborescence complète + nom de fichier, genre : C:\Users\Tagadatsointsoin\desktop\monfichier.exe
D’ailleurs c’est une vraie galère ces fichiers avec des noms à rallonge sur NTFS, suivant les versions du FS ça écrit mais ça ne peut pas le copier sur un autre.
#26
Pour ça que c’est une recommendation, rien de plus. La solution unique répondant à tous les cas d’usage n’existe généralement pas, donc une faut ensuite s’adapter à son cas.
#27
Par curiosité, ça t’as permis de gagner combien de place ? De mémoire un inode c’est genre 256 octets, donc pour 2 millions d’inode ça te fait à la louche 512 Mo.
#28
Pas un OS ?
La fragmentation n’est pas nulle mais reste faible. On ne s’est jamais occupé de la fragmentation sur des serveurs de production en ext2 (puis 3 et 4).
Gros contraste avec toute l’époque FAT de Microsoft et les gens qui faisaient joujou avec des défragmenteurs, sans savoir forcément si ça valait la peine, car en plus c’était facilement très long de défragmenter.
Le gain n’est en effet pas gigantesque, mais ne serait-ce que sur une partition de 10 Go qui sert de système, passer de 900 000 à 300 000 inodes (rarement utilisés à plus de 200 000 chez moi) ça fait un gain non négligeable quand parfois le filesystem approche les 100 %, lors de certaines mises à jour, ça fait la différence entre une mise-à-jour qui échoue et une qui réussit.
Pour les 2 millions d’inodes, c’était probablement plus sur une partition de 3 To que j’ai.
#28.1
Voir la réponse de ShadowNet. Sous 95 et peut-être après il était même possible de quitter Windows pour n’être que sous MS-DOS.
#29
J’ai été confronté une fois - mais je n’ai pas eu beaucoup de serveurs Linux en main qui aient eu un problème de disque saturé ou de stockage de gros fichiers - ou qui ait duré plus de 2 ans sans réinstall.
En prod, je défragmentais fichier par fichier ou répertoire par répertoire via un outil sysinternals.
Le problème avec MS, c’était que leur stupide défragmenteur mettait tous les fichiers à la suite sans trou, au lieu de faire comme Ext2 en éclatant les fichiers sur l’espace libre.
On pouvait le “simuler” en défragmentant un fichier ou un répertoire “à la main”.
Quelques charges de travail étaient bien pourries aussi: faire un backup SQL dans un répertoire compressé menait à plusieurs centaines de fragments pour un backup.
Ceci dit, ne pas défragmenter un PC de bureau pendant 5 ans menait à de gros problèmes de perfs :)
#30
Sur le fond c’est quand même n’importe quoi, cet OS…
(rien de nouveau, c’est ce qu’on pouvait penser dans les années 90)
Avant les Windows NT (et NTFS) je n’ai jamais vu de Windows en prod, et les seuls que j’ai vus c’était pour de l’Oracle vers 2000. Mais pour tout ce qui était sérieux, c’était de l’Unix et ensuite du Linux.
C’est ce que beaucoup croyaient, je ne sais pas ce qu’il en était réellement. Les fichiers systèmes (les binaires) ne sont pas censés bouger quand même, ce sont les données utilisateurs.
Je me souviens que voir les animations de “Defrag” avec les carrés colorés c’était très joli et la sensation d’un rangement sans effort, mais que de temps perdu quand certains gars du support passaient et lançaient ce truc, mal fichu puisque même en le lançant à 1 h d’intervalle ça prenait toujours beaucoup de temps. Pour ma part je ne lançais jamais le défragmenteur au bureau.
#31
Non c’était une application DOS. L’OS était le DOS. Ce n’est devenu un OS qu’avec la branche NT. Même si sous 9X ou ME, microsoft avait essayé de cacher le DOS il était toujours là sous Windows.
#32
Bel à priori. NTFS n’est pas dégueux, très versatile. La gestion du stockage permet de faire un équivalent de lvm avec tiering, dédup, cache pilotable pour les sites distants, et tout le toutim dès la licence PME.
L’os dure des années et des années en restant compatible au niveau binaire, a un mode ‘core’ sans gui aussi, un langage de script récent (et compatible linux) et un standard de configuration de poste et serveur dans le domaine qui permet de brancher, joindre, et ne pas s’en soucier (ou presque).
Les unix ont disparu à cause de leur rigidité, linux prospère par les efforts conjoints pour l’optimiser mais reste un bazar à la Doc très problématique (difficile de tomber sur la bonne Doc, à jour)
Parti pris énorme. Je ne sais pas pour as400, mais gérer un parc de windows une fois les idées préconçues des années 90 ôtées, c’est simple, efficace et pas forcément plus cher si on doit payer un support.
C’est de l’expérience vécue 😁. Un gars du support avait imaginé gagner en ‘perf’ en désactivant la defrag. A un moment j’ai mis le nez dans le ‘pourquoi les utilisateurs se plaignent d’ordis que quand je les réinstalle ils sont excellents’
#33
C’est surtout les chemins. Le système de fichier n’a pas de limite depuis 20 ans là-dessus, mais les appels Windows si!
On peut se retrouver dans l’impossibilité de copier des fichiers, les ouvrir, et cela selon l’outil utilisé.
#33.1
Depuis relativement peu tu peux faire sauter la limite de l’API win32 sur la taille des chemins. Un changement à effectuer dans la base de registre. Ou essayer de colle “\?\” devant les noms (je me trompe peut-être de préfixe).
Un article parmis d’autres qui explique comment activer les noms longs.
#34
Ca fonctionne pour les outils système, mais d’autres outils continuent d’avoir des problèmes avec (Office 2016 par exemple, et d’autres)
En gros, tu peux copier, mais par exemple pour décompresser un zip ça fonctionne selon l’outil, idem pour compresser (parfois sans te prévenir que des fichiers n’ont pas été intégrés). Ouvrir une image peut échouer (toujours selon le logiciel).
Ca reste une super plaie, mais c’est pas le FS! C’est bien Windows qui a plusieurs API différentes pour ouvrir un fichier, certaines compatibles “chemins longs”, d’autres pas. C’est encore pire avec les URL (sharepoint online a encore des limites notamment avec office).
#34.1
Quand tu dis que ça ne fonctionne que sur les outils système, tu parles de ça
Depuis l’usage de ce patch je n’ai plus trop de soucis.
D’ailleurs l’article parle de “Windows api” mais sauf erreur de ma part, c’est Win32, les api native et kernel n’ont pas cette limite.
#35
Windows 95 c’était un OS, pour la première fois en multitâche préemptif (+ pas besoin de configurer à la main les interruptions avec les drivers, entre autres), c’était bien plus qu’une surcouche de MS-DOS.
cf ci-dessus.
NTFS est correct, je ne parlais pas de NTFS mais des autres filesystem Microsoft avant.
Après beaucoup d’années ils ont fini par proposer ça, il était temps.
Quelle blague, concernant la doc.
Linux prospère depuis le début grâce à ses qualités techniques et sa rapidité d’évolution et son adaptabilité.
Les Unix ne sont pas rigides, ils ont continué à évoluer, ils sont payants et étaient pas mal liés à du matériel spécifique (mais pas forcément).
Vision un poil idyllique.
ZFS est totalement mûr depuis longtemps (et ultra-puissant si on a besoin de certaines fonctions), Btrfs pendant longtemps c’était pas complètement “sec” mais je n’ai pas regardé depuis au moins un an.
J’ai hésité à choisir XFS par défaut (ce que font certaines distributions), mais je n’ai pas de gros besoins, et ext4 fonctionne très bien pour ce que j’en fais, et les performances sont bonnes.
#35.1
95 et pas configurer les interruptions à la main ? T’as eu du bol ! Moi c’était interruption, DMA, ports… Mais bon, beaucoup de cartes d’extension.
Je crois que win 3.1 était preemptif aussi, il faudrait voir comment on définit un OS, mais sans sa base MS-DOS Win9x ne boitait pas.
#36
D’autres commentaires ont donné des pistes sur les raisons de ce choix, mais il y a aussi un aspect à considérer: sur un clavier Qwerty, le \ a sa propre touche et est donc aussi facile à utiliser que le /, sans avoir à passer par AltGr comme sur un clavier Azerty. Et il en est de même pour d’autres symboles très utilisés en informatique comme [ et ], ou {, }, |, # et @ qui sont accessibles avec un simple Shift.
#37
Niveau doc, Windows coule doucement, mais il y a encore 5 ans avec le technet et le MSDN, c’était facile de trouver la doc et les exemples étaient cohérents. Les mêmes scripts fonctionnent depuis 10 voire 20 ans.
Sous Linux, les scripts ne sont plus toujours compatibles, et ça ne prévient pas.
Niveau doc, j’ai préféré OpenVMS, puis Ms, puis BSD avant de mettre Linux (pas le noyau, les distro, pour le noyau la doc est bien)
Chacun son expérience. Pour moi, Windows est juste derrière VMS en termes de paramétage. Linux pourrait être bien, mais il lui manque l’homogénéité - si on peut choisir la distro, ça va, mais si on doit en subir à cause de presta, c’est la cata.
Il y a je trouve une plus grande homogénéité dans les outils Windows par rapport à Linux où chaque outil est une aventure.
#38
Non, coopératif. Et pour moi Quake ou un navigateur c’est un OS: ça manipule des fichiers, ça abstrait l’ordi de l’environnement d’exécution…
Et c’est les API “W”, en tout cas certaines. Mais les logiciels peuvent avoir limité en amont la taille…
Mais effectivement, ma limite n’est pas dans le FS ou l’OS: https://support.microsoft.com/en-us/office/restrictions-and-limitations-in-onedrive-and-sharepoint-64883a5d-228e-48f5-b3d2-eb39e07630fa
(cherche “File name and path lengths” pour voir à quel point Ms dans certaines divisions n’a pas grandi)
#38.1
J’avais complètement zappé le fait que ça ne concernait que les W. D’un autre côté j’ose espérer que plus personne n’utilise les A (qui de toutes façons ne sont bonnes qu’à forcer des conversions vu que tout ce qui est en dessous est en quelque sorte en W). Je me demande aussi ce que ça donne si tu utilises des caractères pas compatibles avec les A.
Je me demande pourquoi ils ont fait ça. Je suppose qu’il y a un potentiel soucis, mais je ne vois pas lequel. A part le fait que beaucoup de buffers étaient définis dans le genre filename[MAX_PATH] mais c’est valable aussi pour les W.
#39
Les deux cas que j’ai connu pour ça de mon expérience sont soit lié à des scripts écrits pour un shell spécifique (plein de Basheries ou autre), ou les scripts écrits pour une famille de distributions (des scripts pour de la Debian qui ne fonctionneront pas forcément sur de la famille Red Hat à cause de certaines différences de paths et d’intégrations).
C’est pourquoi je recommande toujours de considérer la distribution comme un OS à part (ce qui est d’ailleurs la définition d’une distrib Linux) plutôt que “Linux” seul qui ne veut rien dire.