Uniksowy system plików — Unix File System

System plików Unix ( UFS ) to system plików obsługiwany przez wiele systemów operacyjnych uniksowych i podobnych do Uniksa . Jest odległym potomkiem oryginalnego systemu plików używanego przez Unix w wersji 7 .

Później Berkeley Fast File System (zwany także BSD Fast File System — FFS ) był używany w Uniksach, co nie jest tym samym co UFS.

Projekt

Wolumen UFS składa się z następujących części:

• Kilka bloków na początku partycji zarezerwowanej dla bloków startowych (które muszą być zainicjowane oddzielnie od systemu plików)
• Superblok zawierający magiczną liczbę identyfikującą go jako system plików UFS oraz kilka innych ważnych liczb opisujących geometrię i statystyki tego systemu plików oraz parametry strojenia behawioralnego
• Zbiór grup cylindrów. Każda grupa cylindrów składa się z następujących elementów:
  • Kopia zapasowa superbloku
  • Nagłówek grupy cylindrów ze statystykami, wolnymi listami itp. na temat tej grupy cylindrów, podobny do tych w superbloku
  • Liczba i- węzłów , z których każdy zawiera atrybuty pliku
  • Szereg bloków danych

I-węzły są numerowane sekwencyjnie, zaczynając od 0. I-węzeł 0 jest zarezerwowany dla nieprzydzielonych wpisów katalogu, i-węzeł 1 był i-węzłem pliku uszkodzonego bloku w historycznych wersjach systemu UNIX, po którym następuje i-węzeł katalogu głównego , który zawsze jest i-węzłem 2 i i-węzłem dla zagubionego + znalezionego katalogu, który jest i-węzłem 3.

Pliki katalogów zawierają tylko listę nazw plików w katalogu i i-węzeł skojarzony z każdym plikiem. Wszystkie metadane pliku są przechowywane w i-węźle.

Historia i ewolucja

Wczesne wersje uniksowych systemów plików były nazywane po prostu FS . FS zawierał tylko blok startowy, superblok, grupę i- węzłów i bloki danych. Działało to dobrze w przypadku małych dysków, dla których zaprojektowano wczesne Unixy, ale wraz z postępem technologii i rozmiarami dysków, przesuwanie głowy tam iz powrotem między grupką i-węzłów a blokami danych, o których mówili, powodowało thrashowanie . Marshall Kirk McKusick , wówczas absolwent Berkeley , zoptymalizował FFS (Fast File System) BSD 4.2, wymyślając grupy cylindrów, które dzielą dysk na mniejsze części, przy czym każda grupa ma własne i-węzły i bloki danych.

Intencją BSD FFS jest próba zlokalizowania powiązanych bloków danych i metadanych w tej samej grupie cylindrów i, najlepiej, całej zawartości katalogu (zarówno danych, jak i metadanych dla wszystkich plików) w tej samej lub pobliskiej grupie cylindrów, a zatem zmniejszenie fragmentacji spowodowanej rozproszeniem zawartości katalogu na całym dysku.

Niektóre parametry wydajności w superbloku obejmowały liczbę ścieżek i sektorów, prędkość obrotową dysku, prędkość głowicy i wyrównanie sektorów między ścieżkami. W w pełni zoptymalizowanym systemie głowicę można było przesuwać między bliskimi ścieżkami, aby odczytywać rozproszone sektory z naprzemiennych ścieżek, czekając na obrót talerza.

W miarę jak dyski stawały się coraz większe, optymalizacja na poziomie sektorów stała się przestarzała (zwłaszcza w przypadku dysków wykorzystujących liniową numerację sektorów i zmienne sektory na ścieżkę). W przypadku większych dysków i większych plików pofragmentowane odczyty stały się większym problemem. Aby temu zaradzić, BSD pierwotnie zwiększyło rozmiar bloku systemu plików z jednego sektora do 1 KB w 4.0 BSD; aw FFS zwiększono rozmiar bloku systemu plików z 1 K do 8 K. Ma to kilka efektów. Szansa na to, że sektory pliku będą ciągłe, jest znacznie większa. Ilość narzutu na wylistowanie bloków pliku jest zmniejszona, podczas gdy liczba bajtów reprezentowanych przez daną liczbę bloków jest zwiększona.

Możliwe są również większe rozmiary dysków, ponieważ maksymalna liczba bloków jest ograniczona przez numer bloku o stałej szerokości bitowej. Jednak przy większych rozmiarach bloków dyski z wieloma małymi plikami będą marnować miejsce, ponieważ każdy plik musi zajmować co najmniej jeden blok. Z tego powodu BSD dodało fragmentację na poziomie bloków , zwaną także podalokacją bloków, łączeniem ogonów lub pakowaniem ogonków, gdzie ostatni częściowy blok danych z kilku plików może być przechowywany w jednym bloku „fragmentu” zamiast wielu w większości pustych bloków ( Allena 2005 ).

Realizacje

Sprzedawcy niektórych zastrzeżonych systemów Unix, takich jak SunOS / Solaris , System V Release 4 , HP-UX i Tru64 UNIX , oraz otwartych systemów pochodnych Unix, takich jak illumos , przyjęli UFS. Większość z nich dostosowała UFS do własnych zastosowań, dodając zastrzeżone rozszerzenia, które mogą nie być rozpoznawane przez wersje Uniksa innych producentów. Wiele z nich nadal używa oryginalnego rozmiaru bloku i szerokości pól danych jako oryginalnego UFS, więc pewien stopień zgodności odczytu pozostaje na różnych platformach. Kompatybilność między implementacjami jako całości jest w najlepszym razie niestabilna.

Od Solarisa 7 firma Sun Microsystems włączyła rejestrowanie UFS, które wprowadziło rejestrowanie systemu plików do systemu UFS, które jest nadal dostępne w obecnych wersjach Solarisa i illumos. Solaris UFS ma również rozszerzenia dla dużych plików i dużych dysków oraz inne funkcje.

W wywodzących się z niego systemach 4.4BSD i BSD Unix, takich jak FreeBSD , NetBSD , OpenBSD i DragonFlyBSD , implementacja UFS1 i UFS2 jest podzielona na dwie warstwy: górną warstwę, która zapewnia strukturę katalogów i obsługuje metadane (uprawnienia, własność, itp.) w strukturze i-węzłów i niższych warstwach, które zapewniają kontenery danych zaimplementowane jako i-węzły. Zrobiono to, aby obsługiwać zarówno tradycyjny FFS, jak i system plików o strukturze dziennika LFS ze współdzielonym kodem dla wspólnych funkcji. Górna warstwa nazywa się „UFS”, a dolne warstwy są nazywane „FFS” i „LFS”. W niektórych z tych systemów termin „FFS” jest używany do połączenia dolnej warstwy FFS i górnej warstwy UFS, a termin „LFS” jest używany do połączenia dolnej warstwy LFS i górnej warstwy UFS.

Kirk McKusick zaimplementował realokację bloków, technikę, która zmienia kolejność bloków w systemie plików tuż przed wykonaniem zapisu, aby zmniejszyć fragmentację i kontrolować starzenie się systemu plików. Zaimplementował także miękkie aktualizacje , mechanizm utrzymujący spójność systemu plików bez ograniczania wydajności w sposób, w jaki robił to tradycyjny tryb synchronizacji. Ma to efekt uboczny polegający na zmniejszeniu wymogu sprawdzania systemu plików po awarii lub awarii zasilania. Aby rozwiązać pozostałe problemy po awarii, wprowadzono narzędzie fsck działające w tle.

W UFS2 Kirk McKusick i Poul-Henning Kamp rozszerzyli warstwy FreeBSD FFS i UFS o 64-bitowe wskaźniki blokowe (pozwalające na zwiększenie objętości do 8 zebibajtów ), bloki o zmiennej wielkości (podobne do ekstentów ), rozszerzone pola flag, dodatkowe znaczniki czasu urodzenia, rozszerzona obsługa atrybutów i listy ACL POSIX1.e. UFS2 stał się domyślną wersją UFS począwszy od FreeBSD 5.0. FreeBSD wprowadził również miękkie aktualizacje i możliwość tworzenia migawek systemu plików zarówno dla UFS1, jak i UFS2. Zostały one od tego czasu przeniesione do NetBSD, ale ostatecznie miękkie aktualizacje (nazywane miękkimi zależnościami w NetBSD) zostały usunięte z NetBSD 6.0 na rzecz mniej złożonego mechanizmu księgowania systemu plików zwanego WAPBL (nazywanego również logowaniem), który został dodany do FFS w NetBSD 5.0. OpenBSD obsługuje miękkie aktualizacje od wersji 2.9 i obsługuje UFS2 (FFS2) (bez list ACL) od wersji 4.2. OpenBSD uczynił teraz UFS2 domyślną wersją UFS i będzie dołączany do wydania 6.7. Od FreeBSD 7.0, UFS obsługuje również księgowanie systemu plików przy użyciu dostawcy gjournal GEOM . FreeBSD 9.0 dodaje obsługę lekkiego księgowania wraz z miękkimi aktualizacjami (SU+J), co znacznie zmniejsza potrzebę korzystania z fsck w tle i list ACL NFSv4.

FreeBSD, NetBSD, OpenBSD i DragonFly BSD zawierają również system Dirhash , opracowany przez Iana Dowse. Ten system utrzymuje tablicę mieszającą w pamięci, aby przyspieszyć wyszukiwanie katalogów. Dirhash łagodzi szereg problemów z wydajnością związanych z dużymi katalogami w UFS.

Linux zawiera implementację UFS dla binarnej kompatybilności na poziomie odczytu z innymi Uniksami, ale ponieważ nie ma standardowej implementacji dla rozszerzeń UFS dostawcy, Linux nie ma pełnej obsługi zapisu do UFS. Natywny system plików Linux ext2 został zainspirowany UFS1, ale nie obsługuje fragmentów i nie ma planów wdrażania miękkich aktualizacji. (W niektórych systemach wywodzących się z 4.4BSD warstwa UFS może używać warstwy ext2 jako warstwy kontenera, podobnie jak może używać FFS i LFS.)

NeXTStep , który był wywodzący się z BSD, również używał wersji UFS. W firmy Apple „s Mac OS X , jest on dostępny jako alternatywa dla HFS + , ich własnego systemu plików. Jednak od systemu Mac OS X Leopard instalowanie systemu Mac OS X na woluminie w formacie UFS nie było już możliwe. Ponadto nie można uaktualnić starszych wersji systemu Mac OS X zainstalowanych na woluminach sformatowanych w systemie UFS do wersji Leopard; aktualizacja wymaga ponownego sformatowania woluminu startowego. Obowiązywał limit plików 4 GB dla dysków sformatowanych jako UFS w systemie Mac OS X. W systemie Mac OS X Lion obsługa UFS została całkowicie porzucona.

Zobacz też

• Porównanie systemów plików

Bibliografia

Cytaty

Bibliografia

Zewnętrzne linki

• Jeroen C. van Gelderen (2003-04-23). „Małe często zadawane pytania dotyczące UFS2” . FreeBSD . Pobrano 08.04.2013 .
• "Systemy plików HOWTO: Inne systemy plików" . Projekt Dokumentacji Linuksa . 2007-01-27.
• System plików Solaris UFS , patrz także [1]
• Format USF (sic)/UFS2
• Lokalność i szybki system plików