Type a search term to find related articles by LIMS subject matter experts gathered from the most trusted and dynamic collaboration tools in the laboratory informatics industry.
A számítástechnika egy fájlrendszer alatt a számítógépes fájlok tárolásának és rendszerezésének a módszerét érti, ideértve a tárolt adatokhoz való hozzáférést és az adatok egyszerű megtalálását is. A fájlrendszerek használhatják az adattároló eszközöket, mint a merevlemez vagy CD-ROM és használhatók a fájlok fizikai elhelyezésének karbantartására is, valamint szervereken lévő adatokhoz való hozzáférést is biztosíthatnak hálózati protokollok segítségével (pl., NFS, SMB, vagy 9P kliensek), vagy lehetnek virtuálisak és csak a virtuális adatokhoz való hozzáférési mód miatt léteznek csak (például procfs).
Precízebben meghatározva: egy fájlrendszer absztrakt adattípusok halmaza, amelyeket adatok tárolására, hierarchikus rendezésére, kezelésére, megtalálására illetve navigálásra, hozzáférésre, és visszakeresésére valósítottak meg. Vita tárgya, hogy egy fájlrendszer tekinthető-e egy speciális adatbázis-kezelő rendszernek (DBMS), vagy nem. Tény ugyanakkor, hogy több fájlrendszer megosztása alapvetően az adatbázis technológiák jellemzője.
A legismertebb fájlrendszerek egy adattároló eszköz segítségével biztosítják, hogy elérhető legyen egy fix méretű blokkokból (blokk méret) álló sorozata (ezeket az általában 512 byte méretű blokkokat gyakran szektoroknak is nevezik). A fájlrendszer szoftvere biztosítja, hogy ezeket a szektorokat fájlokká, és katalógusokká szervezze össze, és tartsa nyilván, melyik szektor melyik fájlhoz tartozik, és melyik szektorok nem használhatók már tárolásra.
Ennek ellenére egy fájlrendszernek nem kell tárolóberendezést használnia mindenre. Egy fájlrendszer használható az adatok szervezésére és megjelenítésére is, ha azok tárolása vagy elérése dinamikusan történik (például hálózati kapcsolat segítségével).
Egy fájlrendszer akár használ, akár nem használ tárolóberendezést, általában rendelkezik egy szótárral, amely összekapcsolja a fájlneveket a fájlokkal. Általában az összekapcsolás indexeléssel történik, a fájlnév egy index vagy egy fájl elhelyezési táblában, amilyen például az MS-DOS fájlrendszerében a FAT tábla (a FAT a File Allocation Table rövidítése), vagy egy (inode) a Unix-szerű fájlrendszereknél. A szótárstruktúra lehet egyszerű vagy megenged hierarchiákat, amikor a szótárak al-szótárakat tartalmazhatnak. Néhány fájlrendszer esetében a fájlnevek strukturáltak, speciális szintaktikával, (például fájlnév, kiterjesztés, verziószám). Más rendszereknél a fájlnév egyszerű string, és fájlonként a metaadatok másutt vannak tárolva.
A hierarchikus fájlrendszereket Unix környezetben Dennis Ritchie alapozta meg; az első megvalósítások csak néhány szintet engedtek meg, az igaz az IBM egyik korai adatbázisára, az IMS-re is. A Unix sikerei után Ritchie kiterjesztette a fájlrendszer koncepcióját minden objektumra a későbbi fejlesztések során, mint például a Plan 9 a Bell Labs-tól és az Inferno.
A hagyományos fájlrendszerek még egyéb szolgáltatásokat is nyújtanak: létrehoznak, mozgatnak vagy törölnek fájlokat vagy katalógusokat. Hiányoznak viszont a szolgáltatásaik közül a katalógusok közötti többszörös kapcsolatok (beégetett kapcsolat a Unix-ban), a szülő kapcsolat átnevezése (".." a Unix-szerű operációs rendszereknél), és a fájlok közötti kétoldalú kapcsolatok létrehozási lehetősége is.
A hagyományos fájlrendszerek gyakran biztosítják a csonkolás (truncate), a kibővítés (append to), a létrehozás (create), a mozgatás (move), a törlés (delete) és a helyben módosítás funkciókat a fájlokra. Nem támogatják viszont a csonkolás a fájl elejétől funkciókat, de esetleg megengednek korlátlan beszúrást a fájl tetszés szerinti helyén, vagy törlést a fájlon belül. A műveletek általában nagyon aszimmetrikusak, és nem nagyon használhatók nem várt eseteknél. Például, a folyamatok közötti csövet a Unix a fájlrendszeren kívül valósította meg, és nem is ajánlja a csonkolást a fájl elejétől.
A fájlrendszerek biztonsági megoldásai általában a hozzáférési ellenőrző listás (ACL) megoldásokon vagy a képességek el használatán alapulnak. A kutatások azt mutatják, hogy a hozzáférési ellenőrző listákon alapuló megoldások esetében bonyolult a biztonsági jellemzők beállítása, ezért inkább a fejlesztések a képességek használata irányába mutatnak. A kereskedelmi forgalomban lévő rendszerek általában még a hozzáférési ellenőrző listákat használnak. lásd: számítógépes biztonság
A fájlrendszerek alapvetően öt osztályba sorolhatók: lemezes fájlrendszerek, adatbázis-fájlrendszerek, tranzakciós fájlrendszerek, hálózati fájlrendszerek és speciális célú fájlrendszerek.
A lemezes fájlrendszereket úgy tervezték, hogy a fájlok tárolására a számítógépek adattároló eszközei szolgálnak, amelyek leggyakrabban lemezes egységek. Ezek az egységek közvetlenül vagy közvetett módon kapcsolódhatnak a számítógéphez. Például a lemezes fájlrendszerek közé tartozik a FAT, az NTFS, a HFS és a HFS+, az ext3, az ext4, az ISO 9660, az ODS-5 és az UDF. Néhány fájlrendszer naplózó fájlrendszerek közé sorolható, néhány viszont változatkezelő fájlrendszer.
Egy új koncepció a fájlkezelésben az adatbázis alapú fájlrendszer. Ez azt jelenti, hogy a fájlok egy hierarchikus struktúrában helyezkednek el, saját jellemzőikkel azonosíthatóan, mint például fájltípus, téma, szerző, vagy egyszerű metaadat. Ezért egy fájl keresése megfogalmazható SQL-ben vagy akár természetes nyelven is, mint például a BFS-nél és a WinFS-nél.
Ezek a fájlrendszerek egy teljesen speciális csoportot alkotnak: a rendszerben minden fájllal kapcsolatos eseményt vagy tranzakciót rögzítenek.
Bármilyen végrehajtott művelet valamilyen változást vagy változásokat okoz a fájlok vagy a diszkek struktúrájában. A legtöbb esetben ezek a változások kapcsolatokat érintenek, amelyeket – lehetőség szerint – azonos időben kell megváltoztatni.
Vegyük példának, hogy egy bank egy másik banknak egy elektronikus utalást küld. A bank számítógépe „küld” egy utasítást a másik bank számítógépének, hogy módosítsa a saját adatait, hogy az utalás megtörtént. Ha valamilyen okból a számítógép leáll, még mielőtt a saját feljegyzéseit módosította volna, majd újra indul, az utalás „elveszik”. Egy tranzakciós fájlrendszer képes helyreállítani az akciót a „tranzakció” újra-szinkronizálásával mindkét végponton, és korrigálja a hibát. Minden tranzakció fel lesz jegyezve és tárolva, és ez a feljegyzés mutatja meg, mi történt, hol, és mikor. Ezeket a fájlrendszereket a hibatűrő rendszerek számára tervezik és ott is alkalmazzák őket, alkalmazásuk viszont természetesen sok járulékos (belső) adminisztrációval jár.
A hálózati fájlrendszerek olyan fájlrendszerek, amelyek úgy viselkednek, mint egy távoli fájlelérési protokollal rendelkező kliens, ami biztosítja a szerveren lévő fájl elérését. Példák hálózati fájlrendszerekre az NFS, a SMB, az AFP és a 9P protokollok, és fájlrendszer-szerű kliensek a FTP-vel és WebDAV-val működnek.
Speciális célú fájlrendszer alapvetően minden olyan fájlrendszer, amely sem lemezes-, sem hálózati fájlrendszer. Ezek azok közé a rendszerek közé tartoznak, ahol a fájlokat egy szoftver dinamikusan kezeli, egyben biztosítja a kommunikációt a számítógépen futó feladat(ok) és az ideiglenes fájl tárolási terület között.
Bizonyos szempontból speciális célú fájlrendszert használnak a leggyakrabban használt, fájl-centrikus operációs rendszerek, mint a Unix.
A mélyűri felfedező űrhajók, mint a Voyager–1 és a Voyager–2 egy speciális, digitális szalag-alapú fájlrendszert használnak. A modern felfedező űrhajók, mint a Cassini-Huygens egy valós idejű operációs rendszert és fájlrendszert használ. A Mars Roverek is egy valós idejű fájlrendszert használnak, amelyet flash memóriával valósítottak meg.
A legtöbb operációs rendszer rendelkezik fájlrendszerrel, azaz a fájlrendszer a modern operációs rendszerek integráns része. A korai mikroszámítógépes operációs rendszerekben ténylegesen elkülönült feladat volt a fájlkezelés; – ez a tény visszatükröződik az elnevezéseikben is (lásd DOS és QDOS). Néhány korai operációs rendszerben a fájlkezelő rendszer külön rendszerként jelentkezett, ezeket nevezték lemezes operációs rendszereknek. Néhány mikroszámítógépen a lemezes fájlkezelőt külön kellett betölteni az operációs rendszer mellé. A korai operációs rendszerek általában csak egy, nekik készült fájlkezelő rendszert támogattak, ami többnyire névtelen volt; például a CP/M csak a saját fájlkezelő rendszerét támogatta, amit „CP/M file system” néven ismerünk, de így szinte senki sem nevezte.
A fentiek miatt szükségessé vált, hogy legyen egy interfész az operációs rendszer, a fájlkezelő rendszer és a felhasználó között. Ez az interfész lehet szöveges (amit egy parancssoros felhasználói felület biztosít, mint például a Unix shell, vagy OpenVMS DCL) vagy grafikus (mint amit egy grafikus felhasználói felület biztosít, mint például a fájlkezelők). Ha grafikus, akkor megfelel valamilyen gyakran használt mappaábrázolásnak, ami dokumentumokat és egyéb fájlokat, illetve beágyazott mappákat is tartalmazhat.
Az egyszerű fájlrendszerek esetében nincsenek katalógusok – minden azonos szinten (gyökér) rögzítődik, (a hordozó szintjén), legyen az merevlemez, hajlékonylemez stb. Az egyszerűsége miatt, a rendszer a fájlok számának növekedésével egyre kevésbé lesz hatékony, a felhasználó(k) számára egyre nehezebb lesz az adatcsoportok kezelése.
Mint a legtöbb régebbi kis rendszer, az eredeti Apple Macintosh egy egyszerű, Macintosh File System nevű fájlkezelőt használt. A Mac OS már nem ezt használta, hanem egy olyan rendszert, ami egy nem teljesen hierarchikus fájlkezelő illúzióját nyújtotta (Macintosh Finder). A Macintosh Finder-t gyorsan helyettesítették a Hierarchical File System-mel, amely már valóban támogatta a katalógusokat.
A Unix és az Unix-szerű operációs rendszerek minden eszközhöz egy eszköznevet rendelnek, de ennek nincsen köze ahhoz, miképp is érhetők el az eszközön lévő fájlok. Valójában a Unix létrehoz egy virtuális fájlrendszert, amelyben minden eszközön lévő minden fájl egy hierarchiába rendeződik. Ez azt jelenti, hogy a Unix-ban van egy gyökérkönyvtár, és minden létező fájl valahol ebben a gyökértől induló struktúrában helyezkedik el. Sőt, ennek a gyökérnek nem is kell tényleges fizikai hely. Nem kell az első merevlemezen lennie, még csak a gépben sem kell lennie, a Unix képes egy megosztott hálózati erőforrást gyökérkönyvtárként kezelni.
Valamilyen eszközön lévő fájl eléréséhez először meg kell mondani az operációs rendszernek, hol van az a könyvtárfa, ahol a fájl található. Ez a művelet a csatlakozás egy fájlrendszerhez. Például, egy CD-ROM-on lévő fájl eléréséhez meg kell mondani az operációs rendszernek, hogy „keress egy fájlrendszert ezen a CD-ROM-on, ami az ilyen-és-ilyen katalógusban található”. Az adott katalógust az operációs rendszer csatlakozási pontnak tekinti – legyen ez mondjuk /mnt. Az /mnt katalógus több Unix-szerű rendszerben létezik (ahogyan azt a fájlrendszer hierarchia szabvány meghatározza) és az a célja, hogy kapcsolódási pontot biztosítson az ideiglenes/cserélhető hordozók számára, mint a flopi lemezek vagy CD-k. Lehet üres is, vagy tartalmazhat alkönyvtárakat más, különálló egységek csatlakoztatásához. Általában csak a adminisztrátor (un. root user) rendelkezik olyan jogokkal, hogy csatlakoztathat fájlrendszereket.
A Unix-szerű operációs rendszereknek gyakran része program vagy eszköz, ami támogatja a csatlakoztatási eljárást, és új lehetőségeket is biztosít. Ezek közül a stratégiák közül a legtöbb az úgynevezett „auto-mounting” – automatikus csatlakoztatás, aminek az elnevezése már utal is a használatára.
A Mac OS X a Mac OS -ben használt és HFS Plus-nak nevezett fájlrendszert örökölte. Ez a fájlrendszer egy meta-adatokban bővelkedő és case preserving fájlrendszer. A Mac OS X Unix gyökerei miatt, a Unix engedélyezési megoldásai megjelentek a HFS Plus-ban. A HFS Plus későbbi változatai kibővülnek a naplózó fájlrendszer szolgáltatásaival, megelőzve a fájlrendszer struktúra sérülését és rendelkezik egy algoritmussal a töredezés elkerülésére, hogy ne kelljen külső töredezésmentesítő eszközt igénybe venni.
A fájlnevek hossza 255 karakterig terjedhet. A HFS Plus a fájlnevek tárolásánál a Unicode-ot használja. A Mac OS X-en a fájltípus a típus kód, és vagy a fájl meta-adatai között, vagy a fájlnévben tárolják.
A HFS Plus három kapcsoló típust ismer: beégetett kapcsolatok, szimbolikus kapcsolatok és álnevek. Az álnevek képesek fenntartani a kapcsolatot akkor is, ha az eredeti fájlt átnevezték vagy átmásolták.
A Bell Labs Plan 9-e tervezése eredetileg a Unix jól bevált megoldásain, valamint néhány új elképzelésen alapult, megoldva ezzel néhány ismert Unix hiányosságot.
Ami a fájlrendszert illeti, a Unix rendszer úgy kezeli a dolgokat, mint például egy fájlt, hogy az folytatható, a Plan-9 viszont mindent fájlként kezel, és úgy is fér hozzá, mintha fájl lenne (például nincs ioctl vagy mmap). Talán meglepő, de a fájl interfész univerzális, és jelentősen leegyszerűsített, például a szimbolikus kapcsolatok, a beégetett kapcsolatok nem használatosak, és egy elemi létrehoz/megnyit művelet létezik csak. nagyon fontos, hogy a fájlműveletek halmaza jól meghatározott és az alváltozatok, mint az ioctl hiányoznak.
Másodszor, a 9P protokoll használatával megszüntethető a helyi és a távoli fájlok közötti különbség (kivéve a lappangást). Itt jelentkezik annak az előnye, hogy mindent fájlként kezel a rendszer, ugyanis a meghajtó vagy meghajtók szintén fájlként jelentkeznek, és a távoli számítógépeket is úgy tekinthetjük, mit a helyi gép egy meghajtóját vagy meghajtóit. Ez azt jelenti, hogy a Plan 9-alatt többszörös fájlrendszerek biztosítanak hozzáférést a meghajtókhoz, amelyek a fájlok egy osztályát képviselik.
A Plan 9-en mindent egy fájlnak kell elképzelni, a hálózati részt, a grafikát, a nyomkövetést, a hitelesítést, a képességeket, a titkosítást, és minden egyéb szolgáltatást, amelyek I/O műveletekkel érhetőek el, különböző fájl-leírókkal.
Egy másik példa: egy Plan-9 alkalmazásnak szüksége van egy FTP szolgáltatásra egy FTP helyszín megnyitásával. Az ftpfs külső beavatkozás nélkül kezeli a megnyitást és a szükséges távoli csatlakoztatást, és ezt úgy jeleníti meg, mintha ez egy helyi fájlrendszer lenne. Egy másik példa a mail rendszer, amely szintetikus, virtuális fájlok és katalógusok használatával éri el, hogy a fájlrendszert tudja használni. A katalógus vagy virtuális fájl a felhasználói mailbox rendszert reprezentálja, mint /mail/fs/mbox. A wikifs egy interfészt biztosít a wiki eléréséhez.
Ezek a fájlrendszerek saját help rendszerre, saját, folyamathoz tartozó névtérrel szervezhetők. A különböző folyamatok számára megengedett, hogy különböző nézeteket alkalmazzanak a fájlrendszerekre és az elosztott rendszerek erőforrásaira.
Az Inferno operációs rendszer hasonló koncepció alapján működik, mint a Plan 9.
A Microsoft Windows a korai operációs rendszerén (MS-DOS amely a QDOS és a CP/M-80 alapján jött létre, és több elképzelést is a kezdeti operációs rendszertől átvett, főként a DEC-től) kifejlesztett egy fájlrendszert, a FAT-ot, amelynek az mind a rendszer-, mind pedig a felhasználói interfész forráskódját több rendszer is használta (Unix, OS/2, stb). Ma a Windows használja mind a FAT (File Allocation Table), mind pedig a NTFS (New Technology File System) fájlrendszereket. A FAT rendszer korábbi változatai, a (FAT12 és FAT16) esetében a fájlnevek hossza korlátozott, és létezik egy korlát a gyökérkönyvtárban lévő bejegyzések számára is, de megkötések vannak a FAT-rendszerrel formázott lemezek vagy partíciók méretére is. Egészen pontosan, a FAT12 és a FAT16 nyolc karakterre korlátozza a fájlnév hosszát, és három karakterre a kiterjesztést. (Erre általában a 8.3 korlát néven hivatkoznak.) A VFAT, amely a FAT12 és a FAT16 bővítése volt, és a Windows NT 3.5-nél jelent meg, de még a Windows 95-ben is megjelent, megengedte a hosszú fájlneveket – long file names (LFN). A FAT32-ben néhány, a FAT12-ben és a FAT16-ban meglévő korlát megmaradt, de ezek elhanyagolhatók.
Az NTFS a Windows NT operációs rendszerrel egy időben jelent meg, megengedi a hozzáférési ellenőrző lista – access control list (ACL) alapú ellenőrzést, a többszörös fájl hozzáférést, a beégetett kapcsolatot, a jellemzővel való indexelést, a feltöltöttség követést, a tömörítést és a kapcsolódási pont létrehozást másik fájlrendszerek számára (ezek a „junction”-ök), azonban ezek a szolgáltatások nem mind dokumentáltak.
A legtöbb operációs rendszertől eltérően, a Windows használja a meghajtó betűjel fogalmat felhasználói szinten, két lemez vagy partíció egymástól való megkülönböztetésére. Például, a C:\WINDOWS\ elérési út egy WINDOWS könyvtárat jelent, ami a C betűvel jelölt partíción helyezkedik el. A C meghajtó a leggyakrabban használt elsődleges lemezpartíció, ami a Windows-ban létrejött, és amiről betöltődik. Ez a „hagyomány” olyan erős, hogy a régebbi Windows változatoknál hibaként is jelentkezett, hogy ezek a változatok azt tételezték fel, hogy az a meghajtó, amin a Windows rendszer található, az csak a C meghajtó lehet. A „C” meghajtóval kapcsolatos hagyomány egészen az MS-DOS-ig nyúlik vissza, ahol az A és B betűk a két flopi meghajtó számra voltak fenntartva; egy általános konfiguráció esetében az A meghajtónak egy 5 1/4 hüvelykes flopi meghajtónak kell lennie, és a B pedig egy 3 1/2 hüvelykes mini flopi meghajtó. A hálózati meghajtókhoz szintén hozzá kell rendelni egy-egy betűt a MAP paranccsal.
Mióta a Windows grafikus felhasználói felület segítségével áll kapcsolatban a használójával, a Windows kézikönyvei a katalógusokra úgy hivatkoztak, mint egy olyan mappára amely fájlokat tartalmaz, és ezeket a grafikus mappa ikonnal jelölték.
LIMS forum content by LIMS forum members is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Based on a work at www.limsforum.com.
