Bevezetés: Ez az írás segíthet a Linuxszal történő ismerkedés során. Sok olyan embernek segítettem Linux telepítésével, akik azelőtt csak Windowst használtak. Ez az írás főleg az általuk feltett kérdéseken alapul. Rengeteg írás, információ fellelhető az interneten, mindenféle szempont szerint kategorizálva. Ez a leírás nem tartalmaz minden érdekes információt, de igyekszem amennyire lehet tömören összefoglalni (így is jó hosszú lesz), azokat a válaszokat, amiket az évek során a nekem feltett kérdésekre volt alkalmam adni.

Kezdjük az ismerkedést a kályhánál (azaz meghajtók, mappák, egyebek)

Meghajtók.

Hosszú út vezetett az AT számítógép megjelenéséig, és bár annak folyamán nem tűnt úgy, de visszatekintve elég egyszerű koncepciók voltak a korabeli gépek, lényegüket tekintve volt egy INPUT meg volt egy OUTPUT , a kettő között meg egy betöltött program. Aztán megjelentek a mikroszámítógépek, utána meg a 286-os procival az AT is. Ezek komplexitása már egy sor dilemmát is felvetett a rájuk írandó rendszer kialakítását illetően. Ekkor a hozzájuk kapcsolódó legfőbb nóvum a lemezek voltak, ami a lyukkártyához / mágnes szalaghoz képest ténylegesen merőben új dolognak számított. Erre építette a koncepcióját a DOS, ami a leginkább elterjedt rendszer lett, azaz, ennek koncepciója a lemezeken alapult. DOS= DISK OPERATING SYSTEM, azaz lemezes operációs rendszert jelent. Ekkor még nem volt merevlemez, a személyi számítógépeknek egy vagy kettő flopi meghajtója volt, Egyiken volt az operációs rendszer, meg a programok (pl. adatbázis kezelő), a másikon meg az adatok, amiket feldolgoztak. Hogy ne keveredjen a kettő meghajtó, az látszott kézenfekvőnek, hogy az egyiket A-nak, a másikat B-nek jelölik. Hogy egyértelmű legyen a meghajtó jelölés a gép használata során, a betű után kettőspontot kellett tenni. Így kellett jelölni, hogy az A vagy B nem egy fájl név első betűje. Tehát A: vagy B:. Ez időtájt, az 1-es DOS idején még nem léteztek mappák.

A hálózati rendszerek, amik lassan terjedtek mint pl. mainframe szerverek, UNIX .... ezek alatt már az adatok mappastruktúrába szervezése szükséges volt, az elérési utak esetén az elválasztójel a „/” karakter volt. Időközben a DOS is fejlődött, meg persze az első merevlemez ősök is megjelentek, és szükség volt az adatok elkülönítésére a helyi gépen is, így lettek mappák DOS alatt is. Annak érdekében, hogy meg legyen különböztetve a hálózati és helyi gépen levő elérési út, azért DOS alatt tagoló jel „\” lett.

Ha egy gépben merevlemez is volt, az már a C jelölést kapta, mert a 2 flopis gépek még többségben voltak, az A meg a B betűket megtartották a flopik számára. Ekkoriban az 5-10 MB kapacitású merevlemezek akkorák voltak mint egy kisebb tál (igen, kerek fém vájlingok voltak), és színes drótok lógtak ki belőle, amiket szakember kötött be a gépbe, ezeket legnagyobb számban az Inprimus cégen belül a Data Control Co. nevű cég gyártotta, és konkrét géptípushoz volt gyártva mindegyik, azaz konkrét géptípushoz valót kellett rendelni / gyártatni, ami más típushoz nem volt jó. Aztán megjelent egy cég, a neve Compaq volt. A Compaq-nak olyan víziója támadt, hogy megreformálja a PC-t, teljesen átstrukturálva azt. Olyan merevlemez kellett nekik, ami elég kicsi fizikailag, hogy a kis méretű, akár asztal fiókba elférő gépükbe beleférjen, és ne kelljen szakember a bekötéséhez, azaz, a felhasználó elmegy a boltba, vesz egyet, otthon kibontja a gépet, belehelyezi, bekonfigurálja, és ha kell még egy, akkor az se legyen akadály - kb. valamit ilyesmit szerettek volna, ami akkor egészen merész elképzelés volt. A Compaq megkereste a Seagate adattárolással foglakozó céget (amely, akkor még nem foglalkozott merevlemezekkel), hogy fejlesszen ki egy számára is megfelelő merevlemezt. A Seagate erre létrehozta a Conner Peripherals nevű céget a San José-i egyetemmel közösen, ők meg kitaláltak egy 3,5 colos HDD-t. Az adatkábelre mindjárt kettőt is lehetett kötni, így C mellett lett egy D betű is a merevlemezek számára. A vezérlő áramkör két részre lett bontva, egyik része a merevlemezre került, a gépben a másik része, a kettő között volt egy elválasztást lehetővé tevő rész, ami az ATA interfész lett. A mai napig ezt a sémát követik a PC-s merevlemezek, igaz, az ATA is fejlődött, és most már SATA van, de a merevlemez formája, mérete, és az, hogy van rajta elektronika, BIOS teremti meg a kapcsolatot gép és merevlemez között az mind a Conner elképzelésén alapul. Nagyon vacakok voltak a Conner merevlemezek, de az elképzelésük iparági szabványt alkotott, ez mindenképpen nekik köszönhető. (Valahol van is egy ilyen relikviám, egy eredeti Conner merevlemez az elsők közül, le akartam fényképezni, de nem találom)

Eközben a hálózati rendszerek terén színre lépett a Novell nevű cég, A Netware nevű hálózati rendszerük a DOS-al kompatibilis volt, azaz, az elérési utakban az elválasztó a „\” volt, és, hogy a hálózaton a nagyon hosszú elérési utakat ne keljen begépelni, az egyes elérési utakhoz további betűket lehetett rendelni. Így felhasználásra kerültek az angol ABC betűi, F lett a szerver gyökere, Z a felhasználó saját mappája, stb.

Ez időtájban jelent meg a Linux, amit viszont a UNIX inspirált, amiben az elérési út tagoló jele a „/” és nem voltak „meghajtói”, tekintve, hogy ezek többfelhasználós kiszolgáló rendszerek, amiknél az elsődleges követelmény a bővíthetőség. Azaz, a fizikai lemezek hozzáadásával meg kellet valósítani azt, hogy azok úgymond ne különüljenek el a többitől, hanem egybefüggő területet alkossanak. Ugyan a Linux elsőre PC-re jelent meg, aminek mindenféle eltérő fizikai meghajtói voltak, ezért ilyen-olyan okokból több betűvel lettek jelölve a meghajtók. Az első flopi fd0 lett, a második fd1… a merevlemez hda, hdb és így tovább. Ezeket a logikai jeleket mappákhoz ill. fájlokhoz csatolja a rendszer.

A történet folytatódott, a merevlemezek mérete nőtt. A DOS FAT fájlrendszere úgy lett kitalálva, hogy fix száma van a gyökérből nyitható mappák számának, továbbá, ami fájdalmasabb volt: fix volt az allokációs egységek száma. Ez azt jelentette, hogy minél nagyobb volt a merevlemez, annál nagyobbak lettek az allokációs egységek is. Egy fájl egy allokációs egységet mindenképpen elfoglal, ha annál nagyobb, akkor többet is. De az allokációs egységek már egy 200 MB-s lemezen is több mint tíz MB méretet lefoglaltak, miközben a fájlok bőven 1 MB alattiak voltak, ami azt jelentette, hogy az 1 bájt méretű (1betút tartalmazó) fájl is lefoglalt több mint tíz MB-t a merevlemezen. Ennek a helypazarlásnak egyik feloldási lehetősége az volt, hogy a HDD-t több partícióra osztották. Ezek további betűket vittek el az ABC-ből. Ha az első merevlemez négy partícióra volt osztva, akkor azok a C; D; E; F betűket kapták. Ám ez máris ütközött a Netware hálózati rendszerrel, mert annak is alapból F betű jelölte a szerver gyökerét. Így mind DOS alatt mind Netware alatt meg lett oldva, hogy a betűket szabadon át lehessen variálni.

Linux alatt a partíciók számozást kaptak. Flopikon (és az optikai lemezeken) nem értelmezhető a partíció, azaz, azokat nem lehet particionálni. Azok így fd0, sr0 jelölést kaptak, a merevlemezeken a partíciók számozása 1-től kezdődik, azaz hda1, hda2 stb.

Mivel manapság SATA HDD (SDD) a jellemző, azok jelölése sda1, sda2… sdb1, sdb2….

(A történethez hozzá tartozik, hogy a PC fejlődése mentén jelen volt a High End képviselője is: a Macintosh, aminek a gépei akkor SCSI sínrendszert használtak. Az sd jelölést a SCSI HDD kapta előbb. De mivel a SATA HDD logikailag nagy hasonlóságot mutat a SCSI HDD -vel, így örökölte az sd jelölést. Amúgy manapság a SCSI utóda a SAS)

Továbbá az NVMe csatolókon lógó lemezek meg nvme0n1, nvme0n2, nvme1n1 … jelöléseket kapnak.

A Windows saját logikát követ a betűk kiosztásával, alapból a C „meghajtóra” települ (de ez lehet D is egyes esetekben), aztán vagy van további partíció, ami D lesz, ha nincs, akkor a CD/DVD meghajtó kapja a D betűt, és így tovább, de jelenleg a C-t leszámítva az összes betű jelölést át lehet állítani Windows alatt, így mondhatni, hogy nincs logika adott esetben a betűk kiosztásában.

A Linux viszont szigorú logikát követ a jelölésben, (más kérdés, hogy azokat csatolni lehet beszédesebb nevű (alap jelöléstől eltérő) mappához pl.)

Linux alatt csak egy gyökér mappa van, ennek jele a „/”. Minden ez alá van rendelve, az összes további meghajtó, és eszköz, stb.

Windows alatt minden meghajtónak van formális gyökér mappája. Bár ma már nincs szükség a lemez szintű koncepcióra, a Windows továbbra is betűzi a lemezeket, és az elérési utak tagoló jele a „\”

Itt most elnézést kérek a hosszú történelmi felvezetés miatt, és megígérem, hogy a továbbiakban nem lesz ilyen. Ennél a dolognál úgy érzem szükség van erre, a legtöbb erre irányuló kérdésre a válasz csak ilyen történelmi magyarázattal volt elfogadható. Van ilyen.

Pl. a párom sem akarta megérteni a logaritmust. Amikor elmeséltem, hogy régen, amikor még nem volt számológép, akkor miért volt ez kitalálva, és hogyan számoltak vele, egyből megértette, hogy miről van szó.

Akkor most jöjjön a fájlrendszer gyorstalpaló.

A Windows NT4.0-val bevezetésre került az NTFS fájlrendszer (illetve már korábban, de ez volt úgymond az első kiforrott verzió (az NTFS-nek több verziója van). Ez akkor a legjobb volt, bele integráltak minden jót, ami az akkori fájlrendszerekre jellemző volt, vettek kölcsön elemeket az EXT / HPFS fájlrendszerektől meg új elemekkel is bővült. A FAT32-t váltotta, bár a FAT32 annyira elterjedt, hogy a mai napig azt használják pendrájvokon, SD kártyákon, külső meghajtókon. Az NTFS kettő allokációs táblát használ, egyet a lemez elején, egyet a közepén, naplóz, leírókat használ, támogatja a fájlrendszer szintű tömörítést, titkosítást, árnyékmásolatot, hardlinket, stb. Az árnyékmásolat azt jelenti, hogy meg tudja őrizni a fájloknak a változásait, azaz szükség esetén egy korábbi állapot visszaállítható. A hardlink azt jelenti, hogy ugyanarra a fájlra / mappára több névvel is lehet hivatkozni, továbbá többféle CRC ellenőrző kódokat tárol, tehát fájlrendszer sérülés esetén nagyobb eséllyel javítható / helyreállítható a sérült fájl. Lehet kvótákat definiálni, és az NTFS partíció méretét lehet növelni / csökkenteni. A jogosultság viszont nem tárolódik a fájlrendszeren, (pontosabban a tulajdonos tárolva van, de ezt csak adott Windows verzió éri el, elég faramuci a kezelése) így ha az NTFS partíció nincs titkosítva, akkor a gépből kivett HDD másik gépben probléma nélkül olvasható, tehát azok a fájlok is, amikhez a rendes helyen adott felhasználónak nincs jogosultsága. A Linux sem tud ezzel mit kezdni, Linux alatt az NTFS meghajtón gond nélkül elérhető minden fájl, tekintett nélkül a Windows alatt beállított jogosultságokra. A Windows erre a problémára a meghajtó titkosítását találta ki, ezt Bitlockernek hívják, bekapcsolása esetén a HDD titkosítva lesz, azt másik gépben csak két nagyon hosszú kódsor begépelésével lehet feloldani.

https://en.wikipedia.org/wiki/NTFS

Az NTFS támogatja a kisbetű / nagybetű megkülönböztetést, csak ez alapból nincs bekapcsolva. Tehát alapból nem lehet Valami ; valami ;VALAMI; vAlami nevű fájl vagy mappa egy mappán belül, csak egy valami nevű fájlunk lehet, és mindegy, hogy kisbetűvel, vagy nagybetűvel ill. ezeket keverve hivatkozunk rá.

A Linux kiforrott fájlrendszere jelenleg az EXT4. Ez is naplóz, és azon túl amit az NTFS nem tud, támogatja a késleltetett allokációt, ami azt jelenti, hogy egy nagy fájl ütemezett közvetlen felírását úgy végzi, hogy „megvárja annak a végét”, aztán egy olyan helyre teszi a sorban, ahová elfér, azaz van elég klaszter, amiket egy menetben le tud fedni, ez az óriási fájlokkal való munka gyors lehetőségét jelenti, beleértve a fragmentálás elkerülését. Továbbá tárolja a jogosultságokat is, így egyik gépből kivett HDD másik gépben Linux alatt nem lesz elérhető (az azon levő fájlokhoz nem lehet hozzáférni alapból) más kérdés, hogy van erre megoldás. Ha azt akarjuk, hogy tényleg ne legyenek elérhetők másik gépben az EXT4 fájlrendszeren tárolt fájlok, akkor azt is lehet titkosítani. Akár csak a saját mappánkat is lehet titkosítani, a rendszertől elkülönítve.

https://en.wikipedia.org/wiki/Ext4

Ugyanakkor az EXT4 nem tárol CRC ellenőrzőkódokat, nincs fájlrendszer szintű tömörítési lehetőség, és nincs árnyékmásolat támogatás sem. (Mindezeket viszont tudja a Btrfs fájlrendszer, amit az EXT4 leváltására találtak ki. Ugyan már elég stabil, de még jelenleg is fejlesztik. De az újabb Linux rendszerek már támogatják a használatát)

EXT4 fájlrendszeren alapból számít a kisbetű / nagybetű a fájl nevében, tehát egy mappán belül lehet Valami ; valami ;VALAMI; vAlami nevű fájl, és ez 4 különböző fájlt jelent.

Az EXT4 fájlrendszer alatt sokkal hosszabb elérési utak, és fájl nevek lehetnek, mint NTFS alatt. Így, ha EXT4-ről másolunk NTFS lemezre, bizony beleütközhetünk olyan problémába, hogy nem lehet mindent átmásolni, a túl hosszú elérési út miatt.

Gyorsaság: az EXT4 csak a metaadatok frissítésének idejével marad el az NTFS-től, minden egyéb tekintetben gyorsabb a kezelése, és különösen a nagy méretű fájlok kezelésében gyorsabb (a fálj méretével exponenciálisan növekedik a másolás gyorsasága az NTFS-hez viszonyítva.)

https://pages.cs.wisc.edu/~bart/736/f2016/Akshay_Vaibhav_ntfs_ext4.pdf

Megjegyzés: a Linux fájlrendszerének a neve így helyes: ext4, azaz, nem nagybetűsen kell írni, én a szövegben azért írtam végig nagy betűvel, hogy szembetűnőbb legyen, az áttekintésben segítsen.

Windows alatt 4 attribútum van: Rejtett, Rendszer, Csak olvasható, és Archív.

Linux alatt alapból 3: Olvasás, Írás, Végrehajtás. (Ám ezek három szinten is beállíthatók, tulajdonosra, csoportra, meg egyébre)

További jelölő bitek: Program (Futtatható), SUID, SGID, Ragadós. (Sticky)

A SUID program esetén azt határozza meg, hogy akármelyik felhasználó ezt ugyanolyan jogokkal futtathatja, mint a tulajdonosa.

Az SGID pedig ugyanazt, de akármelyik csoportra értve.

A Ragadóst mappára kell érteni, ez azt határozza meg, hogy az adott mappán belül csak a tulajdonos, illetve a rendszergazda tud fájlokat törölni / átnevezni, vagy nem.

Ami elsőre leginkább szembe ötlő, hogy Linux alatt nincs Rejtett attribútum. Linux alatt, azt, hogy egy fájl, vagy mappa rejtett, az jelöli, hogy a neve egy ponttal kezdődik. (Android is Linux alapú, az okostelefonon is találkozhatunk ezzel).

Windows alatt, azt, hogy egy fájl futtatható, annak a kiterjesztése jelöli. Futtatható az, aminek a kiterjesztése .COM; .EXE; .BAT; .CMD; .VBS

Linux alatt bármilyen nevű/kiterjesztésű fájl futtatható (mármint, ha az tényleg program, vagy szkript, nem pedig egy dokumentum), amire a „programként futtatható” attribútum jelölés be lett állítva. // persze, ha pl. egy képre / dokumentumra állítjuk ezt be, az nem fog futni mint egy program, hibaüzenetet kapunk.

Btrfs: Fentebb említve volt már, ez a legújabb Linuxos fájlrendszer. Az Ext4 NTFS-hez viszonyított „elmaradásait” pótolja: crc32c ellenőrzőkódok, árnyékmásolatok, fájlrendszer szintű tömörítés. De ez még nem minden, mert rá is tesz egy jókora lapáttal: Míg az ext4 és az NTFS is kb. 1 EiB partíció méretet támogat, a Btrfs partíció akár 16 EiB is lehet. Ext4-en a legnagyobb fájl 16 TiB lehet, Btrfs alatt akár a teljes partíció méretét is elfoglalhatja (16 EiB). De gondolom ezek annyira nem releváns tulajdonságok :-). Ezek viszont annál inkább: Deduplikálás- ez azt jelenti hogy a duplikált fájlok helyett képes egyet megtartani, ami a helytakarékosságot segíti. Másik hasonló dolog a blokk sub-allokáció – ez azt jelenti, hogy a fájlok által lefedett allokációs egységek közül az utolsónak azt a részét, ami üresen marad, hasznosítani tudja. (kb. minden fájlra igaz, hogy van ilyen üres terület utána. Bár ext4 alatt ez pl. akkor jön jól, ha a fájl mérete növekedik.)
És persze, a multi-felhasználás sem maradt ki, natív RAID támogatás, és beépített tartalom manager rendszert tartalmaz (LVM), továbbá támogatja a kötetösszevonást, azaz képes több merevlemezt, több partíciót egy kötegbe foglalni. (Ez utóbbit az NTFS is tudja)

https://en.wikipedia.org/wiki/Btrfs

És legyen itt némi infó a ZFS fájlrendszerről (mivel az újabb Linux Mint telepítők felajánlják a lehetőséget ZFS használatára is)

A Sun Microsystems fejlesztette, azonban amikor az Oracle ezt felvásárolta, akkor megalakult az OpenZFS projekt, ami továbbvitte a fejlesztést. Ma ezért két verziója van a ZFS-nek, az Oracle fizetős változata, illetve az ingyenes és nyílt OpenZFS.

A ZFS és a Btrfs technikailag nagyon hasonló, bár a szolgáltatásaik megvalósítását merőben más módon teszik. Azaz, a ZFS tudja mindazt, amit a Btrfs, de ennek ellenére vannak különbségek. A legmarkánsabb ezekből az, hogy a ZFS képes egy sereg eltérő médiaformátumot úgy kezelni, hogy támogatja azok menet közbeni hozzáadását a kötethez, azaz növelhető a meglévő kötet pl. újabb SSD vagy HDD de pendrájv, vagy SD kártya hozzáadásával is- egybecsomagolva kezeli az LVM és RAID köteteket. (Az előzőkben említett fájlrendszerek csak azonos médiákkal és korlátokkal tudják ezt, RAID kötetre épített LVM-et és másik RAID kötetre épített LVM külön tudják csak kezelni, ZFS esetén no gond, össze lehet vonni mindet egybe)

A Btrfs „csak” 16 exabájt (2 a 64. hatványon) kötetméretet támogat. A ZFS ezzel szemben 256 trillió yoyibájt-ot. (2 a 128. hatványon). És amíg Btrfs alatt „csak” 2 a 64. hatványon számú fájlunk lehet, ZSF alatt nincs korlátja a fájlok számának. Ebből nyilván látszik, hogy ez leginkább szuperszámítógép, vagy mainframe környezetben érdekes, jellemzően még céges szinten sincs szükség ekkora területre.

De ehhez képest ezt használják NAS-okban is, főleg a széles körű médiatámogatása miatt. Pl. lehet (van) olyan megoldás, azaz NAS, amiben HDD és SSD is van, menedzselni lehet úgy a fájlokat, hogy a gyakran használtak az SSD területére kerüljenek, amire meg ritkán van szükség, azok a HDD területén lesznek.

Amit még jó tudni, a Btrfs kernel szinten támogatott. A ZFS-t a legtöbb Linux alatt külön kell telepíteni. A Linux Mint 21 telepítője integráltan tartalmazza.

A ZFS további eltérése a Btrfs-től, hogy míg utóbbi inkább a naplózásra építi a biztonságot (van CRC kezelés is), a ZFS ezt főleg a CRC kezelésre alapozza, a fájlsérüléseket röptében automatikusan javítja. A COW-ot (Copy On Write) mindkettő tudja, de ZFS nagyobb redundanciával kezeli ezt (kikapcsolható amúgy a COW)

Minden, amiben „jobb” a ZFS a Btrfs-hez képest, az egyben a hátulütője is. Abban az értelemben, hogy eléggé erőforrás igényes. Főleg bekapcsolt COW esetén. Képes a NAS teljes memóriáját fájlkezelésre használni, és még többet is lefoglalna, ha lenne.

Ménkű erős gép kell hozzá, na. Szerver, vagy sok procis rengeteg RAM-os, szupergyors PC.

https://en.wikipedia.org/wiki/ZFS

 

Mappastruktúra:

Azt, hogy a rendszer alatt legyenek dedikált mappák, amelyek valamilyen logikát követnek először a hálózati rendszerek, illetve a Linux ”találta ki”. Windows esetén a 95-ösnél kezdődött valami, aminek csak látszata volt, ez csak Windows NT 4.x alatt lett valamennyire kész, csak itt lett először megoldva a „magánélet”, azaz, a felhasználók saját mappát kaptak, és más felhasználó mappájához nem fértek hozzá. Linux alatt a Home mappa tárolja felhasználók almappáit, fájljait, amin belül mindenki a saját cuccaival garázdálkodhat. Windows alatt, ez először a Documents And Settings mappa volt, aztán minden Windows kiadás során változtattak ezen, jelenleg Users a mappa neve. Ebben van egy <Username>\Documents mappa. Régebben ezen belül voltak Képek, Letöltések, Videók, stb. mappák, aztán ezek egy szinttel feljebb kerültek, van felhasználóhoz rendelt beállításokat tároló mappa, (AppData) amit szintén variáltak az idők során, hol adott mappán belül, hol másik mappán belülre került (kb. mint Linux alatt az usr/bin, meg bin mappa esete).

A nem angol nyelvű Windowsok a nyelvi változatnak megfelelően röptében lefordítják az USERS; DOCUMENTS; PICTURES; DOWNLOADS; stb. mappák neveit, azok az Intézőben (A Windows fájlkezelője) a nemzeti nyelven jelennek meg (Tehát FELHASZNÁLÓK; DOKUMENTUMOK; KÉPEK; LETÖLTÉSEK; stb-ként látszanak magyar nyelv felülettel, de a fájlrendszer eredeti angol nevükön tárolja a mappák neveit, és hivatkozhatunk rájuk az angol nevükkel.

Windows alatt van programok számára fenntartott mappa, de ez nem jelent semmiféle fizikai kényszert a programok szempontjából. Nem rendszergazda felhasználó nem fér hozzá ehhez a mappához. Elképzelés szerint ez megakadályozza abban, hogy mindenféle programot telepítsen. Persze, a programok tudnak tudnak települni a felhasználó saját mappájába is. Vagy akár a gyökérben létrehozott új mappába. Az AMD videokártya telepítője pl. notóriusan a C:\AMD mappába települ.

Windows mappa	Linux mappa	Megjegyzés
Users	Home
Program files	bin; urs/bin; opt; usr/share; /usr/local	W: 32 bites Windows esetén 32 bites programoknak szánt mappa, 64 bites Windows esetén 64 bites programoknak szánt mappa L: Linux alatt a bin; usr/bin mappák a programok indítóit tartalmazzák, a legközelebb az opt; usr/share áll a Program Files-hez.
Program files(x86)	bin; urs/bin; opt; usr/share	64 bites Windows esetén 32 bites programoknak szánt mappa
	dev	Eszközök mappája. Windows alatt ilyen nincs, ott kb. az Eszközkezelő (alkalmazás) helyettesíti.
	etc	Főleg beállítások. Windows alatt ilyen nincs, kb. a Registry-nek felel meg (Windows alatt hírhedt beállítás tároló)
Windows\System Windows\System32 Windows\Syswow64	sbin	Rendszer fájlok
%TEMP%	tmp	Windows alatt a temp mappának a helyét be lehet állítani. A mappa neve TMP vagy TEMP rendszerint, és akárhol is lehet.
	var	Változó adatfájlok
	Boot	Rendszer betöltő fájlok, kernel, itt van mindaz, amit a GRUB indít. (pl. Memtest), ill. EFI partícióhoz is itt van csatolási pont UEFI rendszer esetén
	proc	Szolgáltatások és kernel modulok
	root	A root felhasználó mappája
	media	Az eltávolítható meghajtók csatolási mappája.
	mnt	Csatolási (mount) mappa
	srv	Szolgáltatások adatai

A képen balra a DC képe W10 alatt a C: meghajtóról. A zöld keretes mappákat a Windows hozza létre, a pirosakat felhasználó hozta létre, a kékeket meg olyan programok, amik nem a Program Files mappa alá települtek. A kép jobb oldali része u.a. gépen DC Linux alatt, annak mappastruktúrájával. A kép felső részén látszik a Windows meghajtó betűzése, a jobb oldalon meg a Linux jelölése. Egyes esetekben a kötetek a nevükkel szerepelnek. (Bal oldalon eggyel több meghajtó van, a B az a pendrájv, amiről a Windows futott)

A Linux mappastruktúrája körül mindig is, ma is magas szintű vita folyik. Jelenleg a többség az ősi kiosztást próbálja racionalizálni, apróbb változtatásokkal. Aktuális projekt pl. az usrmerge, ami az aktuális Linuxok alatt összevonja az alábbi mappákat:

/bin → /usr/bin
/sbin → /usr/sbin
/lib → /usr/lib
/lib64 → /usr/lib64

A /bin, /sbin, /lib, lib64 mappák látszólag megmaradnak, kompatibilitási okokból, de ezek csak simlinkek, azaz, bármelyiket megnyitva a nekik megfelelő másik mappa nyílik meg, pl. a bin mappa helyett az usr/bin.

Alábbi képen az usrmerge hatása:

A sárga mappák az „átirányítottak”

Vannak olyan disztribúciók is, amelyek teljesen szakítanak az alap mappastruktúrával. Az egyik konkrét példa a GOBO Linux, amelyik minden telepített programot külön mappába telepít a Programs mappa alatt, programnév és verzió számokból képzi a mappák nevét, azaz, adott programnak akár több verzióját is telepíthetjük így, és nem akadnak össze.

De voltak olyanok is, amik ember által nem értelmezhető hexadecimális kódsorokból felépült neveket használtak a mappákhoz.

Csatolásokkal kapcsolatos kezdők kérdései:

Ha egy eltávolítható eszközt (pendrájv, külső merevlemez, SD kártya, fényképezőgép, okostelefon) kapcsolunk a géphez pl. USB porton keresztül, akkor azt a Linux automatikusan csatolja, ikonja megjelenik az asztalon, illetve meg is nyílik egy ablak, amiben egyből elérhetők az azokon levő fájlok…

Miért nem jelenik meg a gépben levő második merevlemez ikonja az asztalon, miért csak akkor jelenik meg, ha Számítógépet megnyitva, abban a megfelelő merevlemez ikonján kattintva az meg van nyitva? Nem lehetne-e megoldani, hogy automatikusan csatolja?

- De, meg lehet oldani. Viszont! Ez így van jól. Ha szükség van a másik lemezre, akkor az elérhető a fentebb leírt módon, vagy bármelyik fájlmenedzser programon belül kiválasztva, akkor a lemez elindul, és csatolódik. Ha pedig nincs szükség rá, akkor meg minek csatolni, ha amúgy sem kell most? Addig is nincs használatban, kevesebb áramot eszik, és addig sem amortizálódik. Energia takarékosság, gazdaságosság, környezet terhelés, ezek is számítanak! Bocs, de nem írom le, hogy miként lehet beállítani az automatikus csatolást…

A cikk folytatódik, a következő részben a kezelő felületekről / kezelésről lesz szó...