Filer-11

Files-11 är filsystemet som används av Digital Equipment Corporation OpenVMS operativsystem , och även (i en enklare form) av den äldre RSX-11 . Det är ett hierarkiskt filsystem, med stöd för åtkomstkontrollistor , postorienterad I /O , fjärrnätverksåtkomst och filversionshantering .

Files-11 liknar, men är betydligt mer avancerad än, filsystemen som används i tidigare Digital Equipment Corporation- operativsystem som TOPS-20 och RSTS/E .

Historia

Det ursprungliga OpenVMS-filsystemet härstammar från äldre DEC-operativsystem och liknar på många sätt, båda har designats av Dave Cutler . En stor skillnad är layouten på kataloger. Dessa filsystem gav alla någon form av rudimentär icke-hierarkisk katalogstruktur, vanligtvis baserad på att tilldela en katalog per användarkonto. Under RSTS/E representerades varje användarkonto av två nummer, ett [ projekt , programmerare ] -par, och hade en associerad katalog. Särskilda systemfiler, såsom programkörbara filer och själva operativsystemet, lagrades i katalogen för ett reserverat systemkonto.

Även om detta var lämpligt för PDP-11- system, som hade begränsad permanent lagringskapacitet, krävde VAX -system med mycket större hårddiskar en mer flexibel metod för fillagring: hierarkisk kataloglayout i synnerhet, den mest anmärkningsvärda förbättringen i ODS-2.

Översikt

"Files-11" är den allmänna termen för fem separata filsystem, kända som on-disk structure (ODS) nivåer 1 till 5.

ODS-1 är det platta filsystemet som används av RSX-11 OS, som stöds av äldre VMS- system för RSX-kompatibilitet, men som aldrig används för att stödja själva VMS; den har i stort sett ersatts av ODS-2 och ODS-5.

ODS-2 är det vanliga VMS-filsystemet och förblir det vanligaste filsystemet för systemdiskar (disken som operativsystemet är installerat på).

Även om de sällan hänvisas till med sina ODS-nivåbeteckningar, är ODS-3 och ODS-4 Files-11-stöd för CD-ROM ISO 9660 respektive High Sierra Format filsystem.

ODS-5 är en utökad version av ODS-2 tillgänglig på Alpha- och IA-64- plattformar som lägger till stöd för skiftlägesbevarande filnamn med icke- ASCII -tecken och förbättringar av det hierarkiska katalogstödet. Det var ursprungligen avsett för filservering till Microsoft Windows eller andra icke-VMS-system som en del av NT-affinitetsprojektet , men används även på användardiskar och Internetservrar .

Kataloglayout

En typisk Files-11-kataloghierarki: alla filer är rotade i Master File Directory; Fil2 finns i två kataloger

Alla filer och kataloger i ett Files-11-filsystem finns i en eller flera överordnade kataloger , och så småningom under rotkatalogen, huvudfilkatalogen ( se nedan). Filsystemet är därför organiserat i en riktad acyklisk grafstruktur ( DAG) .

I det här exemplet ( se höger ) har fil 2 en katalogpost under både Dir 2 och Dir 3 ; det är "i" båda katalogerna samtidigt. Även om den tas bort från en, skulle den fortfarande finnas i den andra katalogen tills den också tas bort därifrån. Detta liknar konceptet med hårda länkar i UNIX , även om man måste se till att filen faktiskt inte raderas på diskar som inte är inställda för hårda länkar (endast tillgängligt på ODS-5-diskar, och då endast om disken har hårda länkar aktiverade).

Diskorganisation och namngivning

Ett operativt VMS-system har tillgång till en eller flera onlinediskar, som var och en innehåller ett komplett, oberoende filsystem. Dessa är antingen lokal lagring eller, i fallet med ett kluster, lagring som delas med fjärrsystem.

Figur 1 : Exempel på OpenVMS-klusterdiskkonfiguration

I en OpenVMS-klusterkonfiguration delas icke-privata diskar mellan alla noder i klustret ( se figur 1) . I den här konfigurationen är de två systemdiskarna tillgängliga för båda noderna via nätverket, men den privata disken delas inte: den monteras endast för användning av en viss användare eller process på den maskinen. Åtkomst till filer över ett kluster hanteras av OpenVMS Distributed Lock Manager, en integrerad del av filsystemet.

Flera diskar kan kombineras för att bilda en enda stor logisk disk eller volymuppsättning . Diskar kan också replikeras automatiskt till skugguppsättningar för datasäkerhet eller snabbare läsprestanda.

En disk identifieras antingen med sitt fysiska namn eller (oftare) av ett användardefinierat logiskt namn. Till exempel kan startenheten (systemdisken) ha det fysiska namnet $3$DKA100 , men den hänvisas i allmänhet till med det logiska namnet SYS$SYSDEVICE .

Filsystemen på varje disk (med undantag för ODS-1) är hierarkiska. Ett fullständigt specificerat filnamn består av ett nodnamn, ett användarnamn och lösenord, ett enhetsnamn, katalog, filnamn, filtyp och ett versionsnummer, i formatet:

NODE"kontonamn lösenord"::enhet:[katalog.underkatalog]filnamn.typ;ver

Till exempel hänvisar [DIR1.DIR2.DIR3]FILE.EXT till den senaste versionen av FILE.EXT , på den aktuella standarddisken, i katalogen [DIR1.DIR2.DIR3] .

DIR1 är en underkatalog till huvudfilkatalogen (MFD), eller rotkatalogen , och DIR2 är en underkatalog till DIR1 . En disks MFD identifieras med [000000] .

De flesta delar av filnamnet kan utelämnas, i vilket fall de är hämtade från den aktuella standardfilspecifikationen . Standardfilspecifikationen ersätter konceptet "nuvarande katalog" i andra operativsystem genom att tillhandahålla en uppsättning standardinställningar för nod, enhetsnamn och katalog. Alla processer har en standardfilspecifikation som inkluderar disknamn och katalog, och de flesta VMS-filsystemrutiner accepterar en standardfilspecifikation som även kan inkludera filtypen; TYPE - kommandot, till exempel, har som standard " .LIS " som filtyp, så kommandot TYPE F , utan tillägg, försöker öppna filen F.LIS .

Varje fil har ett versionsnummer, som är standard till 1 om inga andra versioner av samma filnamn finns (annars en högre än den största versionen). Varje gång en fil sparas, istället för att skriva över den befintliga versionen, skapas en ny fil med samma namn men ett ökat versionsnummer. Gamla versioner kan raderas explicit, med DELETE eller PURGE , eller valfritt kan äldre versioner av en fil raderas automatiskt när filens versionsgräns nås (ställs in av SET FILE/VERSION_LIMIT ). Gamla versioner skrivs alltså inte över, utan lagras på disk och kan hämtas när som helst. Den arkitektoniska gränsen för versionsnummer är 32767. Versionsbeteendet åsidosätts lätt om det är oönskat. I synnerhet filer som uppdateras direkt, såsom databaser, skapar inte nya versioner om de inte är explicit programmerade.

ODS-2 är begränsad till åtta nivåer av underkataloger, och endast versaler, alfanumeriska namn (plus understreck, bindestreck och dollartecken) upp till 39,39 tecken (39 för filnamnet och ytterligare 39 för tillägget). ODS-5 utökar teckenuppsättningen till små bokstäver och de flesta andra utskrivbara ASCII-tecken, samt ISO Latin-1- och Unicode -tecken, ökar den maximala filnamnslängden och tillåter obegränsade nivåer av underkataloger. När man konstruerar ett sökvägsnamn för en ODS-5-fil som använder tecken som inte är tillåtna enligt ODS-2, används en speciell "^"-syntax för att bevara bakåtkompatibilitet; filen " file.tar.gz;1 " på en ODS-5-skiva, till exempel, skulle hänvisas till som " file^.tar.gz "— filens namn är " file.tar ", och filtillägget är " .gz ".

Filsäkerhet: skydd och ACL:er

VMS-filsäkerhet definieras av två mekanismer, UIC-baserad åtkomstkontroll och ACL -baserad åtkomstkontroll. UIC-åtkomstkontroll baseras på ägaren av filen och UIC, eller användaren, får åtkomst till filen. Åtkomsten bestäms av fyra grupper av behörigheter:

Format för filskyddsvisning; behörigheter som inte har beviljats visas inte

Systemet
Ägare
Grupp
Värld

Och fyra behörighetsbitar:

Läsa
Skriva
Kör
Radera

"System"-åtkomsten gäller för alla användare vars UIC-gruppkod är mindre än eller lika med SYSGEN- parametern MAXSYSGROUP (vanligtvis 8 eller 10 oktal ) (till exempel SYSTEM- användaren); "ägare" och "grupp" gäller för ägaren av filen och den användarens användargrupp, och "värld" gäller för alla andra användare. Det finns också en femte behörighetsbit, "Kontroll", som används för att bestämma åtkomst för att ändra filmetadata såsom skydd. Denna grupp kan inte ställas in explicit; den är alltid inställd på System och Ägare, och aldrig för Group eller World.

UIC-baserad åtkomstkontroll påverkas också av fyra systemprivilegier, som gör att användare som håller dem kan åsidosätta åtkomstkontroller:

BYPASS : användaren har implicit RWED-åtkomst till alla filer, oavsett filskydd;
READALL : användaren har implicit R-åtkomst till alla filer;
SYSPRV : användaren kan komma åt filer baserade på systemskydd;
GRPPRV : användare kan komma åt filer baserat på systemskydd om deras UIC-grupp matchar filens grupp.

ACL:er tillåter att ytterligare privilegier tilldelas på en användar- eller gruppspecifik basis; till exempel kan en webbservers UIC ges läsbehörighet till alla filer i en viss katalog. ACL:er kan markeras som ärvda , där en katalogfils ACL gäller för alla filer under den. ACL:er modifieras med EDIT/ACL och tar formen av identifierare/åtkomstpar. Till exempel ACL-posten

(IDENTIFIER=HTTP$SERVER,ACCESS=READ+EXECUTE)

skulle tillåta användaren HTTP$SERVER att läsa och köra filen.

Logiska namn

Ett logiskt namn är en systemvariabel som kan referera till en disk, katalog eller fil, eller innehålla annan programspecifik information. Till exempel innehåller den logiska SYS$SYSDEVICE systemets startenhet. Ett logiskt namn refererar normalt till en enda katalog eller disk, t.ex. SYS$LOGIN: som är användarens inloggningskatalog (eller kataloger); dessa logika kan inte användas som riktiga disknamn— SYS$LOGIN:[DIR]FILE är inte en giltig filspecifikation. Dock kan dolda logiska namn, definierade av DEFINE/TRANSLATION=CONCEALED , användas på det sättet; dessa rotade kataloger definieras med en efterföljande "." på katalogspecifikationen, alltså

 $ DEFINE/TRANS=DÖM HEMDISK$ANVÄNDARE:[  användarnamn  .]

skulle tillåta HOME:[DIR]FILE att användas. Vanligare är enkla logik som pekar på specifika kataloger som är associerade med viss applikationsprogramvara som kan finnas på vilken disk eller vilken katalog som helst. Därför kan logiska ABC_EXE peka på en katalog med körbara program för applikation ABC och ABC_TEMP kan peka på en katalog med temporära filer för samma applikation och denna katalog kan finnas på samma disk och i samma katalogträd som ABC_EXE eller kan vara någonstans på en annan disk (och i ett annat katalogträd).

På ett sätt som liknar Unix, definierar VMS flera standardin- och utgångskanaler som nås via de logiska namnen SYS$INPUT , SYS$OUTPUT , SYS$ERROR och SYS$COMMAND .

Logiska namn har inte en nära motsvarighet i POSIX-operativsystem. De liknar Unix- miljövariabler , förutom att de utökas av filsystemet, istället för kommandoskalet eller applikationsprogrammet. De måste definieras före användning, så det är vanligt att många logiska namn definieras i kommandofilen för systemstart, såväl som kommandofiler för användarinloggning. I VMS kan logiska namn referera till andra logiska namn (upp till en fördefinierad kapslingsgräns på 10) och kan innehålla listor med namn för att söka efter ett befintligt filnamn. Några ofta refererade logiska namn är:

logiskt namn	menande
`SYS$INPUT`	standardinmatning - används interaktivt, detta representerar terminalens tangentbord. Används i en batchfil, läser den batchfilrader som inte föregås av en $-symbol, eller specificeras som ett indatakort med kommandot DECK `.`
`SYS$OUTPUT`	standardutgång - den kommer att matas ut till terminaldisplayen eller batchloggfilen beroende på om processen är interaktiv eller inte.
`SYS$FEL`	standardfel - det kommer att skickas till terminaldisplayen eller batchfelloggfilen beroende på om processen är interaktiv eller inte.
`SYS$COMMAND`	källa för batchfilkommandon. Den kommer att läsa från terminalen eller SYS$INPUT-strömmen beroende på om processen är interaktiv eller inte.
`TT`	terminalen som är associerad med processen
`SYS$PRINT`	standardskrivaren eller utskriftskön
`SYS$LOGGA IN`	hemkatalog för varje användare
`SYS$SCRATCH`	temporary folder , katalog för temporära filer
`SYS$SYSTEM`	katalog som innehåller de flesta systemprogram och några viktiga datafiler, såsom systemauktoriseringsfilen (konton och lösenord)
`SYS$SHARE`	delade runtime-bibliotek, körbara filer, etc.
`SYS$LIBRARY`	system och tillagda bibliotek

Det närmaste icke-DEC-operativsystemet för att stödja konceptet med logiska namn är AmigaOS , genom kommandot ASSIGN . AmigaOS skivoperativsystem, AmigaDOS , som är en port för TRIPOS , har en viss likhet med DEC-operativsystem. Till exempel följer fysiska enhetsnamn ett mönster som DF0: för den första disketten, CDROM2: för den 3:e CD-ROM-enheten, etc. Men eftersom systemet kan starta från vilken ansluten enhet som helst, skapar operativsystemet tilldelningen SYS: för att automatiskt referera till den startenhet som används. Övriga uppdrag, LIBS:, PREFS:, C:, S:, et al. görs också, själva refererade från SYS:. Användare får naturligtvis också skapa och förstöra sina egna uppdrag.

Record-oriented I/O: Record Management Services

Record Management Services är det strukturerade I/O- skiktet i VMS-operativsystemet. RMS tillhandahåller omfattande programstöd för hantering av strukturerade filer , såsom postbaserade och indexerade databasfiler . VMS-filsystemet, tillsammans med RMS, utökar åtkomsten till filer förbi enkla byte -strömmar och tillåter OS-nivå stöd för en mängd olika rika filtyper. Varje fil i VMS-filsystemet kan ses som en databas som innehåller en serie poster , som var och en har ett eller flera individuella fält . En textfil, till exempel, är en lista över poster (rader) separerade med ett nyradstecken. RMS är ett exempel på ett postorienterat filsystem .

Det finns fyra postformat som definieras av RMS:

Fast längd - alla poster i filen har samma längd.
Variabel längd - poster varierar i längd, och varje post föregås av en räknebyte som anger dess längd.
Variabel skivlängd med kontroll med fast längd - poster varierar i längd, men föregås av ett kontrollblock med fast längd.
Stream - posten varierar i längd, och varje post är separerad från nästa med ett avslutningstecken. En textfil är ett exempel på en fil i strömformat som använder radmatning eller vagnretur till separata poster.

Det finns fyra metoder för poståtkomst eller metoder för att hämta befintliga poster från filer:

Sekventiell åtkomst - börjar med en viss post, efterföljande poster hämtas i ordning till slutet av filen.
Relativt postnummeråtkomst - poster hämtas via ett postnummer i förhållande till början av filen.
Record File Address Access - poster hämtas direkt efter deras plats i filen (RFA eller Record File Address).
Indexerad åtkomst – poster hämtas via en nyckel, i form av nyckel-värde-mappning .

Fysisk layout: On-Disk-strukturen

På disknivå representerar ODS filsystemet som en array av block , ett block är 512 sammanhängande byte på en fysisk disk ( volym ). Diskblock tilldelas i kluster (ursprungligen 3 sammanhängande block men utökades senare med större diskstorlekar). En fil på disken kommer helst att vara helt sammanhängande, dvs blocken som innehåller filen kommer att vara sekventiella, men diskfragmentering kräver ibland att filen placeras i osammanhängande kluster i vilket fall fragmenten kallas för utsträckningar . Diskar kan kombineras med andra diskar för att bilda en volymuppsättning och filer lagrade var som helst på den uppsättningen diskar, men större diskstorlekar har minskat användningen av volymuppsättningar eftersom hanteringen av en enda fysisk disk är enklare.

Varje fil på en Files-11-disk (eller volymuppsättning) har en unik filidentifikation (FID), som består av tre nummer: filnumret (NUM), filsekvensnumret (SEQ) och det relativa volymnumret (RVN) . NUMRET anger var i INDEXF.SYS (se nedan) metadata för filen finns; SEQ är ett generationsnummer som ökar när filen raderas och en annan fil skapas genom att återanvända samma INDEXF.SYS-post (så att alla hängande referenser till den gamla filen inte av misstag pekar på den nya); och RVN indikerar volymnumret som filen är lagrad på när en volymuppsättning används.

Kataloger

Det strukturella stödet för en ODS-volym tillhandahålls av en katalogfil — en speciell fil som innehåller en lista med filnamn, filversionsnummer och deras tillhörande FID, liknande VSAM-kataloger på MVS . I roten av katalogstrukturen finns huvudfilkatalogen ( MFD), rotkatalogen som innehåller (direkt eller indirekt) varje fil på volymen.

Det här diagrammet visar ett exempel på en katalog som innehåller 3 filer, och hur varje filnamn mappas till INDEXF.SYS- posten (varje INDEXF-post innehåller mer information; endast de första objekten visas här).

Master File Directory

På den översta nivån i ett ODS-filsystem finns huvudfilkatalogen (MFD), som innehåller alla katalogfiler på toppnivå (inklusive sig själv), och flera systemfiler som används för att lagra filsysteminformation. På ODS-1-volymer används en katalogstruktur på två nivåer: varje användaridentifikationskod (UIC) har en tillhörande användarfilkatalog (UFD), av formen [GROUP.USER] . På ODS-2 och senare volymer är layouten av kataloger under MFD friform, med förbehåll för en gräns för kapsling av kataloger (8 nivåer på ODS-2 och obegränsad på ODS-5). På uppsättningar med flera volymer lagras MFD alltid på den första volymen och innehåller underkatalogerna för alla volymer.

Följande systemfiler finns i ODS MFD:

INDEXF.SYS;1 —Indexfil
BITMAP.SYS;1 — Lagringsbitmappsfil
BADBLK.SYS;1 —Dålig blockfil
000000.DIR;1 — Själva MFD-katalogfilen
CORIMG.SYS;1 — Kärnbildsfil
VOLSET.SYS;1 — Volymuppsättningslistafil (endast ODS-2/5)
CONTIN.SYS;1 – Fortsättningsfil (endast ODS-2/5)
BACKUP.SYS;1 – Backup-loggfil (endast ODS-2/5)
BADLOG.SYS;1 — Väntande dåligt block (endast ODS-2/5)
SECURITY.SYS;1 — Volymsäkerhetsprofil (endast ODS-2/5)
QUOTA.SYS;1 — Kvotfil (valfritt och endast tillgängligt under ODS-2/5)
GPT.SYS;1 —GUID Partitioning Table (GPT) (OpenVMS I64 EFI-startstrukturer, valfritt på OpenVMS Alpha)

Observera att själva filsystemimplementeringen inte refererar till dessa filer med namn, utan med deras fil-ID, som alltid har samma värden. Således är INDEXF.SYS alltid filen med NUM = 1 och SEKV = 1.

Indexfil: INDEXF.SYS

Indexfilen innehåller den mest grundläggande informationen om en Files-11-volymuppsättning.

Det finns två organisationer av INDEXF.SYS, den traditionella organisationen och den organisation som används på diskar med GPT.SYS; med GUID Partition Table (GPT) strukturer.

Med den traditionella organisationen är block 1 startblocket , som innehåller platsen för den primära bootstrap-avbildningen , som används för att ladda VMS-operativsystemet. Denna finns alltid vid logiskt block 0 på disken, så att hårdvarans fasta programvara kan läsa den. Detta block är alltid närvarande, även på icke-systemvolymer (icke startbara).

Efter startblocket är det primära hemblocket . Detta innehåller volymnamnet , platsen för omfattningarna som omfattar resten av indexfilen, volymägarens UIC och volymskyddsinformationen . Det finns normalt flera ytterligare kopior av hemblocket, så kallade sekundära hemblock , för att möjliggöra återställning av volymen om den tappas bort eller skadas.

På diskar med GPT.SYS innehåller GPT.SYS motsvarigheten till startblocket (känd som Master Boot Record (MBR)), och det finns inget primärt hemblock. Alla hemblock som finns på en GPT-baserad disk är alternativa hemblock. Dessa strukturer ingår inte i INDEXF.SYS, och blocken i INDEXF.SYS-filen är oanvända.

Resten av indexfilen består av filhuvuden , som beskriver omfattningen som allokeras till filerna som finns på volymen, och filmetadata som ägarens UIC, ACL:er och skyddsinformation. Varje fil beskrivs av en eller flera filhuvuden – mer än en kan krävas när en fil har ett stort antal omfattningar. Filhuvudet är ett block med fast längd, men innehåller både sektioner med fast och variabel längd:

Rubriken innehåller NUM och SEQ, skyddsinformationen (säkerhets ) och platsen för resten av filhuvudet.
Ident - sektionen innehåller redovisningsmetadata: filnamn, skapelse- och ändringstider och tidpunkten för den senaste säkerhetskopieringen.
Kartan beskriver vilka fysiska diskblock (omfattningar) som mappas till varje virtuellt block i filen .
Åtkomstkontrolllistan innehåller ACL-informationen för filen .
Det reserverade området är utrymme i slutet av filhuvudet som inte används av operativsystemet. Detta kan användas av för kund- eller leverantörsspecifik information.
De två sista byten i rubriken är en kontrollsumma av de föregående 255 orden, för att verifiera giltigheten av rubriken.

Om möjligt finns kart- och ACL-sektionerna i rubriken helt och hållet i den primära rubriken . Men om ACL är för lång, eller filen innehåller för många omfattningar, kommer det inte att finnas tillräckligt med utrymme i den primära rubriken för att lagra dem. I detta fall tilldelas en förlängningsrubrik för att lagra överflödesinformationen.

Layout av INDEXF.SYS -huvudet.

Filhuvudet börjar med 4 förskjutningar ( IDOFFSET , MPOFFSET , ACOFFSET och ROFFSET ). Eftersom storleken på områdena efter rubriken med fast längd kan variera (som kartan och ACL-områdena), krävs förskjutningar för att lokalisera dessa ytterligare områden. Varje förskjutning är antalet 16-bitars ord från början av filhuvudet till början av det området.

Om filen kräver flera rubriker, innehåller tilläggssegmentnumret ( SEGNUM ) sekvensnumret för denna rubrik, med början på 0 i den första posten i INDEXF.SYS.

STRUCLEV innehåller den aktuella strukturnivån (i den höga byten) och versionen (i den låga byten) av filsystemet; ODS-2 är strukturnivå 2. En ökning av versionsnumret indikerar en bakåtkompatibel förändring som äldre programvara kan ignorera; förändringar i själva strukturnivån är oförenliga.

W_FID (som innehåller tre värden: FID_NUM , FID_SEQ och FID_RVN , motsvarande filen, sekvensen och det relativa volymnumret) innehåller ID för denna fil; EXT_FID (återigen sammansatt av tre värden) håller platsen för nästa tilläggshuvud, om någon. I båda dessa värden är RVN specificerad som 0 för att representera den "aktuella" volymen (0 är normalt inte ett giltigt RVN).

FILECHAR innehåller flera flaggor som påverkar hur filen hanteras eller organiseras:

NOBACKUP gör att den här filen ignoreras när en säkerhetskopiering körs.
WRITEBACK möjliggör cachad (fördröjd) skrivning till filen.
READCHECK gör att alla läsningar av filen görs två gånger och jämförs för att säkerställa dataintegritet.
WRITCHECK resulterar i att alla skrivningar verifieras genom en efterföljande läsning och jämförelse.
CONTIGB gör att operativsystemet försöker allokera lagring för filen på ett så sammanhängande sätt som möjligt.
LÅST är inställt om filen är oåtkomstlåst. Om inställt indikerar detta att filen inte stängdes ordentligt efter den senaste användningen och att innehållet kan vara inkonsekvent.
CONTIG indikerar att filen är lagrad kontinuerligt på disken; det vill säga varje virtuellt block $i$ mappas till det logiska (fysiska) blocket $i+k$ , för någon konstant $k$ .
BADACL ställs in om filen har en ogiltig åtkomstkontrolllista.
SPOOL ställs in om filen är en spoolfil, till exempel en mellanfil som används under utskrift.
DIRECTORY ställs in om filen är en katalog.
BADBLOCK ställs in om filen innehåller dåliga block.
MARKDEL ställs in om filen har markerats för radering men fortfarande används; den kommer att raderas när den stängs av den senaste användaren.
NOCHARGE , om den är inställd, gör att utrymme som används av filen inte tas från ägarens lagringskvot.
ERASE gör att filens innehåll skrivs över när den raderas.

ACCMODE beskriver den behörighetsnivå på vilken en process måste köras för att få åtkomst till filen. VMS definierar fyra behörighetsnivåer: användare, supervisor, exec och kärna. Varje typ av åtkomst - läsa, skriva, köra och ta bort - är kodad som ett 2-bitars heltal.

FILEPROT innehåller den diskretionära åtkomstkontrollinformationen för filen. Den är uppdelad i 4 grupper om 4 bitar vardera: system, ägare, grupp och värld. Bit 0 motsvarar läsbehörighet, 1 för att skriva, 2 för att utföra och 3 för att radera. Att sätta en bit nekar en viss åtkomst till en grupp; rensa det tillåter det.

Om filhuvudet är ett tilläggshuvud, innehåller BACKLINK fil-ID:t för den primära rubriken; annars innehåller den fil-ID:t för katalogfilen som innehåller den primära posten för filen.

Andra filer

Lagringsbitmappsfil: BITMAP.SYS

Bitmappsfilen ansvarar för att lagra information om använt och tillgängligt utrymme på en volym. Den innehåller lagringskontrollblocket (SCB), som inkluderar sammanfattningsinformation som beskriver ???, och bitmappen, en uppsättning bitar för att indikera om ett kluster av block på disken är ledigt eller allokerat. I tidiga versioner av VMS bestod klustret av 3 block, men allt eftersom diskstorlekarna har ökat, har klustrets storlek också ökat.

Dålig blockfil: BADBLK.SYS

Den dåliga blockfilen innehåller alla kända dåliga block på den fysiska volymen. Syftet är att förhindra att systemet allokerar dem till filer. Den här filen användes mer under de tidiga dagarna när diskar vanligtvis tillverkades med fler dåliga fläckar på ytan.

Volymuppsättningslistfil: VOLSET.SYS

Volymuppsättningslistan finns på volym 1 av en volymuppsättning och innehåller en lista med etiketter för alla volymer i uppsättningen och uppsättningens volymnamn.

Fortsättningsfil: CONTIN.SYS

När en fil på en uppsättning med flera volymer korsar gränsen för två ingående volymer, används fortsättningsfilen som dess tilläggshuvud och beskriver volymen där resten av filen kan hittas.

Kvotfil: QUOTA.SYS

Kvotfilen innehåller information om varje UIC:s diskutrymmesanvändning på en volym. Den innehåller en post för varje UIC med utrymme tilldelat på en volym, tillsammans med information om hur mycket utrymme som används av den UIC. OBS: Funktionen DISKQUOTA är valfri och filen kommer bara att existera om funktionen någonsin har aktiverats.

Volymsäkerhetsprofil: SECURITY.SYS

Volymsäkerhetsprofilen innehåller volymens ägare-UIC, volymskyddsmasken och dess åtkomstkontrolllista.

GUID-partitioneringstabell: GPT.SYS

Den här filen överlagrar och skyddar skivstrukturerna MBR (Master Boot Record) och GPT (GUID Partitioning Table) som används för och av den inbyggda programvaran som är kompatibel med Extensible Firmware Interface . Den här filen skapas som standard under OpenVMS I64 diskinitiering och skapas valfritt (med INITIALISE/GPT) på OpenVMS Alpha.

Se även

Jämförelse av filsystem
NTFS - Har många strukturella likheter och metadatalikheter med Files-11 och är nästan säkert konceptuellt härlett från det.

Vidare läsning

Andrew C. Goldstein, VAX/VMS Software Development (1985-01-11). "Files-11 On-Disk Structure Specification". {{ citera journal }} : Citera journal kräver |journal= ( hjälp )
Hewlett-Packard Development Company, LP (september 2003). "Bilaga A: Files-11 Disk Structure". OpenVMS System Manager's Manual, Volym 2: Inställning, övervakning och komplexa system .
Kirby McCoy (1990). VMS-filsystems interner . Bedford, Mass.: Digital Press. ISBN 1-55558-056-4 .

externa länkar