Przejdź do zawartości

Installable File System

Przejrzana
Z Wikipedii, wolnej encyklopedii

Installable File System (IFS) – architektura systemowa umożliwiająca dynamiczne ładowanie różnych systemów plików podczas uruchamiania systemu operacyjnego zamiast wbudowania ich w jądro[1]. Rozwiązanie to zastosowano między innymi w OS/2[1], PC-DOS 4.x[2], Windows 95[3] i Windows NT[4.1].

Historia

[edytuj | edytuj kod]

IBM i Microsoft rozpoczęły wspólny rozwój OS/2 w ramach umowy Joint Development Agreement zawartej w czerwcu 1985 roku[5][6]. Podczas prac nad tym projektem obie firmy doszły do wniosku, że system plików FAT nie zapewnia funkcji wymaganych przez nowoczesne systemy operacyjne. Skłoniło to Microsoft do opracowania nowego systemu plików HPFS, znanego pod wewnętrznym kryptonimem „Pinball”[7][8]. Zamiast wbudowywać go bezpośrednio w jądro systemu, zdecydowano się zaprojektować mechanizm sterownikowy umożliwiający dodawanie nowych systemów plików bez konieczności modyfikacji systemu operacyjnego[8].

Współpraca ta zakończyła się w kwietniu 1991 roku, gdy na mocy porozumienia rozdzielono dalszy rozwój oprogramowania obu firm[9]. IBM przejęło wyłączną odpowiedzialność za dalsze prace nad OS/2, natomiast Microsoft skoncentrował się na Windows 3.0 i Windows NT[10].

Architektura w OS/2

[edytuj | edytuj kod]

Mechanizm IFS w systemie OS/2 umożliwia wczytywanie i zarządzanie sterownikami systemu plików (z ang. File System Driver, FSD). Są one ładowane za pomocą dyrektywy IFS=, umieszczonej w pliku CONFIG.SYS[11][12][8]. Obsługa systemu plików FAT stanowi wyjątek, ponieważ jest zaimplementowana bezpośrednio w jądrze systemu[1][8]. Woluminy obsługiwane przez sterowniki FSD muszą znajdować się na partycjach typu 7, podczas gdy woluminy FAT są przeznaczone dla partycji typów 1, 4 i 6[12][13].

Przy pierwszym dostępie do woluminu system kolejno wywołuje punkt wejścia FS_MOUNT każdego zainstalowanego sterownika, oczekując na rozpoznanie nośnika przez jeden z nich. Informacje o przypisaniu woluminu do danego sterownika są przechowywane w strukturze danych określanej jako Volume Parameter Block (VPB)[11][14].

Każde urządzenie obsługiwane przez zainstalowany system plików jest prezentowane użytkownikowi jako dysk oznaczony literą, co umożliwia korzystanie z niego przy użyciu standardowych narzędzi systemowych. Wyjątek stanowi mechanizm NetDrive, który łączy funkcje menedżera IFS z interfejsem API. Umożliwia on tworzenie wtyczek pełniących funkcję odrębnych systemów plików, które są ładowane dynamicznie, bez konieczności ponownego uruchamiania systemu[1].

Architektura w PC-DOS 4.x

[edytuj | edytuj kod]

W PC-DOS 4.0 wprowadzono moduł IFSFUNC.EXE, który stanowił próbę uniezależnienia interfejsu redirectora DOS od wewnętrznej implementacji systemu. Miał on zastąpić dotychczasowy mechanizm oparty na wywołaniach INT 2Fh/11h. Wcześniejszy interfejs był silnie powiązany z architekturą DOS, co utrudniało rozwój systemu bez naruszania kompatybilności z istniejącymi redirectorami[15].

IBM nie opublikował jednak dokumentacji modułu IFSFUNC, w związku z czym twórcy redirectorów nadal korzystali z dotychczasowego interfejsu. W rezultacie rozwiązanie nie zostało szerzej przyjęte i usunięto je PC-DOS 5.0[15].

Architektura w Windows 95

[edytuj | edytuj kod]

Jednym z elementów systemu plików w Windows 95 jest Installable File System Manager (IFSMgr)[16.1]. Jest to wirtualny sterownik urządzenia[16.2] odpowiedzialny za kierowanie żądań systemu plików do zainstalowanych sterowników FSD, funkcjonujących jako niezależne komponenty zarządzane przez ten moduł[16.3]. Zarówno IFSMgr, jak i sterowniki systemu plików działają na poziomie uprzywilejowania ring-0 procesora x86. Żądania systemu plików do modułu kierują natomiast klienci działający na poziomie ring-3, do których należą aplikacje DOS Box, Win16 i Win32, a także klienci działający na poziomie ring-0, tacy jak VSERVER czy VWIN32[16.4].

Sterowniki FSD występują w trzech odmianach:

  • lokalnej (np. VFAT), która implementuje reguły konkretnego systemu plików;
  • sieciowej (np. VREDIR), która pakuje żądanie w pakiety i przesyła je przez sieć;
  • znakowej (np. MONOCFSD), która obsługuje urządzenia przesyłające dane szeregowo.

Niezależnie od typu wszystkie sterowniki komunikują się z IFSMgr za pomocą tej samej struktury danych ifsreq oraz wspólnego interfejsu opartego na tablicach funkcji[16.5].

IFSMgr zadebiutował już w Windows for Workgroups 3.11, gdzie implementował znaczną część interfejsu przerwania 21h. W przypadku niepełnej obsługi, na przykład przy użyciu polecenia subst lub obecności napędów DoubleSpace, system automatycznie przełączał się na wolniejszy, 16-bitowy dostęp do plików realizowany przez MS-DOS. Ograniczenie to usunięto dopiero w Windows 95, który zapewniał pełną obsługę obu tych przypadków[16.6]. W tej wersji systemu interfejs przerwania został również rozszerzony poza granicę funkcji 71h, do której dochodził standardowy MS-DOS. Nowe funkcje sięgały aż do E7h i zapewniały obsługę między innymi długich nazw plików[16.7].

Architektura w Windows NT

[edytuj | edytuj kod]

Sterowniki systemu plików w Windows NT są komponentami podsystemu wejścia-wyjścia zgodnymi z interfejsem zdefiniowanym przez NT I/O Manager[4.2]. Interfejs ten określa mechanizmy umożliwiające instalację, załadowanie i rejestrację sterownika w systemie operacyjnym. Dzięki temu wiele systemów plików, w tym rozwiązania opracowywane przez producentów zewnętrznych, mogą funkcjonować jako niezależne komponenty, które można podmieniać i rozszerzać bez przebudowy całego systemu[4.3].

Ten sam interfejs obowiązuje lokalne sterowniki systemu plików, oprogramowanie redirectorów sieciowych i rozproszonych systemów plików, sterowniki pośredniczące, filtrujące oraz sterowniki urządzeń. Wszystkie te komponenty mogą być ładowane do systemu w sposób dynamiczny[4.2]. Do komunikacji z I/O Managerem wykorzystują one wspólną strukturę danych, nazywaną pakietem żądania wejścia-wyjścia (z ang. I/O Request Packet, IRP)[4.4].

Przypisy

[edytuj | edytuj kod]
  1. 1 2 3 4 OS/2 eZine - The Best OS/2 Reading Anywhere! [online], www.os2ezine.com [dostęp 2026-07-13].
  2. ↑ DOS 4.0 | OS/2 Museum [online] [dostęp 2026-07-13] (ang.).
  3. ↑ Installable File Systems [online], techshelps.github.io [dostęp 2026-07-13].
  4. Rajeev Nagar, Windows NT File System Internals: A Developer's Guide, O'Reilly, 1 stycznia 1997, ISBN 978-1565922495 (ang.).
    1. ↑ s. 15
    2. 1 2 s. 29
    3. ↑ s. 32-33
    4. ↑ s. 144
  5. ↑ Computers -- Microsoft, IBM Set Battle Lines -- `Divorce' Is Deeper Than First Thought | The Seattle Times [online], archive.seattletimes.com [dostęp 2026-07-15].
  6. ↑ OS/2 1.0 | OS/2 Museum [online] [dostęp 2026-07-15] (ang.).
  7. ↑ OS/2 Timeline | OS/2 Museum [online] [dostęp 2026-07-15] (ang.).
  8. 1 2 3 4 HPFS [online], pages.cs.wisc.edu [dostęp 2026-07-14].
  9. ↑ Andrew Orlowski, OS/2 a quarter century on: Why IBM lost out and how Microsoft won [online], theregister, 27 listopada 2012 [dostęp 2026-07-15] (ang.).
  10. ↑ OS/2 1.2 and 1.3 | OS/2 Museum [online] [dostęp 2026-07-15] (ang.).
  11. 1 2 Microsoft Corp, Method and system for dynamic volume tracking in an installable file system, wynalazca: Bryan Willman i inni, patent US 5363487A.
  12. 1 2 IPL Mechanism [online], osfree.org [dostęp 2026-07-14].
  13. ↑ Listing of MBR/EBR Partition Types [online], thestarman.pcministry.com [dostęp 2026-07-14].
  14. ↑ miniFSD/OS2KRNL interface [online], osfree.org [dostęp 2026-07-14].
  15. 1 2 DOS 4.0 | OS/2 Museum [online] [dostęp 2026-07-14] (ang.).
  16. Stan Mitchell, Inside the Windows 95 File System, O′Reilly, 1 czerwca 1997, ISBN 1-56592-200-X (ang.).
    1. ↑ s. 1
    2. ↑ s. 2
    3. ↑ s. 4
    4. ↑ s. 5
    5. ↑ s. 6-8
    6. ↑ s. 3-4
    7. ↑ s. 6
Źródło: „https://pl.wikipedia.org/w/index.php?title=Installable_File_System&oldid=80220836”