Optional sollten FS immer Fuse anbieten

[Siga49427]

Da man nicht weiss, wann ein FS in den Kernel kommt, und es blöd ist, wenn speziell Netzwerk-FS oder neue FS für z.b. SSDs oder SD-Karten/USB-Sticks nur auf einem OS laufen und nicht auf allen OS (BSD, Linux, Solaris, M$, Symbian, PSP, PS3,...), wäre es schon nett, wenn alle FS auch immer als Fuse verfügbar sind.

Dann spart man sich das ständige Geheule wegen ZFS und unter welchem OS es diese Woche mal läuft. Das war leicht böse formuliert, aber WIESO muss es 5 verschiedene Implementierungen NUR wegen der Lizenz geben ? Eine Implementierung nur für FUSE würde mir und den meisten anderen auch reichen.

Und MetaFS aufgrund abstrakter Beschreibungen hatte ich ja schon mal beschrieben. Damit könnte man zumindest alle FS auslesen und das reicht ja oft.

[Zustimmung]

Grundsätzlich plädiere ich auch für einen schlanken Kernel, muss allerdings gestehen, dass ich mir bisher keine Benchmarks zwischen einem FUSE und im Kernel integriertem FS gleicher Versionsnummer angeschaut habe. Letztlich wird man sich damit auseinandersetzen müssen, ggf. einen eigenen Kernel zu kompilieren, was eigentlich heutzutage ja eh kein Problem mehr ist.

[Siga43297424]

Die FS dürfen und sollen ruhig AUCH als Kernel-Module "Multiheaded" verfügbar sein.

D.h. es gibt EINEN Anbieter für fooFS und der bietet EIN tar_File (für Windows halt zip) mit den Sourcen an und das kann als kernel-modul (.ko-Kernel-Module sind ja auch schon eine Abstraktion wie FUSE. Beim booten müsste vmlinuz halt "dahinter" die .ko-Module "hängen" haben, um die benötigten FS gleich laden zu können. Natürlich könnte man die FS rausnehmen und andere hinten dran hängen wenn man von woanders booten will. Oder sie lauern schon wie bei OS9 im RAM weil Grub/syslinux sie dort reingeladen hat. Das überschreitet aber die kleinen Gehirne kleiner Programmierer massiv) übersetzen oder gleich in den Kernel rein (halt kein .ko-File) oder halt als FUSE kompilieren.

Derselbe Code geht für BSD, Solaris, WinDos, FreeDOS (war ernst gemeint!), usw. in deren Kernels. Abstraktion nennt man das was viele nicht verstehen. Das sind dann dieselben die C++/C## und PHP hypen und simpelste Pattern ihres Hypes nicht woanders erkennen. Mindere AssoziationsFähigkeiten nennt man das wohl.

Wenn Debian aufgrund von Glaubens-Problemen ("wuae, ich kann keine BSD-Module kompilieren") auf fooFS im offiziellen von Stallmann gesegneten Distributions-Kernel verzichtet, und "böse" "autonome APT-Verzeichnisse" die ".ko"-Module anbieten oder man sie sich einfach selber kompiliert, dann ist ja kein Problem.

Mehrfach Code schreiben NUR wegen Lizenzen ist doof.

Wer Sarkasmus findet, kann ihn behalten.

[fdsafdsafdsa]

Siga49427 schrieb:
--------------------------------------------------------------------------------
> Dann spart man sich das ständige Geheule wegen ZFS und unter welchem OS es
> diese Woche mal läuft. Das war leicht böse formuliert, aber WIESO muss es 5
> verschiedene Implementierungen NUR wegen der Lizenz geben ? Eine

Du kannst Lizensprobleme nicht technisch loesen.

> Implementierung nur für FUSE würde mir und den meisten anderen auch
> reichen.

Noe. Fuse ist eine kruecke, nicht mehr. linux-zfs-fuse 40MB/s, zfs-opensolaris >300MB/s, auf der gleichen Hardware... Du bist nicht "den meisten".

[darkfader]

jo,


schon ein wenig her, aber der performanceimpact von FUSE ist zu hoch fuer einige(?) anwendungsfaelle. z.b. mit glusterFS hab ich das ebenso erlebt - ein file auf dem lokalen node wurde mit 80MB/s anstatt 120MB/s gelesen. Das sind mal eben 30% - also in etwa so, als ob ich die aktuelle Platte aus- und eine 4 Jahre alte ein-bauen wuerde.

ich hatte das auch schon hier beschrieben:
http://deranfangvomende.wordpress.com/2010/02/14/glusterfs-issues/

usermode-treiber und FUSE sind interessante technologien, aber an vielen stellen sind die performanceverluste einfach viel zu extrem.

meistens scheint es mir halt auch immer genau die anwendungsfaelle zu erwischen, welche richtig viel tempo brauchen, mit der begruedung, dass es garnicht so schlimm sei.

z.b. infiniband unter linux, da gab es so ein statement von einem maintainer, dass 10-20% verlust schon noch tolerabel seien.

wenn mein PC daheim 10% langsamer waere, wuerde ich vermutlich auch noch nichtmal extra ins bios gehen. Aber wenn bei Infiniband dann statt 34 nur 27Gbit/s durchgehen sollen, finde ich das ein wenig krass - der Herr meinte, dass ein GIGABYTE pro sekunde vernachlaessigbar sei.

Und so kommt das bei FUSE m.M. nach auch - die Performanceverluste sind im DesktopPC des Entwicklers vernaechlaessigbar. Auf ein Rechenzentrum skaliert, stehen dann wegen dem vernachlaessigbaren Problem dann u.U. 200 Srever mehr da und heizen die Gegend auf.

[optio nal]

Da steht ja "OPTIONAL". D.h. 99% hat man als FUSE und was man wirklich öfter braucht, als Kernel-Module (natürlich LLVM+++-Optimierbar!) bzw gleich im Kernel.

Für Kernel-FUSE gibts in 2.34 (?) laut ct-KernelLog von gestern/morgen auch Optimierungen.
Oder für ich glaube btrfs gibts nun auch einen direct-mode um die caches/buffer zu umgehen, wenn man z.b. auf Datenbank-Files zugreift, die sowas selber regelt. Wenn ich es richtig erinnere.

TopDown/MetaMäßig das FS beschreiben für MetaFUSE. Wo es beliebt/gebraucht ist, kann man dann konkretere Implementierungen bzw. Teil-Implementierungen für die Performance-Hungrigen Teile nachlegen.
D.h. MetaFUSE, User-FUSE, Kernel-FUSE, Kernel-MODULE, KernelTeil wären interessante "evolutionsstufen".
Die anderen OS profitieren dann hoffentlich möglicherweise auch von effizienteren Implementierungen. Aber man muss nicht mehr "endlos" warten, bis man ein FS überhaupt mal nutzen kann.

Und ext3 unter VDR pausiert den laufenden Betrieb und dann habe ich Lücken in den aufnahmen. Wann ? Wenn man ein paar Gigabyte löscht, was bei VDR-Aufnahmen ja normal ist.
Mit xfs passiert das nicht. Also ext3 ist auch nicht so der Heilsbringer. Zumindest früher nicht.
Du hast Server als Beispiel gebracht. Das hier (VDR) war halt eine near-"Realtime" für im Wohnzimmer.

Die FOSSler halten sich für besser. Aber sind es oft halt leider nicht und machen leere Versprechungen.