Offene Punkte in LLFS

Hier einige Ideen, was es bei LLFS noch zu tun gibt.
- Anzeigen des freien Speichers ist ein Problem, nachdem ein Clone
  freigegeben wurde.  Das zu loesen, waere interessant.

- Ich bin mir nicht sicher, ob bei LLFS derzeit mit Barriers
  etc. wirklich dafuer gesorgt ist, dass die Datenkonsistenz
  gewaehrleistet ist.  Dafuer Tests zu entwickeln, das zu pruefen, und
  ggf. den Code zu verbessern waere eine Aufgabe.  Eventuell koennte
  man ein Testframework entwickeln (evtl. mit einem Simulator
  basierend auf einer virtuellen Maschine), das auf verschiedene
  Filesysteme angewandt werden kann.

  Einige Ideen dazu: Die virtuelle Maschine stellt eine virtuelle
  Platte zur Verfuegung, die fuer jeden Sektor mitfuehrt, ob er sicher
  geschrieben wurde, oder nur vielleicht.  Nach einem simulierten
  Stromausfall darf das Filesystem nicht von Sektoren lesen, die
  vielleicht geschrieben wurden.  Man muesste sich allerdings noch
  etwas fuer Dateisysteme ueberlegen, die mit Checksums arbeiten.

- Ich glaube, LLFS macht derzeit immer vollstaendige Checkpoints.  Man
  koennte die Performance beim Schreiben (insbesondere wenn's viele
  syncs mit kleinen Operationen dazwischen gibt) erhoehen, indem man
  zusaetzliche commit points einfuehrt (im Prinzip eine art ToDo-Log),
  und bei der Crash-Recovery vom letzten Checkpoint ein Roll-Forward
  zum juengsten geschriebenen commit point macht.

- Bessere Performance bei Log-Files (bzw. allgemein fragmentierten
  Files), indem man sie bei Gelegenheit sequentiell neu schreibt; die
  zusaetzlichen Commit-Points koennten da auch helfen, wenn man sie
  dazu verwendet, immer nur vollstaendige Bloecke an die Datei
  anzuhaengen, und davor einfach writes in den commit points
  speichert, bis ein Block zusammen ist; oder man speichert
  unvollstaendige Blocks einfach an einer anderen Stelle, die dann
  nicht im Weg ist, wenn der Block vollstaendig ist, und an den Rest
  der Datei angehaengt werden soll.

- Noch einmal zur Datensicherheit: Derzeit ist der aktuelle Checkpoint
  nur in einem Superblock gespeichert.  Sicherer waere es, wenn alle
  Superblocks Zeiger speichern wuerden und sie nie ueberschrieben
  werden muessten.  Dazu koennten sie Information ueber einige Extents
  enthalten, in denen Checkpoint-Bloecke gespeichert werden (uebrigens
  sollte man nicht davon ausgehen, dass Bloecke atomar geschrieben
  werden, sondern, wenn ueberhaupt, hoechstens Sektoren).  Die
  Checkpoint-Bloecke wuerden dann Timestamps enthalten, damit man
  weiss, welches der letzte ist, und eine Checksum, damit man weiss,
  ob er vielleicht kaputt ist.  Um der Moeglichkeit vorzubeugen, dass
  ein Checkpoint kaputt ist, sollten freigegebene Bloecke erst ab dem
  uebernaechsten Checkpoint wiederverwendet werden.

- Ein fsck, moeglichst einer, der online funktioniert.  Eventuell kann
  man der noch als Option defragmentieren.

- Eine bessere Art, Clones zu verwalten, sowohl kernel-intern (da
  gab's IIRC noch ein paar Probleme), als auch was die
  Systemadministration betrifft.

- Man koennte sich anschauen, ob die reference counting
  
  Vorteile gegenueber der aktuellen Freiblockverwaltung bringt, und
  wenn ja, ob es sich mit vertretbarem Aufwand in LLFS integrieren
  laesst.

- ZFS anschauen und eventuell interessante Features uebernehmen.

Anton Ertl