# Obecné principy OS a embedded systémy

## Co je operační systém a jaké má hlavní funkce?

Operační systém (OS) je základní softwarová vrstva, která zajišťuje správu hardwarových prostředků a poskytuje služby aplikačním programům.

**Hlavní funkce:**
- Správa procesů (proces scheduling, multitasking)
- Správa paměti (alokace, ochrana, stránkování)
- Správa vstupně/výstupních zařízení (I/O)
- Správa souborového systému
- Správa bezpečnosti a přístupu (uživatelé, práva)
- Abstrakce hardwaru (poskytuje aplikačnímu softwaru jednotné rozhraní)

---

## Porovnej real-time a general-purpose operační systémy

| Vlastnost | Real-time OS (RTOS) | General-purpose OS (např. Linux, Windows) |
|------------------|--------------------------------------|-------------------------------------------|
| Účel | Zaručení včasné odezvy | Všeobecné použití, výkon a univerzálnost |
| Determinismus | Vysoký (předvídatelné chování) | Nízký až střední |
| Scheduler | Priority-based, často preemptivní | Obecný, např. fair-share, round-robin |
| Latence | Nízká a deterministická | Vyšší a variabilní |
| Použití | Průmyslové řídicí systémy, automobily| PC, servery, mobily |

---

## Jaké jsou hlavní charakteristiky embedded systémů?

- **Specifický účel**: navržený pro konkrétní funkci (např. mikrovlnka, automobil).
- **Real-time požadavky**: často potřebují garantovat odezvu v časových limitech.
- **Omezené zdroje**: málo paměti, výpočetního výkonu, energie.
- **Spolehlivost**: často nasazeno v kritických aplikacích.
- **Nízká spotřeba energie**: důležité pro mobilní nebo bateriově napájená zařízení.
- **Často bez uživatelského rozhraní.**

---

## Kdy a proč použít general-purpose systém?

Používá se, když:
- Je potřeba univerzální prostředí pro běh různých aplikací.
- Reálný čas není kritický.
- Je dostupný dostatek zdrojů (RAM, CPU).
- Je požadováno komplexní GUI, síťové funkce, kompatibilita s desktopovým SW.

**Příklad**: vývojové platformy, servery, pracovní stanice.

---

## Rozdíl mezi hard a soft real-time systémem

- **Hard real-time**: Nedodržení časového limitu je **nepřijatelné** a může způsobit selhání systému.
*Příklad: airbag v autě.*
- **Soft real-time**: Nedodržení limitu není fatální, ale snižuje kvalitu služby.
*Příklad: přehrávání videa.*

---

## Co znamená „predictability“ v kontextu embedded systémů?

„Predictability“ (předvídatelnost) znamená, že lze **spolehlivě odhadnout chování systému v čase** – konkrétně dobu odezvy a dobu vykonání úloh.
Je klíčová pro **real-time aplikace**, kde je důležité splnění časových požadavků.

---

## Role více-jádrových procesorů v embedded systémech

- Umožňují **paralelní zpracování úloh**, zvyšují výkon bez zvyšování frekvence.
- Mohou být použity pro **oddělení kritických a méně důležitých úloh**.
- Umožňují **nižší energetickou spotřebu** při vyšším výkonu (nižší takt na více jádrech).
- Vhodné např. v automotive nebo multimédiích.

---

## Rozdíl mezi P-cores a E-cores (heterogenní multiprocesorové systémy)

- **P-cores (Performance cores)**: Výkonná jádra, vysoký výkon, vyšší spotřeba.
- **E-cores (Efficiency cores)**: Úsporná jádra, nízká spotřeba, menší výkon.
- **Heterogenní architektura** (např. ARM big.LITTLE, Intel Alder Lake): umožňuje efektivní rozdělení zátěže – těžké úlohy na P-cores, lehké/úsporné na E-cores.
- **Redukovaná instrukční sada**: E-cores mají často redukovanou jejich instrukční sadu

---

## Co jsou to „zero power systems“?

- Systémy, které **neodebírají žádnou energii**, když nejsou aktivní.
- Využívají ultra-nízkopříkonové komponenty a techniky, např. **wake-up circuits**, **event-driven design**.
- Používají se ve **senzorových sítích**, IoT, wearables.

---

## Co říká Mooreův zákon a jak se vztahuje k vývoji embedded systémů?

- Mooreův zákon říká, že počet tranzistorů na čipu se **přibližně zdvojnásobuje každých 18–24 měsíců**.
- Umožňuje miniaturizaci, vyšší výkon a levnější čipy.

**Dopad na embedded systémy:**
- Integrace více funkcí do jednoho čipu (SoC)
- Vyšší výpočetní výkon při nižší ceně
- Možnost použití komplexních OS (např. Linux) i na malých zařízeních

# Správa procesů a systémová volání

## Vyjmenuj a stručně popiš hlavní komponenty operačního systému

- **Správa procesů (Process Management)**: vytváření, ukončování a plánování procesů.
- **Správa paměti (Memory Management)**: přidělování paměti, stránkování, ochrana paměti.
- **Správa souborového systému (File System Management)**: přístup k souborům, adresářová struktura.
- **Správa zařízení (Device Management)**: ovladače zařízení, I/O fronty.
- **Správa uživatelů a zabezpečení**: přístupová práva, autentizace.
- **Systémové volání a API**: prostředník mezi uživatelskými programy a jádrem.

---

## Co je proces a jaké činnosti s procesy OS provádí?

**Proces** je běžící instance programu, která má vlastní adresní prostor, registr CPU, otevřené soubory atd.

**OS s procesy provádí:**
- Vytváření a ukončení procesů
- Naplánování na CPU (scheduler)
- Správa kontextu procesů
- Synchronizaci a komunikaci mezi procesy
- Ochranu paměti a izolaci

---

## Co je PCB (Process Control Block) a co obsahuje?

**PCB** je datová struktura, kterou OS používá k reprezentaci procesu.

**Obsahuje např.:**
- ID procesu (PID)
- Stav procesu (running, ready, waiting...)
- Registry CPU
- Ukazatel na paměťové oblasti
- Otevřené soubory
- Informace pro plánování (priorita, kvanta)
- Informace o rodiči/potomcích

---

## Jaký je rozdíl mezi procesem a vláknem (thread)?

| Vlastnost | Proces | Vlákn(o) (Thread) |
|-----------------|-----------------------------|---------------------------------|
| Adresní prostor | Vlastní | Sdílí s ostatními vlákny |
| Izolace | Úplná (paměť, data) | Minimální |
| Vytváření | Nákladnější (fork/exec) | Levnější (např. pthread_create) |
| Použití | Běh oddělených programů | Paralelizace v rámci programu |

---

## Jaký je rozdíl mezi API a systémovým voláním?

- **API (Application Programming Interface)**: Rozhraní knihoven, které usnadňuje používání systémových volání (např. POSIX `open()`).
- **Systémové volání (System Call)**: Přímý přechod z uživatelského režimu do režimu jádra k provedení chráněných operací (např. `int 0x80`, `syscall`).

---

## Jak funguje systémové volání na úrovni CPU (trap, interrupt, návrat)?

1. **Trap**: Software generuje přerušení (`trap` instrukce) pro volání jádra.
2. CPU přepne režim na **privilegovaný (kernel mode)**.
3. Provádí se obsluha systémového volání (dispatcher volá příslušnou funkci).
4. Po dokončení dojde k návratu do uživatelského režimu (`iret`, `sysret`).

---

## Jaký je rozdíl mezi user mode a system mode?

| Vlastnost | User Mode | System Mode (Kernel Mode) |
|-----------------|-------------------------------|---------------------------------------------|
| Přístup k HW | Omezený | Plný |
| Paměť | Izolována | Přístup ke všem částem paměti |
| Nebezpečí chyb | Nižší | Vysoce rizikové (může způsobit pád systému) |
| Volání jádra | Nepřímo přes systémové volání | Nativně |

---

## Jak OS zabraňuje procesům v přístupu k paměti jiných procesů?

- Pomocí **hardwarové podpory paměťové ochrany**:
- Stránkování (paging)
- Segmentace
- Každý proces má svůj **virtuální adresní prostor**.
- Přístupy mimo přidělený prostor vedou k **segmentation fault**.
- **MMU (Memory Management Unit)** mapuje virtuální adresy na fyzické.

---

## Co jsou ochranné prstence (rings) v x86?

- Prstence určují úroveň oprávnění:
- **Ring 0**: jádro OS (nejvyšší privilegia)
- **Ring 3**: běžné uživatelské aplikace
- Prstence 1 a 2 se běžně nepoužívají v běžných OS.
- Slouží k **ochraně systému před neautorizovaným přístupem**.

---

## Popiš základní fáze bootování x86 systému

1. **Reset**: CPU se spustí z reset vectoru (např. 0xFFFF0).
2. **BIOS/UEFI**: Inicializace HW a načtení zavaděče.
3. **Bootloader** (např. GRUB): Načte a spustí jádro OS.
4. **Kernel**: Inicializace jádra a ovladačů.
5. **Init systém** (např. systemd): Spustí uživatelské služby.

---

## Jaké jsou rozdíly mezi BIOS, UEFI, Coreboot a Libreboot?

| Vlastnost | BIOS | UEFI | Coreboot | Libreboot |
|---------------|----------------|--------------------|-----------------------|------------------------|
| Typ | Zastaralý | Moderní firmware | Open-source firmware | Plně svobodný firmware |
| Disk support | Do 2TB (MBR) | >2TB (GPT) | GPT podpora možná | GPT podpora |
| Grafické UI | Ne | Ano | Ne | Ne |
| Cíl | Kompatibilita | Výkon + bezpečnost | Open HW/rychlost | Svobodný SW |

---

## Co je to reset vector?

- Adresa v paměti, na které procesor po zapnutí/RESETU **začne vykonávat instrukce**.
- U x86: typicky fyzická adresa **0xFFFFFFF0** (BIOS) nebo definovaná v UEFI.

---

## Co je to kernel module a jaký je rozdíl oproti built-in části jádra?

- **Kernel module**: načitatelná komponenta jádra za běhu (např. ovladač).
- **Built-in**: pevně zkompilováno v jádře, nelze odebrat bez rekompilace.
- Výhoda modulů: **flexibilita, nižší paměťová náročnost, dynamické načítání**.

---

## Co je potřeba udělat při přepnutí kontextu?

1. Uložit stav běžícího procesu:
- Registry CPU
- Ukazatel zásobníku
- Program Counter
2. Obnovit stav nového procesu:
- Načíst registry
- Nastavit paměťový kontext
- Nastavit instrukční čítač

---

## Kdy ke kontextovému přepnutí dochází a proč?

Nastává při:
- Vypršení časového kvanta (u preemptivního plánovače)
- Čekání na I/O
- Dobrovolném uvolnění CPU (např. `sleep()`)
- Vyšší priorita jiného procesu

**Cíl**: efektivní sdílení CPU mezi více procesy.

# Výkon, spotřeba a plánování úloh

## Vztah mezi výkonem a energií

- **Výkon (performance)**: jak rychle se úloha dokončí (např. MIPS, FLOPS).
- **Energie (energy)**: celková spotřeba elektrické energie = příkon × čas.
- **Příkon (power)**: okamžitá spotřeba energie (Watt = Joule/s).

💡 Energie = Příkon × Čas
Zvýšení výkonu (zkrácení doby výpočtu) může snížit celkovou energii, i když příkon je vyšší.

---

## Kdy platí, že rychlejší výpočet znamená nižší spotřebu?

- Pokud úloha běží **rychleji**, může se systém dříve přepnout do úsporného režimu (sleep).
- Např.:
- **Race-to-sleep** strategie: co nejrychleji dokončit výpočet a přejít do hlubokého spánku.
- Platí, pokud rozdíl v příkonu není příliš velký.

---

## Vysvětli rozdíl mezi nízkým příkonem (low power) a nízkou spotřebou energie (low energy)

| Vlastnost | Low Power | Low Energy |
|-------------------|-------------------------------------|------------------------------------------|
| Co znamená | Nízký okamžitý příkon (W) | Nízká celková spotřeba (J) |
| Důraz | Dlouhodobý běh, úsporné komponenty | Rychlé dokončení výpočtu a vypnutí |
| Příklad | Hodinky, senzory | Mobilní CPU, které rychle vypočítá a spí |

---

## Z čeho se skládá spotřeba CMOS obvodů?

1. **Dynamická spotřeba (dominantní):**
- Nabíjení/vybíjení kapacitních zatížení (C × V² × f)
- Závislá na frekvenci a napětí

2. **Statická spotřeba:**
- Průsakové proudy (leakage current)
- Rostoucí problém u menších technologií (< 20nm)

---

## Co je to power gating a jak pomáhá?

- Technika vypínání **nepoužívaných částí čipu** (např. jádro CPU, cache).
- Odpojí napájení pomocí tranzistorů (tzv. sleep transistor).
- Výrazně sníží **statickou spotřebu**.
- Vyžaduje rychlé „probuzení“ při potřebě.

---

## Jak funguje Dynamic Voltage Scaling (DVS) a jak ovlivňuje výkon a spotřebu?

- **Snížení napětí (V)** snižuje výkon CPU, ale i spotřebu (díky kvadratické závislosti spotřeby na napětí: P ∝ V² × f).
- Lze jej použít, když není potřeba maximální výkon.
- Při nízkém zatížení šetří energii, ale může prodloužit výpočet.

---

## Co je DVFS (Dynamic Voltage and Frequency Scaling)?

- Rozšíření DVS – mění se **napětí i frekvence** CPU.
- Vysoká frekvence = vyšší výkon, ale vyšší spotřeba.
- Nízká frekvence + nízké napětí = úspora energie.
- Dynamicky řízeno OS (např. **cpufreq** v Linuxu).

---

## Jak se plánují úlohy na heterogenních procesorech (např. big.LITTLE architektura)?

- OS nebo plánovač rozhoduje:
- Která úloha se má spustit na **P-core** (výkonné) nebo **E-core** (úsporné).
- Cílem je **vyvážení mezi výkonem a spotřebou**.
- Např. nízkoprioritní úlohy → E-core, interaktivní úlohy → P-core.

---

## Jak se rozdělují úlohy podle energetických domén?

- Energetické domény = části čipu s vlastním napájením (např. GPU, CPU, DSP).
- Úlohy se přidělují tak, aby:
- Využívaly domény s optimálním poměrem výkon/energie.
- Nedocházelo k přetížení jednoho subsystému.
- Příklad: zpracování videa v DSP místo CPU → nižší spotřeba.

---

## Jaký je rozdíl mezi: Race-to-sleep vs. Crawl-to-sleep

| Strategie | Race-to-sleep | Crawl-to-sleep |
|-------------------|-----------------------------------|---------------------------------------|
| Princip | Rychlé dokončení a usnutí | Pomalý běh se sníženým výkonem |
| Výhoda | Krátký čas běhu, delší spánek | Nízký příkon |
| Použití | Když je přechod do spánku levný | Když je wake-up drahý nebo omezený |

---

## Co je DPM a jaké má režimy (RUN, IDLE, SLEEP)?

**DPM (Dynamic Power Management)** – techniky pro řízení napájení za běhu systému.

**Typické režimy:**
- **RUN** – plný výkon, maximální spotřeba.
- **IDLE** – CPU nic neprovádí, ale je připraven ihned reagovat.
- **SLEEP** – hlubší režim úspory, dlouhá reakční doba (vyžaduje „wake-up“).

# Plánování procesů – algoritmy a víceprocesorové systémy

## Rozdíl mezi preemptivním a nepreemptivním plánováním

- **Preemptivní**: proces může být **přerušen** OS ve prospěch jiného (např. vyšší priorita).
- **Nepreemptivní**: proces běží až do konce nebo do vlastní blokace (např. I/O).

**Výhoda preemptivního**: lepší odezva, férovost
**Nevýhoda**: vyšší režie (context switch)

---

## Jaké jsou žádoucí vlastnosti plánovače?

- **Férovost**: rovnocenná šance sdílení CPU
- **Efektivnost**: procesor trvale jede na 100%
- **Doba odezvy**: minimální odezva pro interaktivní uživatele
- **Doba běhu**: minimální čas čekání na vykonání zadání uživatele (dávky)
- **Průchodnost**: maximální čas procesů vykonaných během jedné čas. jednotky

---

## Co je stárnutí (aging) a jak pomáhá proti hladovění?

- **Aging** = postupné **zvyšování priority** dlouho čekajících procesů.
- Chrání proti **hladovění** (starvation) u algoritmů, které preferují krátké/urgentní procesy.

---

## Jaké problémy mohou nastat bez správného plánování?

- **Hladovění (starvation)**: proces nikdy nedostane CPU.
- **Zablokování (deadlock)**: skupina procesů čeká na zdroje od sebe navzájem.
- **Nízká propustnost**, **nefér přístup**, špatná odezva systému.

---

## Algoritmy plánování procesů

### FCFS (First-Come-First-Served) - FIFO lool

- **Princip**: úlohy se provádí v pořadí příchodu.
- **Preemptivní?**: Ne
- **Výhody**: jednoduchost
- **Nevýhody**: dlouhá čekací doba, **convoy effect**
- **Použití**: dávkové systémy

---

### SJF / SRTF (Shortest Job First / Shortest Remaining Time First)

- **SJF (Nepreemptivní)**: běží proces s nejkratší dobou provedení
- **SRTF (Preemptivní)**: běží proces s nejkratší zbývající dobou
<br/>
- **Výhody**: optimální průměrná čekací doba
- **Nevýhody**: potřeba znát délku procesu, náchylné k hladovění
- **Použití**: simulace, analytické systémy

---

### Priority scheduling

- **Princip**: procesy mají prioritu, běží ten s nejvyšší.
- **Preemptivní?**: Ano i Ne
- **Výhody**: řízení naléhavosti
- **Nevýhody**: hladovění nízkých priorit
- **Řešení**: aging

---

### Round Robin

- **Princip**: každý proces dostane **časové kvantum**.
- **Preemptivní?**: Ano
- **Výhody**: férové, dobrá odezva
- **Nevýhody**: závislost na délce kvanta
- **Použití**: interaktivní systémy

---

### Multilevel Queue Scheduling

- **Princip**: fronty podle typu úloh (např. systémové, uživatelské).
- Každá fronta má vlastní plánovací algoritmus.
- **Nevýhody**: statické, neumožňuje pohyb mezi frontami.

---

### Multilevel Feedback Queue

- **Princip**: jako multilevel queue, ale **umožňuje přesun** mezi frontami na základě chování procesu.
- **Výhody**: adaptivní, flexibilní
- **Nevýhody**: složitá implementace
- **Použití**: Unix/Linux plánovače

---

### Lottery Scheduling

- **Princip**: každému procesu přiděleny "lístky", náhodné losování.
- **Preemptivní?**: Ano
- **Výhody**: jednoduché, probabilisticky férové
- **Nevýhody**: náhodnost
- **Použití**: výzkumné OS, experimenty

---

## Co je technologie big.LITTLE? Jaké jsou její výhody a rizika?

- **big.LITTLE**: kombinace výkonných (big) a úsporných (LITTLE) jader. (efficiency a power cores)
- **Výhody**: úspora energie, možnost paralelního zpracování
- **Rizika**:
- Složitější plánování
- Nekompatibilita v registrech/ISA (např. různé výkonové charakteristiky)
- Možné problémy se synchronizací

---

## Rozdíl mezi asymetrickým a symetrickým víceprocesorovým plánováním

| Typ | Asymetrické (AMP) | Symetrické (SMP) |
|-----------------|----------------------------|-------------------------------|
| Plánování | Pouze jeden CPU plánuje | Každý CPU má vlastní plánovač |
| Komplexita | Nižší | Vyšší, nutná synchronizace |
| Výhoda | Jednoduché, predikovatelné | Lepší škálování, využití CPU |

---

## Co je procesorová afinita (soft vs hard)?

- **Procesorová afinita**: určuje, na kterých jádrech smí běžet proces.

| Typ | Popis |
|----------|--------------------------------------------|
| **Soft** | preferované jádro, ale OS může změnit |
| **Hard** | pevně vázané, OS nesmí měnit |

---

## Jak funguje load balancing mezi procesory (push vs pull migration)?

- **Push migration**: plánovač aktivně přesune proces z přetíženého CPU.
- **Pull migration**: nevyužitý CPU si "vytáhne" úlohu z jiného.
- Cíl: rovnoměrné zatížení všech CPU.

---

## Jaké problémy řeší locky, cache coherence a sdílená data v SMP (Symetric MultiProcessing) systémech?

- **Locky**: zabránění kolizím při přístupu ke sdíleným datům. (řešení kritické sekce)
- **Cache coherence**: zajištění konzistence dat mezi více CPU cache.
- **Sdílená data**: riziko race conditions, potřeba synchronizace.

---

## Co jsou C-stavy (C0–Cn) – lokální režimy spánku CPU?

- **C-stavy** definují úroveň nečinnosti jednotlivých CPU.
- **C0**: aktivní běh
- **C1–Cn**: stále hlubší režimy spánku (nižší spotřeba, vyšší latence probuzení)
- Volí se podle vytížení a požadavků na odezvu.

---

## Co jsou S-stavy (S1–S5) – globální systémové stavy?

- **S-stavy** (ACPI power states) určují **globální** napájecí režim systému.

| Stav | Popis |
|------|--------------------------------|
| S0 | Systém běží |
| S1 | CPU stopped, RAM aktivní |
| S2 | CPU no power, RAM aktivní |
| S3 | Suspend to RAM (sleep) |
| S4 | Suspend to disk (hibernace) |
| S5 | Vypnuto |

# Souborové systémy – obecně i specificky (FAT, ext, NTFS)

## Co je souborový systém a jaké funkce plní?

Souborový systém (FS) je metoda organizace, ukládání a správy dat na úložišti.

**Funkce:**
- Ukládání a načítání souborů
- Hierarchická struktura (adresáře)
- Přístupová práva a metadata
- Správa volného místa
- Odolnost proti chybám (žurnálování apod.)

---

## Jak jsou organizovány data na úložišti?

- **Sektor**: nejmenší adresovatelná jednotka HW (např. 512 B, 4 KB)
- **Blok (Cluster)**: 1 nebo více sektorů

---

## Jak funguje hierarchická struktura adresářů?

- Stromová struktura: složky mohou obsahovat soubory i další složky.
- Každý adresář obsahuje záznamy s názvy a ukazateli (např. inode čísla).
- Cesta k souboru může být absolutní (od rootu) nebo relativní.

---

## Co je to root filesystem? Jak se liší od kernelu?

- **Root filesystem** je hlavní adresářová struktura systému, dostupná pod `/`.
- Obsahuje např. `/bin`, `/etc`, `/usr`, `/home`.
- **Kernel** je součást OS, stará se o nízkoúrovňové operace; není to souborový systém. Je to jiná entita

---

## Co je VFS (Virtual File System) a jakou roli hraje?

- Abstrakce nad konkrétními FS – jednotné API (např. `open()`, `read()`).
- OS může používat různé FS (ext4, FAT, NTFS…) bez změny v aplikacích.

---

## Jaké typy souborových systémů Linux podporuje?

- **Nativní**: ext2, ext3, ext4, XFS, Btrfs, ReiserFS
- **Virtuální**: procfs, sysfs, tmpfs, devtmpfs
- **Síťové**: NFS, SMB, SSHFS
- **Cizí**: FAT, NTFS (přes FUSE nebo ntfs3)

---

## Co je FUSE a jak umožňuje uživatelské implementace FS?

- **FUSE (Filesystem in Userspace)**: rozhraní pro tvorbu FS mimo kernel.
- Vývojáři mohou napsat FS v uživatelském prostoru (např. v Pythonu).
- Jádro komunikuje s uživatelským démonem přes FUSE modul.

---

## Jaké jsou typické aplikace FUSE souborových systémů?

- EncFS, SSHFS, archivní FS (ZIP jako FS), síťové FS, šifrování na úrovni FS

---

## Jak probíhá bootování z pohledu souborového systému?

1. **Bootloader** načte kernel a případně initramfs.
2. **Kernel** připojí rootfs.
3. Spustí init proces (`/sbin/init`, `systemd`).

---

## Co je initramfs, rootfs, a jak se používají?

- **initramfs**: dočasný kořenový FS (v RAM), obsahuje init skripty a ovladače.
- initramfs slouží k inicializaci HW, pak se připojí skutečný root.
- **rootfs**: cílový FS připojený jako `/`.

---

## Co je MBR (Master Boot Record) a jak je strukturován?

- Prvních 512 B disku.
- Obsahuje:
- **bootloader** (446 B)
- **partition table** (4 záznamy po 16 B)
- **boot signatura** (2 B) - 0x55aa
- Omezení: max. 4 primární oddíly, disk do 2 TB.

---

## Co je GPT (GUID Partition Table) a jaké výhody přináší?

- Novější standard (součást UEFI).
- Podpora až 128 oddílů, disky větší než 2 TB.
- Redundantní záznamy pro vyšší odolnost.
- Každý oddíl má **GUID**, název, atributy.
- Struktura
- Na začátku Protective MBR (ochrana pro legacy toolky)
- Hlavička GPT
- GUID disku
- Kde tabulky oddílů?
- Primární i backup
- Velikost položky
- Kolik místa zabírá jeden záznam o partition v této tabulce
- Počet položek oddílů
- Kolik lze na disku udělat partitions?
- CRC (corrupted -> použij backup)
- Tabulka oddílů
- Jednotlivé záznamy
- GUID typu oddílu
- EFI sys oddíl?
- Windows data oddíl?
- Linux oddíl?
- GUID oddílu
- Počáteční a koncová LBA oddílu
- Prostě kde je (od - do)
- Atributy oddílu
- Např bootable?
- Název (human readable - až 36 unicode)
- Záloha GPT
- Na konci -> nejdřív tabulka, pak header

---

## Rozdíl mezi MBR a GPT? Kdy se používají?

| Vlastnost | MBR | GPT |
|----------------|-----------------------|---------------------------|
| Max. velikost | 2 TB | > 2 TB |
| Počet oddílů | 4 primární | až 128 |
| Redundance | Ne | Ano (záložní tabulka) |
| Použití | Starší BIOS systémy | Nové systémy s UEFI |

---

## Jak funguje FAT12/16/32 – struktura a princip práce?

- **struktura**: MBR, FAT table, (Root direcotry), Data
- Používá **FAT tabulku**, která sleduje řetězec bloků souboru.
- **FAT12**: pro disky do 32 MB
**FAT16**: do 2 GB
**FAT32**: až 32 GB (někdy i víc, omezeno OS)

---

## Co je FAT tabulka? Jak se používá?

- Tabulka s ukazateli na další cluster souboru (formou linked-listu).
- Každý záznam říká, kde pokračuje obsah souboru.

---

## Jak FAT řeší dlouhé názvy souborů?

- Používá **VFAT**: speciální záznamy v adresáři s Unicode jmény.
- Soubory mají stále 8.3 (AAAAAAAA.BBB) kompatibilní jméno (DOS-style).

---

## Jaké jsou výhody a nevýhody FAT16/FAT32?

**Výhody:**
- Široká podpora (OS, zařízení)
- Jednoduchost
- Efektivnost zvlášť pro zařízení menší než 256MB

**Nevýhody:**
- Fragmentace
- Bez žurnálování
- FAT16: malá max. velikost
- FAT32: omezení velikosti souboru (4 GB)

---

## Jaké novinky přináší exFAT oproti FAT32?

- Vyšší limity velikosti souborů i oddílů
- Vylepšená alokace (bitmapa volných clusterů)
- Podpora větších clusterů
- Licencováno Microsoftem (Linux: exfat-utils, exfat-fuse)

---

## Co je inode a co obsahuje? Proč není jméno souboru součástí inode?

- **inode** je datová struktura popisující soubor.
- Obsahuje:
- Velikost, přístupová práva, časová metadata
- Ukazatele na datové bloky
- **Jméno není součástí** inode → umožňuje hardlinky

---

## Jak funguje adresář v ext2/ext3?

- Adresář je soubor obsahující páry:
- **jméno souboru** + **číslo inode**
- Vyhledání probíhá porovnáním jmen.

---

## Popiš strukturu souborového systému ext2

- **Superblok** – metadata FS (velikost, počet inode…)
- **Skupiny bloků (block groups)**:
- Bitmapy bloků a inode
- Tabulka inode
- Datové bloky

---

## Jak se ext2/ext3/ext4 liší v použitelnosti a výkonu?

| Vlastnost | ext2 | ext3 | ext4 |
|-----------|--------------|-------------------|---------------------------------|
| Žurnál | Ne | Ano | Ano |
| Výkon | Rychlý zápis | Odolný vůči pádům | Lepší škálování |
| Funkce | Základní | Spolehlivý | Extents, multibloky, timestamps |

-----

## Srovnání souborových systémů Ext2, Ext3 a Ext4

| Vlastnost / Souborový systém | Ext2 (1993) | Ext3 (2001) | Ext4 (2008) |
| :--------------------------- | :---------- | :---------- | :---------- |
| **Základní vlastnosti** | Tradiční Unix inode; funkce z Unix File System | Vše z Ext2 + žurnálování | Vše z Ext3 + extenty, 48bit adresace |
| **Žurnálování (Journaling)** | Ne | Ano (3 typy: writeback, ordered, data) | Ano (výchozí: ordered) |
| **Maximální velikost svazku** | 32 TB | 32 TB | 1 EB (Exabajt) |
| **Maximální velikost souboru** | 2 TB | 2 TB | 16 TB (s 4 KiB bloky) |
| **Extenty** | Ne | Ne | Ano (souvislé bloky, zlepšuje výkon a snižuje fragmentaci) |
| **Počet podadresářů** | Omezeno (max 32 000) | Omezeno (max 32 000) | Neomezeno (dříve 64 000) |
| **Indexování adresářů** | Ne | HTree (32bit) | HTree (64bit) |
| **Online zvětšování FS** | Ne | Ano | Ano |
| **Rezerva pro superuživatele**| \~5% bloků | \~5% bloků | Nastavitelné (výchozí 5%) |
| **Volitelná velikost bloku** | Ano (1, 2, 4 KiB) | Ano (1, 2, 4 KiB) | Ano (1, 2, 4 KiB) |
| **Sledování stavu FS** | Ano | Ano | Ano |
| **Časová razítka** | Modifikace dat | Modifikace dat | Zlepšená přesnost (nanosekundy), vytvoření, přístup, modifikace |
| **Atributy souborů/adresářů** | Ano | Ano | Ano |
| **Checksumming (kontrola integrity)** | Ne | Ne (pouze žurnál) | Žurnál, metadata (volitelné) |
| **Perzistentní pre-alokace** | Ne | Ne | Ano (rezervace místa na disku pro soubor, zabraňuje fragmentaci) |
| **Transparentní šifrování** | Ne | Ne | Ano (od jádra Linux 4.1, prostřednictvím fscrypt) |
| **Odložená alokace (Delayed allocation)** | Ne | Ne | Ano (data nejsou zapsána okamžitě, ale po nashromáždění, zlepšuje výkon) |
| **Rychlejší kontrola FS (fsck)** | Pomalejší | Pomalejší | Rychlejší (díky inode tabulkám a skupinám) |
| **Zpětná kompatibilita** | Kompatibilní s Ext3/Ext4 | Kompatibilní s Ext2; s Ext4 lze připojit | Kompatibilní s Ext2/Ext3 (lze připojit jako Ext3) |

-----

### Další rozdíly a detaily

| Vlastnost | Detaily |
| :------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Typy žurnálování (Ext3)** | **Writeback:** Zapisuje pouze metadata do žurnálu. Nejrychlejší, ale při pádu může dojít ke zmatení metadat a dat. \<br\> **Ordered:** Zapisuje metadata do žurnálu a zajišťuje, že data jsou zapsána na disk před metadaty. Dobrý kompromis mezi bezpečností a výkonem. \<br\> **Data:** Zapisuje jak metadata, tak i data do žurnálu. Nejpomalejší, ale nejbezpečnější, zajišťuje nejvyšší integritu dat. |
| **HTree Indexování** | Zlepšuje výkon pro velké adresáře tím, že organizuje položky adresářů do hashovaných stromů, což urychluje vyhledávání. |
| **Inode size (Ext4)** | Standardně 256 bytů (oproti 128 bytů u Ext2/Ext3), což umožňuje více místa pro atributy a časová razítka s vyšší přesností. |
| **Online defragmentace (Ext4)** | Existují nástroje jako `e4defrag`, které umožňují defragmentaci za běhu systému, i když extenty snižují její nutnost. |
| **Záměna souborů (Ext4)** | `fallocate()` systémové volání pro efektivní alokaci místa pro soubory, což je užitečné pro databázové aplikace a virtuální stroje. |
| **Odolnost proti chybám** | Ext4 je díky checksummingu žurnálu a metadat, perzistentní pre-alokaci a dalším vylepšením robustnější proti korupci dat při výpadcích napájení. |
| **Podpora velkých souborů** | Díky 48bitové blokové adresaci a extentům Ext4 výrazně navyšuje limity pro velikost souborů a celých svazků, což je klíčové pro moderní datová centra. |

---

## Co dělají nástroje fsck, debugfs a kdy se používají?

- **fsck**: kontrola a oprava konzistence FS (po pádu, chybě).
- **debugfs**: nástroj pro ruční prohlížení/ext2/3/4 FS (analýza, vývoj).

---

## Jaký je účel žurnálu u ext3/ext4?

- Zajišťuje **konzistenci FS po výpadku**.
- Změny se nejdříve zapisují do žurnálu → po potvrzení se aplikují do FS.
- Zrychluje obnovu po pádu (není třeba úplný fsck).

---

## Jak se obnovuje konzistence FS po pádu systému?

- Pomocí:
- **Journalingu** (ext3/ext4)
- **fsck**: provádí kontrolu a opravu
- U non-journal FS (ext2) trvá déle a může dojít ke ztrátám.

---

## Jaké klíčové vlastnosti přináší NTFS?

- **Žurnálování**
- **ACL (Access Control Lists)**
- **Šifrování (EFS)**
- **Diskové kvóty**
- **Komprese**
- **Alternativní datové streamy**

---

## Co je $MFT a jak je strukturováno?

- **Master File Table (MFT)**: hlavní databáze NTFS
- Každý soubor = záznam v MFT
- Obsahuje:
- Metadata (název, velikost)
- Ukazatele na datové bloky
- Atributy (bezpečnost, timestamps)

---

## Co je MTD zařízení a proč se nepoužívá klasické blokové FS?

- **MTD (Memory Technology Device)**: rozhraní pro přístup k flash pamětem
- Používá se pro **raw flash** (bez řadiče)
- Potřebuje specifické FS: JFFS2, YAFFS, UBIFS

---

## Jak funguje zápis do flash (circular log, wear leveling)?

- Flash paměti nelze přepisovat po jednotlivých bajtech.
- Nutné:
- **Mazat celé bloky**
- **Wear leveling**: rovnoměrné opotřebení
- **Log-structured FS**: nové zápisy do volného místa, staré se označí jako neplatné

# Flash paměti a specifické souborové systémy

## Proč klasické FS nejsou vhodné pro flash čipy?

Klasické souborové systémy (např. ext4, FAT) předpokládají:
- Náhodný přístup,
- Časté přepisování bloků,
- Žádné omezení na počet zápisů.

**Flash paměti však:**
- Mají **omezený počet zápisů/mazání** na blok,
- Vyžadují **mazání po větších blocích** (např. 128–512 KB),
- Nelze přepsat záznam přímo → nutnost přepsat celý blok.

📌 Výsledkem by byla rychlá degradace flash paměti a nízká životnost.

---

## Co je MTD zařízení a proč se nepoužívá klasické blokové FS?

- **MTD (Memory Technology Device)** je rozhraní v Linuxu pro **raw flash** paměti (bez FTL – flash translation layer).
- Přímo zpřístupňuje paměť typu NOR/NAND (bez simulace bloku).
- Klasické FS (ext4, FAT) **neumí pracovat s požadavkem mazání po blocích** a s wear levelingem → selhání a poškození paměti.

📌 Proto se používají speciální FS, které s těmito omezeními počítají.

---

## Jak funguje zápis do flash (circular log, wear leveling)?

- **Log-structured FS**: místo přepisování zapisuje nová data **na nové místo**.
- Staré bloky jsou označeny jako **neplatné**, mazány později (garbage collection).
- **Wear leveling**: algoritmus, který se snaží **rovnoměrně opotřebovávat** bloky flash paměti.
- Dva typy:
- **Static**: přesun i často neměněných dat
- **Dynamic**: rotace pouze měněných bloků

---

## Příklady FS vhodných pro flash

| FS | Vhodný pro | Vlastnosti |
|------------|----------------|------------------------------------------------------------|
| **JFFS2** | NAND/NOR (MTD) | Log-struktura, komprese, pomalé mountování |
| **YAFFS2** | NAND (MTD) | Rychlejší než JFFS2, jednoduchost |
| **UBIFS** | NAND (MTD) | Nahrazuje JFFS2/YAFFS2, lepší škálování |
| **F2FS** | eMMC/SD (s FTL)| Flash-friendly FS od Samsungu, běží nad blokovým zařízením |

---

## Shrnutí rozdílů mezi klasickými a flash-friendly FS

| Vlastnost | Klasické FS (ext4, FAT) | Flash-friendly FS (UBIFS, F2FS) |
|-----------------------|--------------------------|----------------------------------|
| Zápis na místo | Ano | Ne – vždy nový záznam |
| Mazání před zápisem | Neřeší | Ano – správa bloků |
| Wear leveling | Není | Ano |
| Pomalý zápis | Možný | Optimalizovaný pro flash |
| Žurnálování | ext3/4 – ano | Různé přístupy (log, checkpoint) |

# Letem světem Filesystémy

## FAT - File allocation table

- klasicky 2 kopie FAT
- FAT12, 16, 32 -> význam -> kolik bitů pro FAT entry
- Boot sector - reserved sectors - FAT1 - FAT2 - Root folder - Data
- 4 oblasti zvlášť pro každou partition
- Boot record - na začátku partition
- Definuje partition a říká, kde jsou ostatní 3 oblasti dané partition
- Jestli je to bootable, obsahuje taky kód potřebný pro boot
- FAT (1, 2) - lookup table jako linked list
- Root dir
- Fixed délka, hned za FAT ve FAT12 a FAT16
- Data
- Partition je rozdělena do clusterů (2 kB ~ 32 kB)
- Soubor je chain clusterů
- **Stavy clusteru** ve FAT
- Unused
- Used by a file (neposlední - ukazuje dál)
- Last cluster in a file
- Bad cluster
- FAT entry
- Name (8.3)
- Atributy (1 byte)
- Create time, date (3 + 2 bytes)
- Last access date (2 bytes)
- Last modified time, date (2+2)
- Starting cluster (2 nebo 4)
- File size (4)
- Long names
- Pro VFAT -> nemají nativně 12 a 16
- 32 už má VFAT v sobě, takže tam už nativně
- Další entries (jsou před tím reálným entry, ta první (resp. poslední - jsou v opačném pořadí) má název ORnutý s 0x40), každý má 13 dalších unicode znaků
- Pak teprv ten reálný s 8.3, kde se nechá přípona a na poslední místa fname (8) se dává "-1"
- Atribut LFN
- Pozná se to podle checksumu asi - každý má checksum toho 8.3
- Limity
- Max 512 root entries
- FAT16 max 65536 clusterů
- Neefektivní na větších partitionech
- Žádná komprese a securita

### exFAT
- File size: 16 EB
- Disk size: 128 PB
- Metadata integrity - checksums
- Performance++ (allocation bitmap)
- Podpora transakcí (optional)
- Stream extension
- File directory entry (atributy, timestamp)
- Stream extension entry
- Data length (velikost souboru)
- Valid data length (kolik je platných dat - zbytek může být naalokovaný, ale ještě nevynulovaný)
- First cluster
- Cluster count
- Flags (souvislé nebo je nutné projít FAT?)
- Souvislý - start + count
- Nemusí být ve FAT - pro hledání free místa je bitmapa, takže se nemusíme srát s FAT
- Nesouvislý - FAT

## Ext - Extended file system

### Ext
- File size: 2 GB
- Partition size: 2 GB
- První systém
- Fname: 255
- Jen jedna timestamp (created)
- Přesnost na sekundy
- Pro free space --> linked-list

### Ext2
- File size: 2 TB
- Volume size: 32 TB
- **Cca 5 % bloků je rezervovaných pro superusera**
- ACL (oprávnění)
- Extended Attributes
- Logický blok může nastavit admin (1, 2, 4 kiB)
- Modification timestamp
- Přesnost na sekundy
- Data structure
- Místo rozděleno na bloky --> block groups
- Boot sector - [block groups]
- Block group
- Superblock (v pozdějších revizích jen některé groupy)
- Group descriptor
- Block bitmap
- Inode bitmap
- Inode table
- Data blocks
- **Bitmapy** mapují, které bloky a které inodes jsou použity
- **Superblock**
- **Metainfo o celém FS**
- **Popisuje basic size and shape**
- Co to je za fs?
- Jak velké jsou bloky?
- Kolik bloků (obsazených / volných) tam je?
- Kolik inodes (obsazených / volných)?
- **Inode** = základní stavební kámen
- **Každý soubor (složka) je popsán právě jedním inode (128 bytů)**
- Název nemá - inode je basically link na ten soubor - podporuje tak hardlinky jednoduše
- Složky (resp. entries) jsou ve formátu "**inode** - rec_len - name_len - file_type - **name**"
- Každý řádek je link
- Soubory se hledají pomocí full path a po levelech se takhle sestupuje po inodech
- Obsahuje všechny důležité informace:
- Mode
- Owner info
- 3 timestampy
- **Datablocky**
- Pointery na bloky s daty
- 12 direct blocků (ptr -> data)
- Každý z nich má kapacitu 1 * block_size
- single indirect (ptr -> blok pointerů -> data)
- Když máme 4kB block a ptr délky 4B, tak to je 1024 pointerů na block -> 1024 * 4kb = 4 MB pro 1 single indirect
- double indirect (ptr -> blok pointerů -> blok pointerů -> data)
- 1024 * 1024 * 4096 = 4 GB
- triple indirect
- 1024 * 1024 * 1024 * 4096 = 4 TB
- Limit ext2/3 je 2TB, protože je tam 32bit field "i_blocks" -> kolik má inode bloků. A tam se vleze jen 2^32 => 2 TB

- Superblock + Inodes -> jsou systémové propky -> mají fixed format a nejdou přímo upravovat

### Ext3
- File size: 2 TB
- Volume size: 32 TB
- Jde předělat na ext2 a naopak bez backup / repartitioning
- Ext2 je furt lepší na flashky, protože míň zápisů (ne journal)
- Nové featury
- **Žurnál**
- **Online FS growth**
- HTree indexing pro větší složky (32bit)
- Žurnál levely
- **Journal** (lowest risk) - vše se píše do žurnálu před commitem do FS
- **Ordered** (medium risk) - jen metadata do žurnálu; nejdřív zápis dat, pak commit metadat
- **Writeback** (highest risk) - jen metadata do žurnálu
- Block allocator
- Začíná ze stejné groupy, kde je daná inode struktura (kde je složka, do které píšu) - ať je to blízko u sebe
- **Konkurence**
- -> block reservation
- Pořád bitmapy na free block reservation
- Nevýhody
- Max 31 998 podsložek ve složce
- Není online defrag
- Čas jako 32bit unix (max 2038)

### Ext4
- File size: **16TB**
- Volume size: **1EB**
- obojí pro 4kB block size
- **48bit block adresace**
- **Extent**
- Mapuje části souborů na oblasti (range bloků)
- Větší soubory - extent tree
- Neomezený počet podsložek
- **Checksum**
- Metadata a Journal
- Alokace bloků
- **Multiblock allocator**
- **Persistent prealloc**
- Aplikace řekne
- **Delayed alloc**
- Alokuje až na flush(), ne na write()
- Spojí se tak víc alokací do jendoho requestu -> menší fragmentace, šetří CPU
- Online defrag
- Lepší timestamps
- Nanosekundy
- Transparent encryption

### FSCK - File System ChecK
- A taky chdsk
- Když systém crashne - disk nemusí být konzistentní
- Scan všech inodů -> každý blok musí náležet právě jednomu inodu, NEBO je na free listu
- Počet linků na každý soubor musí být korektní (prohledání všech složek)
- Většinou nabízí fix
- Plus další checky

## NTFS
- **Nástupce FAT**
- **Journaling**
- **Encryption**
- **ACL**
- **ADS (Alternativní data streamy)**
- **Komprese**
- **Sparse files**
- **Disk quotas**
- **Reparse points**

### NTFS
- Vše je soubor
- **$MFT** - Master File Table
- Záznam pro každý soubor a složku (včetně sebe)
- Záznamy 1024 B
- Header "FILE" pro identifikaci záznamu
- Struktura záznamu
- Header - Attributes
- Common atributy
- $Standard_Information
- Má flagy, timestampy apod
- $File_Name
- Názvy souboru -> normální název i 8.3 pro zpětnou kompatibilitu
- $Data
- Ukazuje na data souboru
- **Formát "start cluster - length" pro každý soubor**
- Pokud je soubor malý - data jsou přímo v $Data
- 12 % disku je alokováno pro $MFT
- 64bit timestampy -> stovky nanosekund od 1601
- Created
- Modified
- Accessed
- MFT entry modified
- Velikost souboru
- Logická => Jak velký se ten soubor tváří pro aplikaci (sparse files)
- Initialized => kolik dat tam reálně je zapsaných
- Fyzická => kolik místa to zabírá (bloky)
- Sparse files
- Časté pro virtuální disky (virtualbox)
- Taky pro databáze apod
- Soubor může mít plno volného místa, jen některé oblasti s reálnými daty
- Real oblasti se smrsknou k sobě a zapíšou na disk
- Prázdné oblasti (sparse zeros) -> nejsou zapsány na disku -> když se na ně aplikace zeptá, FS vrátí nuly
- ADS - Alternativní Data Streamy
- Každý soubor má $Data stream (nepojmenovaný) - ten jde normálně vidět
- Další pojmenované streamy
- example.txt:stream1
- Viditelné jen pro NTFS volumes
- Často pro metadata apod.
- Lze zobrazit např. pomocí dir /r
- Normálně (obyč. dir nebo explorer) vidět nejsou
- Umožňuje takhle nenápadně schovávat např. malware nebo jiná data (moderní toolky to ale prozkoumávají)
- USN Journal a $LogFile
- USN = Update Sequence Number
- Při vytvoření / smazání / změně souboru (složky) se udělají entries do \$UsnJrnl:\$J
- Featura pro rychlý recover
- $LogFile
- Pro obnovu konzistence metadat po sys failu
- Má INDX, MFT a LNK records

## MTD - Memory technology device
- FTL - Flash Translation Layer (řadič flash paměti)
- Stará se o flash paměť
- Eraseblock - data lze mazat jen po velkých blocích
- Wear levelling
- Detekce a správa špatných bloků
- Když flash paměť nemá FTL (řadič) - musí se o to postarat FS -> MTD
- MTD je abstrakční vrstva pro flash paměti
- Umožňuje práci
- **Nestará se o wear levelling ani o špatné bloky**
- Zpřístupňuje zařízení jako character nebo block devices
- /dev/mtdX
- /dev/mtdblockX -> ještě k tomu neefektivní zápis (mazání po blocích)
- Aby to zajišťovalo flash-aware funkce, je potřeba FS, který to řeší
- JFFS2, YAFFS, UBIFS
- Při použití klasických FS dochází k rychlému opotřebení a neefektivní práci

### JFFS
- Log structured FS
- Operuje přímo na flash pamětech
- Stará se o wear levelling
- **Enforcuje to - chová se k tomu jako k circular logu**
- Každá změna se zapisuje na konec logu v nodech

#### JFFSv1
- V logu jenom jeden typ node (jffs_raw_inode)
- Každý node asociovaný s jedním inode
- Header s inode num, sys metadata pro inode, může mít trochu dat
- **Každý node má verzi - zapisuje se vždy verze vyšší než mají ostatní nody pro tu samou inode**
- Inode nums - 32bit - nikdy se nerecyklují
- Každý zápis upravuje ten log
- Node 1 - zapiš data
- Node 2 - přidej data
- Node 3 - přepiš část dat ...
- Některé nody jsou zbytečné (dirty space) - byly přepsány
- Garbage collector - nechá jen ty reálně potřebné nody
- Smaže všechny a ty užitečné napíše na nové místo na konec - circular

#### JFFSv2
- Podporuje NAND flashky
- Hard links
- Komprese
- **Bloky** - velikost = erase segment flash média
- Něco málo si drží v RAM (jffs2_raw_node_ref)
- Bloky se postupně plní (jeden za druhým)
- Clean - má jen validní nody
- Dirty - má aspoň jeden obsolete node a bude potřebovat garbage collection
- Free - žádné nody

## FS Summary

### Klasické
- Linked FS
- Všechna data jako singly linked list (data + odkaz na další cluster)
- FAT
- Allocation table - linked list je v FAT, data zvlášť samostatně
- NTFS
- Všechny soubory a složky v MFT, odkaz na data jako seznam dvojic "start, len"
- Inode
- Data v inode (právě 1 pro každý soubor) a 12 direct pointerů a 3x indirect (single, double, triple)

### Mobile devices
- Block devices
- Ext2 - vše super, jen není úplně space efficient
- cramfs - malý FS (compressed rom fs), good pro embedded, **read onlyš**
- squashfs - Větší (pokročilejší), super komprese ale horší performance
- romfs - malý kernel module, nemá kompresi
- Flash
- JFFS2 - Ok, ale slabý výkon (hlavně mount + write time)
- YAFFS2 - NAND flashky, taky trošku lackuje výkon
- Memory
- initramfs - kompletní support na permissions a ownership, načítá se do ram při startu systému (není persistent)