====== Lyx OS – IOFS: Island & Ocean File System ======
IOFS ist das native Dateisystem von Lyx OS. Es ersetzt FAT32 als primären Speicher und ist von Grund auf für drei Anforderungen gebaut: **Zero-Load-Ausführung** (LBF-Binaries laufen direkt aus dem Speicher, ohne Kopieren), **graphbasierte Abhängigkeitsverwaltung** (Pages sind Knoten, Abhängigkeiten sind typisierte Kanten) und **semantische Suche** (jede Page kann mit Embeddings annotiert werden).
→ [[lyxos:lbf|LBF-Binärformat]] · [[lyxos:syscalls|Syscall-ABI 0x0C00]] · [[lyxos:architektur|Architektur]] · [[lyxos:start|Übersicht]]
----
===== 1. Die Metapher: Ocean, Islands, Pages =====
┌──────────────────────────────────────────────────────────────┐
│ OCEAN (gesamtes Block-Device) │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ Island "system" │ │ Island "tools" │ ... │
│ │ │ │ │ │
│ │ Page 0x0001 │ │ Page 0x4A01 │ │
│ │ Page 0x0002 ────┼──┼─► Page 0x4A02 │ (Graph-Kante) │
│ │ ... │ │ ... │ │
│ └──────────────────┘ └──────────────────┘ │
└──────────────────────────────────────────────────────────────┘
^ Begriff ^ Bedeutung ^
| **Ocean** | Das gesamte Block-Device. Enthält alle Islands als logische Namensräume. |
| **Island** | Benannter Container für zusammengehörige Pages, z.B. ''system'', ''tools'', ''ai-models''. Entspricht grob einem Dateisystem-Volume oder einer Datenbank. |
| **Page** | Kleinste Adressierungseinheit: exakt **4096 Bytes**. Jede Page trägt einen 32-Byte-Header mit Typ, CRC32C-Prüfsumme und LPID. |
| **LPID** | *Logical Page ID* — eine 64-Bit-Kennung, die eine Page eindeutig im Ocean identifiziert. Entspricht dem logischen Block-Slot (LBA-Block). |
----
===== 2. Page-Aufbau =====
Jede IOFS-Page beginnt mit einem 32-Byte-Header:
Offset Größe Feld Beschreibung
────── ───── ───────────── ─────────────────────────────────────────────
0x0000 4 magic "LYX!" (0x4C 0x59 0x58 0x21) — gleich wie LBF
0x0004 1 page_type Typ der Page (siehe Tabelle unten)
0x0005 3 reserved Reserviert, muss 0 sein
0x0008 8 lpid Logical Page ID dieser Page
0x0010 4 crc32c CRC32C über Bytes 0x0020–0x0FFF (Nutzdaten)
0x0014 4 payload_len Größe der Nutzdaten in Bytes (max. 4064)
0x0018 8 prev_lpid LPID der Vorgänger-Page (für verkettete Cluster; 0 = keine)
0x0020 4064 payload Nutzdaten
==== Page-Typen ====
^ Typ ^ Konstante ^ Beschreibung ^
| 0x01 | ''IOFS_PAGE_FREE'' | Freie, noch nicht belegte Page |
| 0x02 | ''IOFS_PAGE_DATA'' | Allgemeine Nutzdaten (Datei-Inhalt, KV-Cache-Cluster, Embeddings) |
| 0x03 | ''IOFS_PAGE_META'' | Island-Metadaten, Verzeichnis-Einträge, Hash-Index-Segmente |
| 0x04 | ''IOFS_PAGE_EXEC'' | LBF-Genesis-Block eines ausführbaren Programms |
| 0x05 | ''IOFS_PAGE_GRAPH'' | Graph-Kanten-Cluster (kompakter Speicher für viele Kanten) |
| 0x06 | ''IOFS_PAGE_CONT'' | Continuation-Page (Fortsetzung eines zu langen TLV-Pools) |
| 0x07 | ''IOFS_PAGE_ISLAND'' | Island-Descriptor (Name, Flags, Root-LPID eines Islands) |
con IOFS_PAGE_FREE : uint8 := 0x01
con IOFS_PAGE_DATA : uint8 := 0x02
con IOFS_PAGE_META : uint8 := 0x03
con IOFS_PAGE_EXEC : uint8 := 0x04
con IOFS_PAGE_GRAPH : uint8 := 0x05
con IOFS_PAGE_CONT : uint8 := 0x06
con IOFS_PAGE_ISLAND : uint8 := 0x07
> **Unterscheidung IOFS-Page vs. LBF-Genesis:** Beide tragen ''LYX!'' an Byte 0. Die Unterscheidung erfolgt über Byte ''0x0004'': Wert ''0x01'' = LBF-Genesis (''format_version''); Werte ''0x02–0xFF'' = IOFS-Page-Typ.
----
===== 3. LIP-Adressierung: LPID → LBA =====
Die Kernleistung von IOFS ist die **O(1)-Übersetzung** eines LPIDs in eine physische LBA (Logical Block Address). Der Kernel hält eine kompakte In-Memory-Tabelle, die **LIP-Tabelle** (*Logical Island Page*):
lip_get(lpid) → lba O(1) — direkter Array-Zugriff
lba × 4096 → Byte-Offset auf dem Block-Device
Im Zero-Load-Modus (→ [[lyxos:lbf|LBF-Format, Abschnitt 6]]) trägt der Kernel diese LBAs direkt als physische Adressen in die CPU-Page-Tables (CR3) ein. Die CPU greift auf LBF-Code-Pages zu, als wären sie RAM — ohne eine einzige Kopie.
// Kernel-internes API (nicht als Syscall exponiert):
var lba: int64 := lip_get(block_lpid);
// pte.phys_addr = lba × 4096
// pte.flags = PROT_READ | PROT_EXEC (für .text-Pages)
----
===== 4. Graph-Kanten =====
Jede Page kann als Knoten im Kernel-Wissensgraphen (→ Syscalls 0x080F–0x0812) registriert werden. IOFS definiert zwei eingebaute Kanten-Typen für die LBF-Integration:
^ Kanten-Typ ^ Konstante ^ Bedeutung ^
| ''0xB001'' | ''IOFS_EDGE_LBF_CHAIN'' | Genesis-Block → Block 1 → Block 2 → ... (Code-Seiten-Kette) |
| ''0xD001'' | ''IOFS_EDGE_LBF_DEP'' | Genesis-Block → Dependency-Genesis (Bibliotheks-Abhängigkeit) |
con IOFS_EDGE_LBF_CHAIN : int64 := 0xB001
con IOFS_EDGE_LBF_DEP : int64 := 0xD001
Weitere Kanten-Typen werden von höheren Schichten vergeben (z.B. semantische Ähnlichkeit durch den AI-Subsystem-Layer in M7+). Die Kanten werden im Kernel-Wissensgraph (''sys_graph_*'') gespeichert — IOFS selbst speichert nur die rohen Page-Daten.
----
===== 5. Hash-Index =====
IOFS führt einen **Hash-Index** über alle Genesis-Pages (Typ ''0x04''). Schlüssel ist der SHA-256-Hash der Quelldateien (''source_sha256'' aus dem LBF-Genesis-Header), Wert ist der LPID der entsprechenden Page.
Anwendung: Der LBF-Loader löst ''DEP_HASH_GRAPH''-Einträge (TLV 0x02) ohne Verzeichnis-Traversierung auf — er berechnet den SHA-256 der Abhängigkeit und schlägt direkt im Hash-Index nach. Kein symbolisches Linking, keine Pfad-Suche.
import-Auflösung:
sha256(dep.source) → lip_index_lookup() → lpid → lba
kein ld.so, kein PATH-Scan, kein symbolisches Linking
----
===== 6. Omni-Ingest =====
Beim Import eines LBF-Binaries via ''lbf_import'' läuft der **Omni-Ingest**-Prozess:
- LBF-Blöcke werden als IOFS-Pages gespeichert (Typ ''0x04'' für Genesis, ''0x02'' für Code-/Daten-Pages)
- Der ''HUMAN_INTENT''-Text (TLV 0x01 aus dem Genesis-Block) wird durch das KI-Subsystem in einen Embedding-Vektor umgewandelt
- Der Embedding-Vektor wird an die Genesis-Page annotiert (''sys_sem_annotate'')
- Die Page wird im Kernel-Wissensgraph registriert (''sys_graph_node_create'')
- Graph-Kanten werden zwischen den LBF-Blöcken gewoben
Nach dem Ingest ist das Programm über ''sys_ai_search'' (semantische Ähnlichkeit) und ''sys_timeline_query'' (zeitbasiert) auffindbar — ohne dass der User den genauen Dateinamen kennen muss.
lbf_import main.lbf --into-island="tools"
→ IOFS-Pages anlegen
→ Omni-Ingest: Embedding + Graph-Registrierung
→ Hash-Index aktualisieren
----
===== 7. Panic-Sandbox =====
Die **Panic-Sandbox** ist ein IOFS-Modus für die Vertrauenskette des LBF-Loaders (→ [[lyxos:lbf|LBF-Format, Abschnitt 5]]).
* ''sys_iofs_sandbox_enter'' (''CAP_ADMIN'' erforderlich) aktiviert den Modus: IOFS verweigert alle Schreiboperationen außer dem Aktualisieren der Compiler-Blacklist
* In diesem Modus können kompromittierte Compiler-UUIDs sicher zur Blacklist hinzugefügt werden, ohne dass ein laufender Angriff die Liste manipulieren kann
* ''sys_iofs_sandbox_exit'' verlässt den Modus
Beim LBF-Import prüft der Kernel automatisch: Ist die ''compiler_instance_sn'' (UUID aus dem Genesis-Block) in der Blacklist? Falls ja, wird der Import abgelehnt — Schicht 3 der [[lyxos:lbf|5-Schichten-Vertrauenskette]].
----
===== 8. Kompaktierung =====
IOFS ist ein **Append-Only**-System: gelöschte oder veraltete Pages werden nicht sofort überschrieben, sondern als ''IOFS_PAGE_FREE'' markiert. Ein periodischer oder manueller Kompaktierungszyklus defragmentiert das Volume:
var mount_fd: int64 := ...;
// region_hint = 0: gesamtes Volume kompaktieren
var freed_pages: int64 := 0;
var err: int64 := 0;
// (err, freed_pages) := syscall(SYS_IOFS_COMPACT, mount_fd, 0);
''sys_iofs_compact'' (0x0C01) gibt die Anzahl der zurückgewonnenen Pages zurück. Der Kernel kann diesen Zyklus auch automatisch im Hintergrund auslösen (konfigurierbar über ''IofsOpts'' beim Mount).
----
===== 9. Syscall-Schnittstelle (0x0C00–0x0C04) =====
Die Low-Level-IOFS-Syscalls sind für Systemtools und den Kernel selbst. Normale Anwendungen gehen über das [[lyxos:syscalls#vfs|VFS-Interface (0x0200–0x0215)]].
^ Nr ^ Name ^ Argumente ^ Rückgabe (rdx) ^ Beschreibung ^
| 0x0C00 | ''sys_iofs_mount'' | ''dev_fd, IofsOpts*'' | mount_fd | Raw-Block-Device als IOFS einbinden |
| 0x0C01 | ''sys_iofs_compact'' | ''mount_fd, region_hint'' | Pages | Kompaktierungszyklus auslösen; 0 = ganzes Volume |
| 0x0C02 | ''sys_iofs_page_info'' | ''mount_fd, lpid, IofsPageInfo*'' | — | Page-Header und Metadaten lesen |
| 0x0C03 | ''sys_iofs_sandbox_enter'' | ''mount_fd'' | — | Panic-Sandbox aktivieren (''CAP_ADMIN'' erforderlich) |
| 0x0C04 | ''sys_iofs_sandbox_exit'' | — | — | Panic-Sandbox verlassen |
----
===== 10. Verhältnis zu VFS und FAT32 =====
Ring-3-Anwendungen
│
▼ sys_open / sys_read / sys_write (0x0200)
┌─────────────┐
│ VFS │ Abstraktionsschicht — kennt kein Dateisystem direkt
└──────┬──────┘
│
┌────┴────┐
│ │
▼ ▼
FAT32 IOFS ← beide als VFS-Backends mountbar
(M1–M4) (M5+)
FAT32 bleibt für den UEFI-Boot (''BOOTX64.EFI'' und ''kernel.elf'' auf der EFI-Partition) und als Kompatibilitätsmodus erhalten. Ab M5 ist IOFS das primäre Volume für alle Anwendungen und KI-Modelle. Das VFS-Interface (''sys_open''/''sys_read'' usw.) bleibt unverändert — der Wechsel ist für Ring-3-Code transparent.
----
===== 11. Aktuelle Einschränkungen =====
IOFS ist ab M5 geplant. In M1–M4 gilt:
* Das Kernel-Dateisystem ist ausschließlich FAT32 (via ''fat32.lyx'' und ''vfs.lyx'')
* ''sys_iofs_*''-Syscalls (0x0C00–0x0C04) geben in M1–M4 ''ERR_NOSYS'' zurück
* Die LBF-Zero-Load-Ausführung ist ab M5 mit dem IOFS-Treiber verfügbar; bis dahin lädt ''ring3.lyx'' LBF-Binaries sequentiell via FAT32/VFS
Letzte Aktualisierung: 2026-06-10