Gerede über Dateisysteme

fusefs-exfat gab und gibt es nicht per pkg zu installieren. Das was bei freshports steht, stimmt nicht.
Was hat den FreshPorts damit zu tun ob es das als "binary package" zu installieren gibt?
Die beziehen sich prinzipiell erst mal auf die ports und nebenbei erwähnt, findest du dort folgende Info:
To install the port: cd /usr/ports/sysutils/fusefs-exfat/ && make install clean
A package is not available for ports marked as: Forbidden / Broken / Ignore / Restricted
PKGNAME: there is no package for this port: _LICENSE_RESTRICTED = delete-package delete-distfiles



Was mich an NTFS stört, ist das es nicht "case senstive" ist, ansonsten hatte ich seit einer Ewigkeit keine Probleme damit (im Gegensatz zu UFS/ext*)
 
Ich wollte mit meinem Startbeitrag gar nicht so sehr auf NTFS hinaus. Dateisysteme sind Schall und Rauch, letztendlich nur ein definiertes Format der Daten auf der Platte. Wie gut oder schlecht sich ein Dateisystem in der Praxis verhält, hängt in erster Linie von seiner Implementierung, von Cache-Strategien und so weiter ab. Steckt man genügend Hirnschmalz hinein, bekommt man auch Krüppel wie FAT schnell... Mir ging es stattdessen darum, dass das ganze I/O-Subsystem, also auch die Ebenen über und unter dem Dateisystem auf Windows eine mittelgroße Katastrophe sind. Diesen ganzen Weg zu multithreaded und non-blocking I/O, den z.B. FreeBSD und Linux in den letzten 10 Jahren gegangen sind, scheint Microsoft nie ernsthaft betreten zu haben. Das führt dann zu Dingen wie z.B. I/O auf einem Mountpoint oder in Windows-Sprache Laufwerk blockiert I/O auf einem anderen Mountpoint. Oder auch führt ein Thread eine Operation aus, blockieren alle anderen Threads. Das nervt beim täglichen (mich) einfach massiv.

Kamikazes use-Case, das Compilen von Code, ist ein gutes, praktisches Beispiel dafür. Weil das Buildsystem selbst und mehrere Compiler parallel auf dem Dateisystem arbeiten, blockieren sie sich gegenseitig und sehr, sehr viel CPU-Zeit verpufft durch das Warten auf das I/O oder den I/O-Overhead. In der Folge sind Compilezeiten von dem fünf- bis im Extremfall sogar zehnfachen ggü. FreeBSD oder Linux nichts Ungewöhnliches. Und während die Compiler laufen, ist das Restsystem nahezu unbenutzbar, bis hin zu hängender Maus.

Warum Microsoft daran nie etwas grundlegend geändert hat, wo sie doch in Windows 10 seit 2015 durchaus große Fortschritte in Sachen Performance und Skalierung gemacht haben, kann man nur spekulieren. Mein Tipp wäre, dass einfach viel zu viele Anwendungen annehmen, dass I/O-Request immer schön in Reihe, nur ein Request zur Zeit, bearbeitet werden. Und jede Änderung daran würde sehr viele obskure, teilweise bis hin zu Datenverlust führende Probleme nach sich ziehen.
 
Exfat ist unter OpenBSD in den packages und kann leicht über pkg_add exfat-fuse installiert werden :) - ich besitze aber keine Geräte die das verwenden.

Leicht off-topic, aber für mich sehr viel praktischer ist das es auch dieses "mtp" pseudo-dateisystem über fuse unter OpenBSD gibt (Paket simple-mtpfs), dadurch kann ich sehr viel einfacher Daten per USB von meinem Smartphone kopieren, das ist zwar in zeiten von cloud & co nicht mehr sooooo oft nötig aber manchmal schon praktisch.
Scheint bei mir auch problemlos zu funktionieren.
 
Ich habe das bei mir geändert und keinen Unterschied bemerkt.
So endlos ist der Bootvorgang zumindest bei Verwendung von SSD nicht.
Dabei ist es aber gar nicht einfach, die Bootzeit tatsächlich zu erfassen, also auch zu messen. Denn ich muss mich immer einloggen und dazu wird immer ein gewisser Bildschirm erst geladen (das ist mir von meiner Firma so gegeben und nicht zu ändern). Das dauert eine gewisse Zeit, so oder so.
Aber dann geschieht beim Windows auch noch jede Menge nach dem Einloggen und ich habe gelernt, dass ich das System erst mal einige Minuten in Ruhe lasse, bevor ich damit arbeite. Erst dann funktioniert alles ziemlich gut, auch unter Windows.
.
Ja das stimmt. Wobei es bei Windows recht angenehm ist. Natürlich muss im Hintergrund noch einiges abgearbeitet werden, aber wenn ich mein besagtes Notebook zum Beispiel einschalte habe ich nach 3 Sekunden den Login da und kann arbeiten. Oft schaltet man ja den Rechner ein macht sich dann noch eine Tasse Tee oder so und dann ist alles fertig. Windows bereitet sich ja schon vor während es auf den Login wartet. Bei anderen Systemen (Linux/BSD) passiert ja erst einmal nichts. Es wäre schön wenn das System schon mal den Desktop und Bibliotheken lädt und nicht erst damit beginnt wenn ich mich angemeldet habe. Ja klar da theoretisch alles Manager gleichzeitig installiert sein können ist das etwas komplexer wenn der eine Nutzer KDE, Gnome und der nächste Xfce nutzt. Aber bei einem normalen Desktop zuhause wäre es nett wenn KDE öde Gnome schon im Hintergrund anfangensich bereit zu machen anstatt erst anzufangen wenn ich mich angemeldet habe. Wobei du hast recht was ist der Bootvorgang eigentlich. Im Prinzip wenn der Bootloader der Reihe ist könnte man ja sagen das System hat gebootet. Der Rest ist ja normales ausführen von beliebiger Software.
 
Bei anderen Systemen (Linux/BSD) passiert ja erst einmal nichts.
Ubuntu hat da sehr viel dran gedreht.
Wie es aktuell dort aussieht, kann ich nicht sagen. Meine letzten Erfahrungen liegen noch bei Zeiten, wo systemd gerade Einzug hielt. Davor hatte Ubuntu ein eigenes "Boot-Beschleuniger"-Konzept und parallelisierte viele Prozesse. Ich glaube, das nannte sich StartUp oder sowas. Jedenfalls hatte ich und mit einem Ubuntu aus einem minimal-System (also ohne deren übliche zusätzliche Überwachungs- und Automatisierungsmechanismen) das bisher absolut schnellste Booterlebnis auf einem Freien System und es lässt sogar einen Mac ziemlich alt aussehen.
Dabei muss man ja schon wieder genauer sagen, was die Bootzeit sein soll.
Alleine die Suchen vom BIOS können ja je nach Rechner schon mal etliche Sekunden dauern. Dann der Bootmanager, der vielleicht eine Zeit zur Auswahl verstreichen lässt (den man in einem Windows gar nicht benutzt). Das alles ist sehr schwierig zu erfassen und weg zu rechnen.
Und bei Ubuntu typisch war damals, dass sehr schnell der login-Screen gezeigt wurde, dass aber dabei noch gar nicht alles abgearbeitet war, was wirklich gebraucht wurde. Also könnte man das auch als Augenwischerei beschreiben, aber es entspricht ziemlich genau deinem Wunsch.
Einen großen Einfluss auf die Bootzeit kann das Einrichten der Netzwerk-Karte haben. Das Beziehen einer Adresse vom DHCP-Server kann deshalb durchaus auffällig sein. Nur: bei Ubuntu wird das in den Nutzer-Account verlegt. Erst nach dem Anmelden eines Nutzers baut sich das Netzwerk auf und man kann darüber streiten, was nun welche Vor- oder Nachteile hat.
Ich finde es eben ziemlich wichtig, diese Dinge nicht zu übersehen, wenn man vom langsamen Booten eines FreeBSD nach dem alten init redet.
Rechne ich all die nicht system-typischen Dinge weg, dann braucht mein FreeBSD-Laptop (den ich häufiger boote, während mein PC normalerweise gebootet bleibt), vielleicht 20 Sekunden bis zum Login-Screen. Selbst, wenn ich lange auf eine IP-Adresse warten muss, ist der Bootvorgang nie länger als eine Minute insgesamt. Das ist also in etwa: Einschalten kurz umsehen, Stuhl zurechtrücken, Ärmel hoch krempeln, Barthaare glatt streichen, einloggen. Und einatmen und Arbeiten. Denn länger dauert es nicht, bis meine Arbeitsumgebung aufgebaut ist und steht.
Weshalb ich das so explizit erwähne?
Eben wegen der Gedanken, dass sich doch schon mal KDE oder so was halbwegs auf den Einsatz vorbereiten könnte. Das wäre nämlich in meinem Fall vergebene Liebesmüh. Die Arbeitsumgebung steht quasi adhoc bereit, sofort nach dem Einloggen.
 
Wobei wenn man uns so Schreiben sieht, dann könnte man meinen das wir unser halbes Leben mit Bootvorgängen verbringen ;) Was leider oft vergessen wird ist das ein Bootvorgang transparent sein sollte. Wenn irgendwas schief geht, dann sollte man sofort ohne viele Probleme einen Hinweis bekommen. BSD ist da recht angenehm und zeigt ja viel Text beim starten, Windows zeigt in der Regel wenn was schief geht einen Fehlercode. Bei Linux ist es leider inzwischen oft so das Default einfach der Bildschirm schwarz bleibt und man ohne viel Aufwand keinen Ansatz hat. Ich glaube man muss einen Kompromiss finden zwischen schnellen starten und sauberen nachvollziehbaren starten.
 
Jetzt mal ne schwierigere Frage:

Welches ist (mit) das zuverlässigste Dateisystem?

Hintergrund: will mir ne USB Platte als zusätzliches Backupmedium anschaffen und frage mich, mit was ich sie am besten formatiere. ZFS?

Zugriff soll vorzugsweise über Linux oder Mac erfolgen.
 
Aus eigener Erfahrung - beruflich wie privat - empfehle ich ZFS, das hilft auf alle Fälle z.B. auch gegen bit-rot (einzelne bits kippen im Laufe der Zeit).
Zugriff per NFS oder CIFS, da sehen die Clients das darunterliegende ZFS gar nicht.
BTRFS hatte ich persönlich noch nie eingesetzt, das soll aber ähnlich komfortabel sein und gegen bit-rot gefeit sein.

Externe USB Platten zum Backup kann man auch gut mit ext4 oder xfs formatieren, da fiel mir selber auch noch nie ein Filesystem aus (nur die Hardware selber)
 
Aber bei einem normalen Desktop zuhause wäre es nett wenn KDE öde Gnome schon im Hintergrund anfangen sich bereit zu machen anstatt erst anzufangen wenn ich mich angemeldet habe.

Wie lange dauert es bei dir, dass es dir so negativ auffällt? Laut Logs braucht bei mir GDM zu Gnome-Desktop weniger als 3 Sekunden; ohne GDM sind es unter 5 Sekunden.

Wobei wenn man uns so Schreiben sieht, dann könnte man meinen das wir unser halbes Leben mit Bootvorgängen verbringen ;)

Ich verstehe die Diskussion um die Boot-Zeiten auch nicht. Von Bootloader bis GDM vergehen bei mir ~15 Sekunden (mit deaktiviertem Auswahlmenü ~10 Sekunden), davon nimmt das Warten auf DHCP noch den größten Brocken ein.

Bei Linux ist es leider inzwischen oft so das Default einfach der Bildschirm schwarz bleibt und man ohne viel Aufwand keinen Ansatz hat.

Ich bin auch kein Freund von stillen Bootvorgängen oder gar den Splash Screens vieler Distros, aber quiet splash ist schnell aus der Bootloader-Config entfernt. :)

Ich glaube man muss einen Kompromiss finden zwischen schnellen starten und sauberen nachvollziehbaren starten.

Ich glaube nicht, dass das ein Widerspruch ist. Solange das Init-System eine Vorstellung von Abhängigkeiten der Dienste hat, lassen sich im Zeitalter von SSDs und Multicore-CPUs Dienste problemlos parallel, sauber und nachvollziehbar starten - das ist aber kein Thema für diesen Thread.

BTRFS hatte ich persönlich noch nie eingesetzt, das soll aber ähnlich komfortabel sein und gegen bit-rot gefeit sein.

Korrekt.

Externe USB Platten zum Backup kann man auch gut mit ext4 oder xfs formatieren, da fiel mir selber auch noch nie ein Filesystem aus (nur die Hardware selber)

Der Vorteil von btrfs und zfs für Backups ist auch die Möglichkeit zur transparenten Kompression, die ext4 und xfs nicht haben. Die Kombination von rsnapshot für versionierte Backups samt btrfs oder zfs zur automatischen Kompression ist extrem angenehm, insbesondere mit zstd.
 
Welches ist (mit) das zuverlässigste Dateisystem?
Hintergrund: will mir ne USB Platte als zusätzliches Backupmedium anschaffen und frage mich, mit was ich sie am besten formatiere. ZFS?
Ich denke, dass die Frage schon beantwortet wurde und möchte nur meine Erfahrungen teilen. Bei mir läuft ein NAS mit ZFS und Redundanz von zwei Platten. Erst seit letzten Jahr, davor über fast ein Jahrzehnt mit ZFS und einer Platte Redundanz. Das will ich hier nicht diskutieren: eine Platte Redundanz ist mist und das sollte man nicht ernsthaft in Erwägung ziehen! ABER: über fast ein Jahrzehnt habe ich damit all meine Daten konsistent erhalten.
Während dieser Zeit habe ich unterschiedliche externe USB-Platten als Backup für die Daten auf dem NAS benutzt und insgesamt damit mehr Probleme gehabt, als mit dem NAS selbst. Diese Probleme erstreckten sich auf HW-Fehler und zerstörte Dateisysteme. HW-Fehler sowohl die Platte, als der Controller.
Als Lehre daraus leite ich ab, dass ein wirklich zuverlässiger und problemloser Backup auf einen zweiten NAS mit ZFS erfolgen sollte.
Kann ich mir nicht leisten, klar, kann man nicht machen, sollte man sich aber doch klar machen. Externe Medien sind immer eine Notlösung und niemals wirklich verlässlich. Man braucht da quasi immer auch Faktor zwei, wenn man ernsthaft damit arbeiten will. Dabei sind viele Daten nun nicht so wichtig und da genügt es dann vielleicht, nur eine Kopie (zusätzlich zum funktionierenden NAS) zu pflegen.

Ich entwickele aber mal das Szenario: NAS stirbt und geht in Flammen auf. Alle Platten auf einen Schlag hinüber. Alle Daten weg. Nun greift man zu seiner externen Platte mit dem Backup und oh Schreck! Dateisystem kaputt. Meinetwegen ein EXT4 oder NTFS, was ja grenzenlos beliebt ist. So ein Dateisystem kann ja schon mal deshalb kaputt sein, weil man vergessen hatte, das Medium korrekt auszuwerfen. Dann kann es allermeist vollkommen problemlos repariert werden, aber werden nun ausgerechnet mehrere Defekte gefunden und in der Konsequenz einige Dateien gelöscht, die unbrauchbar geworden waren. Natürlich genau die Dateien, die man nun unbedingt beim Finanzamt vorlegen muss!
Zugegeben, alleine durch Wort "Finanzamt" wird das zu einem Horror-Szenario, aber das will ich ja auch bezwecken.
Allermeist können Dateisysteme problemlos wiederhergestellt werden. Aber können wir das wirklich mit FreeBSD? Ein NTFS zuverlässig reparieren, oder ein EXT4? Meine Erfahrungen damit sind durchwegs schlecht und mann sollte so etwas probieren, wenn man sich für ein Dateisystem entscheidet. Meiner Meinung nach sollte man nur solche Dateisysteme zur Sicherung von Daten verwenden, für deren Reparatur man die zugehörigen Betriebssysteme auch einsetzen kann. Also NTFS nur, wenn einem auch Windows zur Verfügung steht und EXT4 nur, wenn man auch Linux hat.

Wenn also mit Linux und Mac auf solch ein Medium zugegriffen werden soll, frage ich mich, wo hier der gemeinsame Nenner ist. Soviel ich sehe, gibt es keinen. Außer: ZFS.
Oder?
Nun ist ZFS absolut besonders und kein eigentliches Dateisystem.
Ich weiß nicht, wie momentan die Unterstützung für OS-X aussieht, aber bei Linux soll das gut laufen ("unser ZFS kommt ja von dort"). Ich habe derzeit nur zwei externe Platten mit ZFS als Backup-Medien im Gebrauch und nutze die nur auf FreeBSD. Es gibt bei ZFS keine Dateisystem-Reparatur, es ist aber auch (theoretisch) unkaputtbar und braucht so etwas dann auch nicht. Was ich gelernt habe: auch in FreeBSD wechseln die Versionen von ZFS und sind nicht immer vollständig abwärts-kompatibel, sprich, auf einem alten FreeBSD mit einer alten ZFS-Version kann ich mitunter Schwierigkeiten haben, einen neuen Pool zu importieren. Ich kann mir vorstellen, dass dies zwischen unterschiedlichen Systemen eine noch größere Rolle spielen kann. Da würde ich zuvor ausgiebig testen wollen.
Den Import der externen Pools muss ich manuell vornehmen und ich glaube, als root, bin da nicht ganz sicher. Die Namen der Pools habe ich zur Sicherheit auf die Platten außen angeschrieben. Obwohl das USB3 ist, scheint mir das Verhalten etwas behäbig, was aber natürlich auch an der HW liegen kann.
Die mehrere TB großen Platten werden dann aber zuverlässig bedient und auch Sync-Vorgänge über mehrere Tage laufen gut durch.
Also, ausreichend Erfahrung habe ich damit nicht und nur auf FreeBSD, aber für mich sieht ZFS auf externen Medien nicht grundsätzlich schlecht aus. Ich würde das an deiner Stelle einfach erst mit einem USB-Stick oder so mal testen, vor allem, zwischen den Systemen und auch, wie die dann reagieren, auch, wenn mal kein export durchgeführt wurde und wenn der Stick mal einfach so abgezogen wird (macht natürlich niemand, ist aber genau, was dann gerade passieren kann, wenn man es nicht haben mag, wenn etwa der Controller der externen Platte mitten im Sync abraucht).
 
Moment mal, das mit der Abwärtskompatibilität - kann ich dann evtl die Daten meiner USB Platte oder meines NAS (sollte das OS aus irgend einem Grund ausfallen) nicht mehr auslesen kann, weil das ZFS "zu alt" ist???
 
Bei Linux ist es leider inzwischen oft so das Default einfach der Bildschirm schwarz bleibt und man ohne viel Aufwand keinen Ansatz hat.
Ich bin jetzt weniger mit Linux-Distris routiniert oder gar festgelegt, aber wenn es mal bei einem debian-Verschnitt hängt, dann hilft oft einfach auf das richtige VT zu wechseln. Dann gibts auch lecker Text. ;) Das ist meist das erste oder zweite und xorg bringt den schwarzen Screen auf dem 7ten oder 9ten.

Windows zeigt in der Regel wenn was schief geht einen Fehlercode.
...wobei man die häufigsten irgendwann auswendig und folgerichtig deuten kann. :D

Welches ist (mit) das zuverlässigste Dateisystem?
Hintergrund: will mir ne USB Platte als zusätzliches Backupmedium anschaffen und frage mich, mit was ich sie am besten formatiere. ZFS?
Wirklich irreparabel geschrottet bekommen hab ich bisher nur FAT16 und FAT32. Ohne Hardware-Fail, versteht sich. Womit wir bei der Kernaussage sind: wenn deine einzelne USB-Platte die Hufe streckt, kann auch das Superduper-FS keine Daten mehr aus dem Äther ziehen. ;)
Du kannst bei ZFS das Attribut copies z.B. auf 3 hochsetzen, dann wird alles 3x gespeichert, der verfügbare Platz allerdings dann auch gedrittelt. Das hilft allenfalls bei kaputten Sektoren und ein wenig dem Gewissen, aber nicht, wenn der Kopf schon die Magnetschicht runterspachtelt.

nicht mehr auslesen kann, weil das ZFS "zu alt" ist???
Nein, abwärtskompatibel etc. geht immer, soweit ich weiß. Nur wenn du einen neuen pool mit altem Softwarestand lesen willst, gehts nicht.
 
Das trifft nur zu, wenn das OS, bzw. die darin vorhandene ZFS-Version älter sind, als das ZFS auf dem Datenträger, den man lesen möchte. Mit einem aktuellen OS kannst Du ältere ZFS-Pools immer lesen.
 
Nein, abwärtskompatibel etc. geht immer, soweit ich weiß. Nur wenn du einen neuen pool mit altem Softwarestand lesen willst, gehts nicht.
Das trifft nur zu, wenn das OS, bzw. die darin vorhandene ZFS-Version älter sind, als das ZFS auf dem Datenträger, den man lesen möchte. Mit einem aktuellen OS kannst Du ältere ZFS-Pools immer lesen.
so habe ich das erlebt.
Nur ist mein NAS wirklich sehr alt und ich habe den isoliert und ohne updates laufen seit FreeBSD 7.x
Er hat definitiv ein anderes ZFS, als meine aktuellen Rechner.
Und er kann meine aktuellen Backup-Pools auf externen Medien nicht direkt importieren!
(Das ist für mich gar nicht schlimm, ich importiere sie in meinem aktuellen PC und synchronisiere die Daten über Netz, anstatt die neuen Platten mit neuen Pools am alten NAS mit USB2 einzubinden).
Ist für mich kein Problem, aber ich würde mich nicht so gerne blind darauf verlassen, dass ZFS on LInux und ZFS on OS-X immer alles so können und machen, wie wir in FreeBSD. Ich würde da recherchieren und jeweils probieren.

Was ich wollte: ein Achtung! Flag setzen.
Selbst mit dem besten und sichersten Dateisystem der Welt kann man immer noch Probleme bekommen!
 
P.S. für alle, welche mal ein "verrottetes" File sehen wollen... so schaut bit-rot aus:
Das ist original aus meiner eigenen Erfahrungs-Sammlung - lag damals auf nem USB-Disklein mit FAT32, hab die Datei so wie sie dann war mal gesichert, es war ursprünglich ein Schaltplan zu meinem Heathkit-Röhren-Voltmeter

Reiner Zufall, wenn man sowas im Firmenumfeld auf Filern mit Milliarden von Dateien mal rechtzeitig findet... gut, wenn man ein Dateisystem mit bit-rot Prävention hat, wie z.B. ZFS

Selection_002.png
 
Auch wenn Checksummen im FS durchaus schick sind, so muss man doch anmerken, dass sowohl Linux als auch FreeBSD das auch auf Blockebene machen können (geli, bzw. dm integrity). Dann ist es egal welches FS man oben draufsetzt.
 
Auch wenn Checksummen im FS durchaus schick sind, so muss man doch anmerken, dass sowohl Linux als auch FreeBSD das auch auf Blockebene machen können (geli, bzw. dm integrity). Dann ist es egal welches FS man oben draufsetzt.

Ja, aber...

dm-integrity is able to detect bit rot. [...] What's left is to build an automated way to use RAID to fix corrupted data by using a known good copy (that is, one with a valid checksum) to recreate the corrupted segments on a different part of the disk. This part is still being worked on, with Red Hat and in the upstream communities.

https://www.redhat.com/en/blog/what-bit-rot-and-how-can-i-detect-it-rhel

Und genau das kann ZFS schon ewig.
 
Das dm-integrity kanns detektieren, das ZFS kanns (innerhalb gewisser Grenzen) automatisch reparieren/auffangen. Ärgerlich ists sowieso, wenns soweit kommt, aber es passiert;
 
Ja, aber...

dm-integrity is able to detect bit rot. [...] What's left is to build an automated way to use RAID to fix corrupted data by using a known good copy (that is, one with a valid checksum) to recreate the corrupted segments on a different part of the disk. This part is still being worked on, with Red Hat and in the upstream communities.

https://www.redhat.com/en/blog/what-bit-rot-and-how-can-i-detect-it-rhel

Und genau das kann ZFS schon ewig.

Möglicherweise ist das noch nicht bei RHEL angekommen, aber ein aktuelles Fedora kann das schon.

Ich wollte eigentlich nur darauf hinweisen, dass viele Wege nach Rom führen, ich verwende auch gerne ZFS, aber es gibt auch Szenarien für die ZFS weniger geeignet ist.
 
Ich wollte eigentlich nur darauf hinweisen, dass viele Wege nach Rom führen...

Es soll und darf ein jeder nach seiner Fassong (mit dem FS seiner Wahl) glücklich werden - nur weil ich von ZFS begeistert bin, müssen es andere nicht sein. Gottseidank hat man in der Nicht-Windows-Welt die Wahl...
 
Hallo Leute,

gerade in bezug auf Dateisysteme möchte ich fragen, ob jemand von Euch auch "verteielte" Dateisysteme einsetzt? Ich denke insbesondere an MooseFS ...habe es vor Jahren mal testweise ausprobiert und war sehr angetan. Leider macht es erst Sinn, wenn mann viele Datenserver hat und auch so etliche TB hosten muss. Das ist auf meiner Arbeit in der Bioinformatik kein Problem ;-) Da würde sich jeder über PB Storage tierisch freuen... Nochmal zur Frage: hat das jemand schon im Einsatz?

VG aus Münster und einen guten Rutsch die kommenden Tage, Norbert
 
Zurück
Oben