Le système de fichiers fait-il partie du système d'exploitation?


9

Je me demandais si un système de fichiers sur un périphérique de stockage fait partie du système d'exploitation?

Je ne pense pas. Au lieu de cela, il fait partie du périphérique de stockage et existe en dehors de tout système d'exploitation bien qu'il ait été créé par un système d'exploitation. Ma compréhension est-elle correcte?

Cependant dans Wikipedia :

La plupart des systèmes d'exploitation fournissent un système de fichiers, car un système de fichiers fait partie intégrante de tout système d'exploitation moderne.

Pour LVM, fait-il partie du système d'exploitation? Si oui, alors le système de fichiers virtuel construit sur LVM fait partie du système d'exploitation?


Étant donné que le système d'exploitation lui-même réside dans le système de fichiers, je dirais qu'il fait partie intégrante du système d'exploitation, aucun moyen de le contourner.
Moab

Selon votre raison, la partie OS du système de fichiers n'est-elle pas plus appropriée que l'inverse?
Tim

En fait, je pense qu'un système de fichiers est une exigence du support de stockage, car un système d'exploitation peut résider en mémoire sans utiliser de disque dur ou autre périphérique de stockage.
Moab

Réponses:


10

Le système de fichiers lui-même, représenté par l'ordre physique des informations sur une représentation de stockage, est indépendant du système d'exploitation. Le système d'exploitation contient un pilote qui lui permet de fonctionner avec le système de fichiers. Certains systèmes de fichiers peuvent n'avoir qu'un seul système d'exploitation qui peut lui parler, et ce système a ce système de fichiers codé en dur (pensez au système de fichiers d'origine de Novell NetWare); mais cela n'empêche pas une personne entreprenante d'écrire un tel pilote pour un autre système d'exploitation simplement parce que.

LVM n'est pas un système de fichiers, c'est un gestionnaire de volume. Les gestionnaires de volumes, comme les systèmes de fichiers, s'appuient sur des données stockées sur une présentation de stockage logique pour définir plus précisément comment accéder à ce stockage pour d'autres volumes logiques. Dans le cas de LVM, Linux et les BSD peuvent utiliser le même format de stockage pour leurs implémentations LVM respectives.

Le gestionnaire de volumes Windows est le Dynamic Disk, et certaines personnes entreprenantes ont créé des pilotes Linux pour y accéder.

Si vous deviez prendre un ensemble de disques, installer une sorte de Linux, les configurer avec LVM, installer plusieurs ext3systèmes de fichiers sur les volumes logiques et ensuite placer les disques dans une machine FreeBSD, cette machine FreeBSD serait capable de lire les disques . Probablement. C'est parce que FreeBSD a des pilotes qui comprennent la disposition physique de LVM et ext3, et implémentent la mémoire requise dans le système d'exploitation et les structures d'accès requises pour interagir avec eux.

Les pilotes requis pour interpréter la disposition du stockage sont presque toujours «dans le système d'exploitation», mais la disposition réelle du stockage n'est pas considérée comme telle.


4

J'ai répondu à cela sur ServerFault . Voici à nouveau la réponse:

Le problème ici est le mot "système de fichiers". Dans les mondes POSIX / Unix / Linux, il est utilisé pour signifier plusieurs choses différentes.

  1. Le "système de fichiers" est parfois l'ensemble du système de fichiers, enraciné dans /et tel que présenté aux logiciels d'application par le noyau du système d'exploitation. Dans ce sens, les gens parlent par exemple de systèmes d'exploitation POSIX ayant une " arborescence de systèmes de fichiers unique ".
  2. Un «système de fichiers» est parfois une (ou plusieurs) tranche (s) d'un (ou plusieurs) périphérique (s) de stockage à accès direct ou DASD - une ou plusieurs collections de secteurs de disque contigus formatés en un seul volume avec un format donné - tel que délimité par un schéma de partitionnement de disque. Avec cette signification, les gens parlent, par exemple, de "formatage de mon /usrsystème de fichiers ".
  3. Un "système de fichiers" est parfois une arborescence de fichiers et de répertoires pouvant être jointe, présentée par un pilote de système de fichiers (c'est-à-dire la couche VFS) au reste du système. Avec cette signification, les gens parlent, par exemple, de "monter le système de fichiers proc/proc ".

La prose de Wikipédia signifie # 1. Cela fait en effet partie du système d'exploitation, car il s'agit d'un système d'exploitation fourni et d'une abstraction spécifique au système d'exploitation fournie aux logiciels d'application qui s'exécutent sur le système d'exploitation.

Signification # 2 ne fait pas partie du système d'exploitation. Il s'agit d'une structure de données sur disque qu'un ou plusieurs systèmes d'exploitation sont capables de comprendre. Les structures de données sur disque pour LVM, en particulier, permettent de découper un ou plusieurs DASD en un ou plusieurs volumes. Ils ne font pas partie du système d'exploitation en soi. (Mais, de la même manière, «LVM» a plusieurs significations et peut signifier les pilotes LVM et les utilitaires dans le système d'exploitation autant qu'il peut signifier les structures de données sur disque que ces pilotes et utilitaires manipulent. Par exemple, «J'ai exécuté LVM à partir du disque de secours. ")

Signification # 3 est une abstraction spécifique au système d'exploitation fournie par les pilotes de système de fichiers spécifiques au système d'exploitation. Les pilotes du système de fichiers font en effet partie du système d'exploitation, bien qu'ils soient généralement distincts et séparés du noyau du système d' exploitation .


2

Un système de fichiers est créé, maintenu et utilisé par un système d'exploitation, mais vous avez raison de conclure que sa représentation peut exister indépendamment d'un système d'exploitation.


Toutes les réponses valent la peine, celle-ci est la principale à retenir.
conner.xyz

2

Il n'y a pas de définition formelle de "système d'exploitation". Certains avaient l'habitude de maintenir que «système d'exploitation» et «API de gestion de fichiers» étaient une seule et même chose, le système d'exploitation n'ayant rien d'autre à faire que de fournir un analyseur de commandes. (Après tout, c'est tout ce que MS-DOS a fait, à l'origine.)

J'ai toujours soutenu que DOS n'était pas un vrai système d'exploitation - que le travail d'un système d'exploitation était d'abstraire et de virtualiser le matériel, et de gérer les ressources matérielles. DOS n'a pratiquement rien fait de tout cela.

Quant à savoir si un système de fichiers est une partie de l'OS ou une partie du "périphérique de stockage", beaucoup dépend à son tour de ce que vous entendez par "système de fichiers". Il y a la disposition physique, telle que la disposition sur une disquette ou un CD, et il y a le système de fichiers FUNCTION, qui dépend d'avoir une entité intelligente (CPU ou processeur périphérique quelconque) pour prendre le non-sens sur le disque et retourner comme une séquence significative d'octets. La disposition est vraisemblablement conforme à une norme, vous pouvez donc, par exemple, enregistrer un CD sur un appareil et le lire / lire sur un autre. La question est de savoir si cette disposition est un "système de fichiers", ou si le "système" réside dans les appareils suffisamment intelligents pour lire / écrire la disposition.

Dans la plupart des contextes informatiques, on utilise le terme "système de fichiers" pour désigner les API qui vous permettent de lire / écrire des fichiers, et la combinaison de CPU et de périphériques, fonctionnant sous le contrôle de certains systèmes d'exploitation, qui implémentent ces API - le terme ne fait généralement pas référence au format physique du support ou aux supports individuels, amovibles ou non.


Points intéressants.
Maxpm

Même sous MS-DOS, le système d'exploitation l'était MSDOS.SYSet le shell de ligne de commande l'était COMMAND.COM.
user1686

1

L' implémentation particulière fait partie du système d'exploitation. L'idée abstraite, les spécifications et les données stockées ne le sont pas.


1

Les lecteurs de disque et les périphériques de type lecteur de disque sont «stupides». Vous lui demandez un LBA, il vous rend les 512, 2048 ou 4096 octets qu'il contient; vice versa pour l'écriture.

Une couche de système de fichiers vous permet de dire "Je veux c: \ users \ public \ documents \ quelquechose.doc" et d'effectuer des opérations de streaming sur cela (ouvrir, lire, écrire, rechercher, fermer) - elle se traduit à partir d'emplacements adressables par nom en une série des demandes de lecture / écriture des LBA.

La couche du système de fichiers a donc deux côtés, l'un qui communique avec le périphérique de type lecteur de disque (ou bloc) et l'autre qui communique avec le système d'exploitation. C'est là que la spécificité du système d'exploitation entre en jeu. Habituellement, le côté périphérique de bloc du système de fichiers est un pilote de périphérique et le côté système d'exploitation est une API utilisable par les applications. Mais ce ne sont que des interfaces et n'ont pas vraiment à affecter le fonctionnement sous-jacent de la couche du système de fichiers.

Tous les systèmes de fichiers entraînent l'écriture et la lecture de données supplémentaires en dehors des données de fichier, afin de garder une trace des informations sur les fichiers, c'est-à-dire d'enregistrer les autorisations, les attributs, etc.

Il y a un peu de problème de démarrage avec le poulet - comme les fichiers du système d'exploitation sont stockés sur le système de fichiers, mais comment sont-ils chargés si la couche du système de fichiers n'est pas encore active? Linux résout ce problème avec un disque RAM initial ou en intégrant le code du système de fichiers dans le cadre du noyau. Windows résout ce problème en donnant au chargeur de démarrage Windows la possibilité de lire les partitions FAT et NTFS. Les chargeurs de démarrage peuvent être stupides, comme la plupart des chargeurs de démarrage BIOS classiques qui ne chargent que LBA 0 et l'exécutent et s'attendent à ce que le code soit récupéré par la suite, ou assez intelligent et avec de petites couches de système de fichiers qui leur sont propres, telles que UEFI, U-boot, etc.

LVM n'est pas un système de fichiers. Il prend un ou plusieurs périphériques de bloc et l'abstrait dans un autre périphérique de bloc "virtuel" (dans /dev/mapper- tout ce qui /dev/mapperest dans est un périphérique de bloc virtuel). Vous placez un système de fichiers "au-dessus" d'un LVM de la même manière que vous mettriez un système de fichiers "au-dessus" d'une partition. LVM est une autre couche entre un ou plusieurs pilotes de périphérique et le système de fichiers, convertissant les lectures et les écritures en LBA sur le périphérique de bloc virtuel en un ou plusieurs autres périphériques de bloc. Oui, un LVM peut être un périphérique de bloc virtuel et vous pouvez en avoir une cascade.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.