Grub Modul=Linux Modul?

[Der Kaiser!]

Die Möglichkeit besteht. :D

___

Die ganz grossen Wahrheiten sind EINFACH!

Wirkung und Gegenwirkung.
Variation und Selektion.
Wie im grossen, so im kleinen.

[Exception]

Ich nehme mal, ausgehend von den Kommentaren die ich hier sonst so lese, an, dass diese Aussage ernst gemeint ist.

Normalerweise verkneif ich mir Kommentare auf zahlreiche Einzeiler, welche ich für total unnötig und nichtssagend halte.

Durch zahlreiche Einflüsse, welche ich wahrscheinlich nur durch Überbeschallung meines Trommelfells erklären könnte, bin ich heute Motiviert konstruktiven Beitrag zu leisten.


Wie schon, mit etwas Fantasie, im <sarcasm>hoch Wissenschaftlichen</sarcasm> Beitrag auf Golem zu lesen war, ist ein Grub-Modul != einem Kernel-Modul.

Dies ist auch logisch, geht man davon aus, dass der Grub zuerst die Festplatten auslesen muss, bevor der eigentliche Linux-Kernel geladen wird.

Im großen und Ganzen wird es Möglichkeiten geben das Modul zu portieren, jedoch benötigt Grub lediglich schreibenden Zugriff. Dies bedeutet, dass es trotz des Portierens noch eine Menge Arbeit wäre.

Abgesehen davon unterliegt ZFS zurzeit der CDDL, welche inkompatibel zur vom Linux-Kernel verwendeten Lizenz (GPL) ist.


try{
Hoffe, dass ich helfen konnte!
}catch(Exception e){}

[PG]

Die Idee wäre wohl gerade, mit dem GRUB-Modul anzufangen, weil es GPL2+ ist. Aber wie geschrieben, ist dessen Funktionsumfang eingeschränkt (kein Schreibzugriff, evtl. kein RAID-Z)

Was mit ZFS-Support in GRUB geht, ist nen Linuxkernel mit InitRD zu laden, in dem sich FUSE mit ZFS-FUSE befindet. Damit könnte man dann auch das rootfs von ZFS laufen lassen, ohne Ärger mit der Lizenz zu bekommen.

Wobei FUSE es noch etwas schwieriger macht, das Speichermodell, dem ZFS unterliegt, effizient zu implementieren.

[0o9i8u7z]

PG schrieb:
--------------------------------------------------------------------------------
> Wobei FUSE es noch etwas schwieriger macht, das Speichermodell, dem ZFS
> unterliegt, effizient zu implementieren.

Ich gestehe, selbst nichts über das Programm-Interna von FUSE zu wissen, aber viele Entwickler die ich kenne, schimpfen über die Performance von FUSE und bezweifeln, dass damit überhaupt ein effizientes (im Sinne von Performance) Dateisystem programmiert werden könne...

[HyperLINK]

0o9i8u7z schrieb:
--------------------------------------------------------------------------------
> Ich gestehe, selbst nichts über das Programm-Interna von FUSE zu wissen,
> aber viele Entwickler die ich kenne, schimpfen über die Performance von
> FUSE und bezweifeln, dass damit überhaupt ein effizientes (im Sinne von
> Performance) Dateisystem programmiert werden könne...

Definiere Performance. Wenn ich mit ntfs 70MB/s kriege auf einer Platte die mit Original Windows(tm) knapp 90MB/s schaft, ist das IMHO ok. Es ist sicher richtig, das ein FUSE nie die Performance eines native im Kernel implementierten FS erreichen wird, aber wer das will hat das problem nicht verstanden.

[PG]

0o9i8u7z schrieb:
--------------------------------------------------------------------------------
> Ich gestehe, selbst nichts über das Programm-Interna von FUSE zu wissen,
> aber viele Entwickler die ich kenne, schimpfen über die Performance von
> FUSE und bezweifeln, dass damit überhaupt ein effizientes (im Sinne von
> Performance) Dateisystem programmiert werden könne...

Es wird immer etwas weniger effizient sein. Allein, weil für die meisten Zugriffe auf das Dateisystem via FUSE 4 zusätzliche Wechsel zwischen Kernel und Userspace fällig werden (Kernel -> FUSE, um die Anfrage an das Dateisystem weiterzureichen, FUSE -> Kernel, wenn FUSE auf den Datenträger zugreifen muss).

Wenn es richtig gemacht wird, gibt das zwar einen kleinen Nachteil, dafür gibt es aber auch einige Vorteile: Separater Prozess, dh. Fehler reißen nicht gleich das OS mit sich; Userspace-Prozesse sind auch etwas angenehmer zu entwickeln (weniger Ärger mit Speicherverwaltung, mehr Flexibilität in der Wahl der Programmierumgebung - was bei ZFS nicht notwendig ist, weils ja schon existiert).

Minix3 propagiert den Ansatz konsequent (alle Treiber und Dateisysteme in eigenen Userspace-Prozessen, außer dem Treiber für den Taktgeber), und man nimmt dort auch 10-20% Geschwindigkeitseinbuße in Kauf, wenn man dafür mehr Sicherheit und Stabilität bieten kann.
Ist halt eine Designentscheidung, wieviel Tempo man für andere Merkmale aufgibt.

Einige Linuxentwickler sehen das evtl. als Angriff auf die "reine Lehre" monolithischer Kernel (da gabs mal die legendäre Auseinandersetzung zwischen Torvalds und Tanenbaum über monolithische vs. microkernel), und FUSE könnte als Schritt richtung microkernel betrachtet werden.
Mit Performance hat das wohl eher weniger zu tun: XFS ist seit ca. 10 Jahren im Kernel und bekommt immer noch Performanceoptimierungen. Wenn bei FUSE die Performance eine Rolle spielen würde, hätte XFS nicht vor 10 Jahren aufgenommen werden dürfen. ;-)

[AC]

Also, ZFS auf Linux (native) ist langsamer als btrfs:

> http://linux.slashdot.org/story/10/11/22/1433246/slashdot.sourceforge.net

Also, ZFS ist schon eine feine Sache, aber btrfs wird richtig rocken (sobald die ZFS-Features implementiert wurden).

LG,
Anonymous Coward

[Der Kaiser!]

>> Ich gestehe, selbst nichts über das Programm-Interna von FUSE zu wissen, aber viele Entwickler die ich kenne, schimpfen über die Performance von FUSE und bezweifeln, dass damit überhaupt ein effizientes (im Sinne von Performance) Dateisystem programmiert werden könne...

> Definiere Performance. Wenn ich mit ntfs 70MB/s kriege auf einer Platte die mit Original Windows(tm) knapp 90MB/s schaft, ist das IMHO ok.

> Es ist sicher richtig, das ein FUSE nie die Performance eines native im Kernel implementierten FS erreichen wird, aber wer das will hat das problem nicht verstanden.
Die Auslastung der CPU ist grauenhaft..

___

Die ganz grossen Wahrheiten sind EINFACH!

Wirkung und Gegenwirkung.
Variation und Selektion.
Wie im grossen, so im kleinen.