Fileserver für Win 9x und andere alte Betriebssysteme mit ZFS und Linux

    Wir wissen inzwischen, dass Windows 98se und andere alte Betriebssysteme auf aktuelle NAS Systeme nicht vernünftig zugreifen können.

    Daher möchte ich hier eine kleine Anleitung zusammenschreiben wie man einen funktionierenden Fileserver selber baut.

    ACHTUNG: ES WERDEN VIELE SICHERHEITSFEATURES DEAKTIVIERT. NUR IN SICHEREN NETZWERKEN NUTZEN UND AUF EIGENES RISIKO!

    Benötigte Hardware / Demo Hardware:

    Generell gilt, es ist fast egal welche Hardware ihr nutzt. An sich reicht ein altes Mainboard und eine alte gammel IDE HDD um dieses / ein ähnliches Setup aufzusetzen, allerdings gibt es ein paar Empfehlungen:

    Empfehlungen:

    64Bit Betriebssystem:

    ZFS kann mit einem 32bit Betriebssystem arbeiten, da es allerdings vom grundsätzlichen Design auf 64bit ausgelegt ist und eine menge RAM nutzt ist ein 64bit System von Vorteil.

    Ich werde hier alles mit 64bit machen.

    ECC-Ram:

    ZFS nutzt Checksummen um die Datenintegrität sicher zu stellen. Allerdings ist es (genau wie alle anderen Dateisysteme) anfällig für Fehler im Arbeitsspeicher. Daher ist es sinnvoll wann immer es geht ECC Speicher einzusetzen. Dies heist allerdings nicht, dass man lieber ein EXT4/NTFS nimmt wenn man keinen ECC Ram hat. Selbst in dem Fall bietet ZFS eine bessere Sicherheit.

    1GB RAM pro TB Storage:

    Diese Faustregel ist schwierig. Ich selbst habe noch nicht ausreichend Tests gemacht und im Netz finden sich epische Troll fights hierzu.

    Grundsätzlich ist es sinnvoll so viel RAM wie möglich im System zu haben. Allerdings ist dies auch eine Frage wohin wir wirklich wollen.

    Ein Firmenserver wo 1000 Leute rund um die Uhr drauf zugreifen, wo z.b. eine Datenbank und ein Fileserver drauf rennt braucht weit mehr Arbeitsspeicher fürs Storage als ein kleiner Fileserver der nur 1-2 Leute Bedient. ZFS nutzt den RAM zum einen als Datencache und zum anderen auch für Metadaten.

    2 SSDs mit Power-loss Protection:

    Auch hier gilt man kann selbstverständlich auch auf eine einzelne SSD setzen oder es ganz weglassen. Wir wollen allerdings auf Nummer sicher gehen.

    Diese beiden SSDs sollten in unserem Beispiel mindestens 10GB pro TB Storage haben. Man kommt allerdings auch gut mit kleineren aus, sollte man einige später genannte Features weglassen wollen. Power-loss Protection ist hier Wichtig, da wir all unsere Metadaten auf der SSD liegen haben. Sollten wir keine Power-loss Protection haben, kann es zu Datenverlust kommen. Beispiel A: SSD bearbeitet grade ihre Internen Metadaten ---> kompletter Datenverlust auf der SSD ---> Metadaten fürs Storage weg ---> Datenverlust. Beispiel B: SSD bestätigt Schreibvorgänge obwohl sie noch im Cache liegen ---> Datenkorruption / evlt kann man die zuletzt geschriebenen Daten nicht mehr vom Storage lesen oder Datenverlust.

    Generell gilt hier der Spruch: Sollten einem seine Daten wichtig sein, immer auf Power-loss Protection achten bei SSDs, auch ohne ZFS....

    2 HDDs:

    Man kann natürlich auch ein reines SSD Storage bauen... Dennoch haben heutzutage Festplatten immer noch die besten Preise / GB. Und wir werden sämtliche Nachteile für ein home Storage mit Festplatten hier erschlagen, ob ihr es glaubt oder nicht.

    Optimal: 1 sehr schnelle oder billige U.2 / M.2 SSD:

    Je nachdem wie ihr das System ans Netzwerk anbindet, sollte diese SSD schneller im Lesen sein als euer Netzwerk. z.b. Sollte bei einem 10gbit netzwerk die SSD mindestens 1GB/s Lesen können. Weiterhin ist hier eine hohe TBW von Vorteil.

    Wir nutzen folgende Hardware zum Testen:

    X8SIL-F

    Intel X3450

    32GB Reg ECC

    2 Intel 320 120GB SSDs

    2 HGST HE10 10TB

    1 Intel X540 10G Netzwerkkarte

    1 Intel P4610 1.6TB

    Lass uns doch mal ansehen wie unsere Benchmark werte aussehen. Fangen wir mit den SSDs an:


    Bei den SSDs ist die sequenzielle Lese und Schreibgeschwindigkeit für uns eigentlich zweitrangig. Diese können aber später relevant werden.

    Hier haben wir Werte ab 4KB Das sind etwa 98mb/s beim Lesen und 78mb/s beim Schreiben. Je nachdem wie wir später das Storage aufsetzen kann es hier beim Schreiben zu einem irrelevanten Bottleneck kommen. Allerdings liefern uns die SSDs 260mb/s beim Lesen. Was schon mal für uns voll ausreichend ist.

    Nach 4KB brechen die IO/s zusammen. Aber für uns sind nur die 4KB IO/s interessant.

    Noch einen AS SSD benchmark zum Schluss. Ich Wette ihr habt schon weit bessere Ergebnisse gesehen. Allerdings ist dies für unseren Anwendungsfall mehr als ausreichend.

    Was machen unsere HDDs:

    Wenigstens gewinnen die SSDs beim Random IO und den Zugriffszeiten :)

    Lass uns mal Kopieren:

    HDTune misst nur die ersten 2 TB, dennoch haben wir einen Durchsatz von etwa 220 MB/s.

    Wir sind also mehr als schnell genug um ein 1gb Netzwerk auszulasten. Ein 10gbit Netzwerk wird uns allerdings Probleme machen. Ich gehe davon aus, dass wir Später mit 200MB/s schreiben und mit 400-500 MB/s lesen können.

    Sehr wichtig ist allerdings, dass man auf die verbaute Hardware achtet. Der Intel Chipsatz den wir hier verbaut haben hat ein kleines Problem:

    Wir haben beim SATA Controller nur eine Bandbreite von etwa 760MB/s. Solltet ihr wie ich auch ein 10g Netzwerk zuhause haben, und hier 6 Platten im Raid 6 nutzen wollen, habt ihr ein Problem....Für unsere Testes reicht es.

    Wir nutzen folgende Software hierzu:

    Debian 11

    ZFS + Tools

    Samba

    Lass uns mal mit dem Setup beginnen:

    Wir nutzen ein Debian 11 in diesem Beispiel, dieses ist mit eine der besten Linux Distributionen, wenn es um Zuverlässigkeit und Einfachheit geht.

    Debian nutzt nicht die aktuellste Software, da es eine lange Testphase für Pakete gibt. Ihr könnt gerne andere Betriebssysteme testen. Allerdings werden wir hier keinerlei Diskussionen dulden ob Debian oder Distro XYZ besser ist. Fakt ist einfach Debian ist für uns hier am besten, da die Anleitung mit Debian arbeitet. ;)

    Hier mal das Setup in Screenshots:

    Englisch ist eine Schöne Sprache. Wir werden hier alles in Englisch machen, Ich könnt auch Deutsch wählen, davon kann ich euch nicht abhalten. Wenn ihr dies tut kann ich euch allerdings ggf nicht helfen ;)

    Hostnamen solltet ihr einen eintragen, welcher in euer Namensschema passt.

    Ich denke es ist klar, dass root hier nur ein demo Passwort ist und nicht genutzt werden sollte.

    Wir nutzen die ganze Festplatte und lassen LVM weg.

    Wir packen alle Daten auf eine Partition. Das ist für uns vollkommen ausrechend. Die anderen Optionen haben auch ihren Sinn und Zweck, z.b. wenn irgendeine logdatei under /var/log voll läuft ist /home und so weiter nicht betroffen.

    Hier müssen wir eigentlich auf Ja drücken, tun wir dies nicht wiederholt sich alles von vorne:

    So anhaken wie hier zu sehen. Wir brauchen keine Desktop Umgebung!

    Damit haben wir Debian Installiert. Jetzt kommt die Installation und das Einrichten von ZFS

    Wir werden ab hier Codeblöcke für grössere mengen an Quelltext nutzen oder grün um einzelne Befehle im Text hervorzuheben.

    Wir können uns jetzt entweder mit SSH auf das System verbinden oder direkt am Gerät arbeiten.

    Putty kann für Windows genutzt werden. Unter Linux gibt es den ssh Befehl.

    Um die IP Adresse des Systemes herrauszufinden kann der Befehl ip address genutzt werden.

    Nachdem wir uns eingeloggt haben Begrüsst uns der Server erst einmal mit einer Information und dadrunter mit der Kommandozeile.

    nun werden wir erst einmal root um ZFS und Samba zu installieren.

    Code
    bier@FileserverLAN:~$ su -
Password:
root@FileserverLAN:~#

    das su - wechselt in den super user account anschließend geben wir das root Passwort ein und haben einen root prompt.

    Wir müssen nun die source.list anpassen:

    Code
    root@FileserverLAN:~# nano /etc/apt/sources.list

    wir öffnen die source.list hier mit dem editor nano. Die source.list ist die Datei, welche die Paket quellen enthält, wenn wir Programme installieren. Wir müssen nun an jede Zeile contrib non-free anhängen:

    Orginal:

    Nach der Bearbeitung:

    Die # ist der beginn eines Kommentars. Wir speichern das ganze jetzt mit strg +s und beenden nano mit strg +x

    apt update aktualisiert jetzt unsere lokale Paket liste:

    Nun können wir zfs und samba installieren:

    wir bestätigen mit y und dann wird eine menge an Zeug aufs system installiert. Dieses kann einen moment Dauern.

    Irgendwann kommt eine Meldung: Licenses of OpenZFS and Linux are incompatible Diese können wir einfach bestätigen.

    wir brauchen noch die Smartmontools:

    Wir können jetzt entweder mit modprobe zfs das ZFS Modul laden oder das system einfach mit reboot neu starten.

    Jetzt kommen wir zu dem spannenden Teil. Wir richten unser Storage ein. Und das erste was wir dafür brauchen ist ein Name.

    Namen sind wichtig. Sie verleihen dir Macht! ;) Ich benenne meine großen Storages zum Beispiel nach den 7 Weltmeeren. Da dies ein kleines Storage ist werden wir einfach mal einen Himmelskörper nehmen: Merkur

    Lasst uns erst mal eine Liste mit unseren aktuell genutzten Laufwerken anzeigen:

    Code
    root@FileserverLAN:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  2.4M  3.2G   1% /run
/dev/sde1       109G  1.6G  102G   2% /
tmpfs            16G     0   16G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           3.2G     0  3.2G   0% /run/user/1000

    wie wir sehen ist auf /dev/sde1 unser Betriebssystem. Dieses sollten wir nicht löschen.

    Wir können uns jetzt auch die Smart Informationen von sde anzeigen lassen. Dies machen wir mit smartctl /dev/sde -iAH

    Hier haben wir die Informationen von dem Systemlaufwerk. Dieses wollen wir nicht im ZFS nutzen.

    Wir wechseln jetzt das Verzeichnis und zeigen uns dort alles an.

    Das /dev Ordner ist ein Ordner, in welchem sich die Hardware befindet. Wir gehen in den Unterordner /dev/disks/by-id und lassen uns hier mit ls -al alles anzeigen.

    Da wir unsere beiden Festplatten Energiespaaren sollen, nutzen wir hdparm (wir installieren es wieder mit apt-get install hdparm) um unsere Festplatten nach einer gewissen Zeit ohne Last ausschalten zu lassen. Dafür nutzen wir das -S Flag.

    Code
    -S     Put  the  drive into idle (low-power) mode, and also set the standby (spindown) timeout for the drive.  This timeout value is used by the drive to determine how long to wait (with no disk activity) before turning off the spindle motor  to  save  power.   Under  such  circumstances,  the  drive may take as long as 30 seconds to respond to a subsequent disk access, though most drives are much quicker.  The encoding of the timeout value is somewhat peculiar.  A value of zero means "timeouts are disabled": the device will not automatically enter standby  mode.   Values from 1 to 240 specify multiples of 5 seconds, yielding timeouts from 5 seconds to 20 minutes.  Values from 241 to 251 specify from 1 to 11 units of 30 minutes, yielding timeouts from 30 minutes to 5.5 hours.  A value of 252 signifies a timeout  of  21 minutes.  A  value of 253 sets a vendor-defined timeout period between 8 and 12 hours, and the value 254 is reserved.  255 is interpreted as 21 minutes plus 15 seconds.  Note that some older drives may have very different interpretations of these values.

    Wir nutzen stellen nun die Platten auf 20 Minuten Timeout. Dies sollte für unsere Anwendung mehr als ausreichend sein. Dies machen wir für beide Festplatten.

    Code
    root@Froot@FileserverLAN:/dev/disk/by-id# hdparm -S 240 ata-HGST_HUH721010ALE600_2TJZH0XD

ata-HGST_HUH721010ALE600_2TJZH0XD:
 setting standby to 240 (20 minutes)

    Wir nehmen jetzt unsere beiden mechanischen Platten und machen daraus einen ZFS Mirror.

    Code
    root@FileserverLAN:/dev/disk/by-id# zpool create Merkur -f -o ashift=12 mirror ata-HGST_HUH721010ALE600_2TGUM59D ata-HGST_HUH721010ALE600_2TJZH0XD

root@FileserverLAN:/dev/disk/by-id# zpool list -v
NAME                                    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
Merkur                                 9.09T   396K  9.09T        -         -     0%     0%  1.00x    ONLINE  -  
  mirror                               9.09T   396K  9.09T        -         -     0%  0.00%      -  ONLINE
    ata-HGST_HUH721010ALE600_2TGUM59D      -      -      -        -         -      -      -      -  ONLINE
    ata-HGST_HUH721010ALE600_2TJZH0XD      -      -      -        -         -      -      -      -  ONLINE
root@FileserverLAN:/dev/disk/by-id#

    Hier haben wir mit zpool create Merkur den Storage Pool hergestellt. -f Forciert das erstellen des pools -o ashift=12 gibt an welche sektorgrösse wir nutzen. 12 entspricht 4k und anschließend haben wir gesagt mit mirror HDD1 HDD2 das wir HDD1 und HDD2 als mirror zu dem neuen Pool hinzufügen wollen.

    Wenn wir einen Mirror mit zwei unterschiedlichen Festplatten haben, haben wir beim Schreiben die Geschwindigkeit der Langsamsten Platte, beim Lesen die Geschwindigkeit beider Platten gemeinsam und die Kapazität der kleinsten Platte.

    zpool list -v gibt uns den den Aufbau unserer Pools aus.

    Wir haben hier einen Pool mit namen Merkur und einem VDEV als mirror mit 2 Festplatten.

    mit df -h können wir jetzt unseren Pool sehen:

    Code
    root@FileserverLAN:/dev/disk/by-id# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  2.4M  3.2G   1% /run
/dev/sde1       109G  1.6G  102G   2% /
tmpfs            16G     0   16G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           3.2G     0  3.2G   0% /run/user/1000
Merkur          8.9T  128K  8.9T   1% /Merkur
root@FileserverLAN:/dev/disk/by-id#

    Wir könnten jetzt zur Samba Konfiguration weiterspringen. Allerdings wollen wir das ganze jetzt noch weiter einrichten.

    Wir haben ja noch die beiden 120GB SSDs. Diese nutzen wir als Spezial VDEV.

    Ein Spezial VDEV ist einer der 3 Turbolader die man bei einen Storage Pool einrichten kann. Und je nach Anwendungsfall einer der wichtigen.

    Ein Spezial VDEV hat drei relevante Funktionen:

    Metadaten:

    Auf dem Spezial VDEV können sämtliche Metadaten abgelegt werden, welche ZFS benötigt um auf die Festplatten zuzugreifen.

    Also Block XYZ gehört zu Datei XZY und liegt auf der Festplatte YZX an Position ZXY und ist YXZ gross.

    Sprich um eine Datei vom Storage zu lesen sind nur noch ein Bruchteil der Zugriffe auf die mechanische Platte notwendig, denn auf der HDD liegen wirklich nur noch die Daten die zur Datei gehören. Es kann also Linear gelesen werden, ohne andauernd in einem langsamen Index (auf der HDD) nach dem nächsten Block suchen zu müssen.

    Das ganze hat auch den Vorteil, dass wenn man sich den Inhalt eines Ordners anzeigt oder durchs Dateisystem wandert oder sich die gösse eines Ordners anzeigen will, alle Informationen von der SSD Kommen und nicht von der Festplatte. (solange man natürlich keine Vorschaubilder lädt. ...) Sprich die Festplatte springt erst an, wenn man wirklich Daten haben will.

    dedup Table:

    ZFS hat eine eingebaute deduplication, sofern man sie aktiviert. Ohne Spezial VDEV liegt diese Tabelle im Arbeitsspeicher und braucht dort etwa 5GB/TB Daten. Und mit einem Spezial VDEV liegt das ganze auf den SSDs, hierzu kommen wir später noch genauer.

    spezial_small_blocks:

    wir können ZFS sagen, dass alle Datenblöcke die kleiner als xKB sind aufs Spezial VDEV gelegt werden sollen. Somit kann der ganze Kleinkram auf dem Spezial VDEV gespeichert werden und dadurch nutzen wir die SSDs und Festplatten jeweils für was sie am Besten geeignet sind. Festplatten liefern all das große Zeug wie ISOs Filme und die SSDs liefern alles was IO Schluckt, wie kleine Textdateien etc.

    Das hinzufügen von einem Spezial VDEV lohnt sich auf jedenfall, wenn man grade zwei passende SSDs zur Hand hat.

    Also fügen wir es mal hinzu:

    So nun haben wir zwei VDEVs eins für Daten und eins für Metadaten etc.


    Nun fügen wir noch einen L2Arc Cache hinzu:

    Das Cache Device ist eine schnelle SSD, welche oft gelesene Daten zwischenspeichert. Dies sollte uns ermöglichen deutlich schneller Daten zu Kopieren.

  • Bier.jpg 30. Dezember 2022 um 19:14

    Hat den Titel des Themas von „Fileserver für Win 9x und andere alte Betriebssysteme mit ZFS und Linux“ zu „Fileserver für Win 9x und andere alte Betriebssysteme mit ZFS und Linux (in Bearbeitung)“ geändert.

    Hier wollen wir jetzt etwas tiefer in die ZFS Configuration reingehen, Ich würde euch bitten zumindest den abschnitt ZFS Config und Datasets durchzuarbeiten, bevor ihr weiterspringt.


    ZFS Config:

    Wir wollen noch ein paar Konfigurationsparameter für das ZFS setzen.

    Als erstes wollen wir den ganzen pool mit LZ4 komprimieren. Dies kostet kaum Leistung und bringt eine Menge Platz

    Code
    root@FileserverLAN:/dev/disk/by-id# zfs set compression=lz4 Merkur

    Da ich sehr kleine SSDs habe lege ich nur die 4k Blöcke auf die SSDs:

    Code
    root@FileserverLAN:/dev/disk/by-id# zfs set special_small_blocks=4k Merkur

    Wir Setzen atime auf Off, da wir nicht wissen müssen, wann zuletzt auf eine Datei zugegriffen wurde und dies minimal Performance bringt:

    Code
     root@FileserverLAN:/dev/disk/by-id# zfs set atime=off Merkur


    ZFS Datasets:

    ZFS Datasets sind im Prinzip Ordner/Virtuelle Festplatten/Zuordnungseinheiten auf Dateisystem Ebene, welche verschiedene Eigenschaften haben können. Und unterschiedliche Settings haben können.

    Wir werden fünf Datensets anlegen in diesem Beispiel.

    Software

    Treiber

    ISOs

    SpieleLAN

    Daten

    Wir wollen jetzt allerdings, dass die Datensets ISOs Treiber und Software dedupliziert werden.

    Code
    root@FileserverLAN:/dev/disk/by-id# zfs set dedup=on Merkur/Daten Merkur/ISOs Merkur/Treiber
root@FileserverLAN:/dev/disk/by-id# zfs get dedup Merkur Merkur/ISOs
NAME         PROPERTY  VALUE          SOURCE
Merkur       dedup     off            default
Merkur/ISOs  dedup     on             local

    Hier setzen wir dedup für Merkur/Daten und für Merkur/ISOs und für Merkur/Treiber auf on. Allerdings nicht für Merkur selber.

    bei dem zweiten Befehl lassen wir uns die dedup Informationen für Merkur und Merkur/ISOs ausgeben.

    ZFS Snapshot

    Ein ZFS Snapshot kann mit zfs snapshot Merkur@demo erstellt werden und mit zfs list -t snapshot können die Snapshots angezeigt werden

    Code
    root@FileserverLAN:/# zfs snapshot Merkur@demo
root@FileserverLAN:/# zfs list -t snapshot
NAME                                                      USED  AVAIL     REFER  MOUNTPOINT
Merkur@demo                                                 0B      -      120K  -
root@FileserverLAN:/etc/cron.daily#

    mit zfs destroy Merkur@demo kann man jetzt den Snapshot wieder entfernen.

    Code
    root@FileserverLAN:/# zfs destroy Merkur@demo
root@FileserverLAN:/# zfs list -t snapshot
NAME                                                      USED  AVAIL     REFER  MOUNTPOINT
root@FileserverLAN:/#

    zfs-auto-snapshot

    zfs-auto-snapshot ist ein Tool welches uns die Arbeit abnimmt und regelmäßig Snapshots ablegt. Hiermit wird dafür gesorgt, dass wenn wir versehentlich eine Datei Löschen immer noch ein Snapshot mit dieser Datei vorhanden ist.

    Wir installieren zfs-auto-snapshot mit apt-get install zfs-auto-snapshot

    Jetzt kommen wir zur Samba Installation.

    Wir löschen die alte smb.conf und öffnen anschliessend eine neue Samba Config File:

    Code
    root@FileserverLAN:/Merkur# rm /etc/samba/smb.conf
root@FileserverLAN:/Merkur# nano /etc/samba/smb.conf

    Wir geben in diese Datei den Inhalt meiner smb.conf Datei ein:

    nun speichern wir das ganze wieder

    strg+s (zum speichern) und strg+x (zum verlassen)

    und starten den Samba server neu:

    Code
    systemctl restart smbd

    Wir passen nun noch die Berechtigungen an:

    Nun mounten wir das ganze noch unter Windows 98:

    Lasst uns mal ein paar Benchmarks machen:

    Wir fangen mit einem ganz normalen Kopier Benchmark von und zu Windows an.

    Hierbei nutzen wir auf der Windows Seite eine Ram Disk.

    Wir kopieren zuerst viele gemischte Dateien aufs Storage:

    wie wir sehen empfangen wir über das Netzwerk 234MiB/s und Windows sendet mit 247 MB/Sekunde.

    auf das Storage kopieren wir mit 728M. Also sind wir voll und ganz im Limit des SATA Controllers.

    Lesen tun wir mit 227MB/s. Das ist weniger als ich vermutet habe.


    Und hier der ATTO Benchmark:

    hier sieht man sehr schön den ZFS Cache am Werk :D

    Lasst uns mal einen PCI-E Festplatten Controller einbauen, um zu sehen ob der S-ATA Chipsatz uns Limitiert:

    Dies scheint nicht der Fall zu sein.

  • Bier.jpg 31. Dezember 2022 um 02:36

    Hat den Titel des Themas von „Fileserver für Win 9x und andere alte Betriebssysteme mit ZFS und Linux (in Bearbeitung)“ zu „Fileserver für Win 9x und andere alte Betriebssysteme mit ZFS und Linux“ geändert.

    Danke für die Mühe, jedoch finde ich (als Linux Konsolen-Noob) dies als recht kompliziert. Die einzig relevante Info für alte Betriebssysteme war für mich, die Protokollebene von SMB runterzustellen.

    Ich selbst nutze FreeNAS und dort habe ich nur die Protokollebene vom SMB-Dienst auf "Minimum" gestellt und schon kann Win98 drauf zugreifen.


    Thema 1GB RAM pro 1TB:

    Ich kanns in etwa nachvollziehen. Ich habe mit 0,85GB pro TB angefangen (Der RAM wird wohl als Filecache gebraucht) und manchmal war es so, dass nach langer Laufzeit ein Ordner mit mehr als 1.500 Unterodnern immer wieder sichtbare Ladehemmungen hatte. Ich bin sogar mal den Umweg über SSD's als Syslog (bzw. RAM-Ersatz) gegangen, was aber nicht wirklich geholfen hat.

    Mittlerweile habe ich die RAM-Menge verdoppelt und die Probleme sind Geschichte.

    Einmal editiert, zuletzt von bschicht86 (31. Dezember 2022 um 11:08)

    Ich würde einfach eine separate externe USB-Festplatte einrichten wo ich dann das ganze Win98-Geraffel drauf packe. Das ist natürlich nicht so geil wie ein Fileserver im Netzwerk.

    Permanent aufgebaut:
    A7V133, Athlon 1,4GHz, 512MB, GeForce3 Ti200 128MB, SB Live! X-Gamer
    Für die LAN:
    TUSL2-C, PIII-S 1,4GHz, 512MB, GeForce2 GTS 32MB, 2x Monster II 12M, SB Live!
    TUSL2-C, PIII-S 1,4GHz, 512MB, GeForce2 GTS 32MB, 2x Monster II 12M, SB Live!
    CUSL2-C, PIII 933MHz, 512MB, G400 Max 32MB AGP, 2x 3D Blaster Voodoo² 12MB, SB Live!
    CUSL2-C, PIII 933MHz, 512MB, G400 Max 32MB AGP, 2x Monster II 8MB, SB Live!

    Zitat von bschicht86

    [...] Thema 1GB RAM pro 1TB:

    Ich kanns in etwa nachvollziehen. Ich habe mit 0,85GB pro TB angefangen (Der RAM wird wohl als Filecache gebraucht) und manchmal war es so, dass nach langer Laufzeit ein Ordner mit mehr als 1.500 Unterodnern immer wieder sichtbare Ladehemmungen hatte. Ich bin sogar mal den Umweg über SSD's als Syslog (bzw. RAM-Ersatz) gegangen, was aber nicht wirklich geholfen hat. [...]

    Speziell wenn du Deduplizierung auf Blockebene hast, mußt du für jeden Block des Dateisystems einen Hash erstellen, üblicherweise ist das ein SHA-256 Hash. Dieser Hash identifiziert den Block als einzigartiges Datum. Jeder weitere Block, der den gleichen Hashwert produziert, wird als identisch erkannt, und dementsprechend nur mehr referenziert, aber nicht mehr separat gespeichert. Wenn du sehr viele gleiche Daten hast (z.B. VM Images mit gleichem Betriebssystem), ist das recht wurscht. Wenn du aber sehr viele unterschiedliche Daten hast, kriegst du sehr schnell SEHR viele Hashes, die du schnell verfügbar halten mußt. Zudem reduziert das die Effektivität der Deduplizierung.

    Tendenziell hält man diese Hashtabelle (ein Hash pro Block wohlgemerkt!) im RAM. Wenn das nicht mehr geht, müssen halt schnelle und haltbare SSDs als zusätzliches Speichermedium dafür her.

    Man bedenke: Jedesmal wenn du eine Datei schreibst, müssen die Hashes pro Block (!) erzeugt und mit ALLEN bereits bekannten Hashes (!) verglichen werden, damit die Deduplizierung greifen kann. Und das für jeden einzelnen, geschriebenen Block. Nun hat ZFS (soweit ich es weiß) variable Blockgrößen, was das ganze bei großen Dateien weniger schlimm macht, aber der Anspruch ist dennoch schon gut groß, auch im Hinblick auf CPU.

    Stell dir ein 64 TiB Dateisystem mit einer statischen Blockgröße von 16 kiB vor; Hier hättest du in Summe 4.294.967.296 Blöcke. Das wären also im Extremstfall 4.294.967.296 Hashes zu je 256 Bit oder 32 Byte. Das sind 128 GiB rein für die Hashtabelle. Wie gesagt, das ist der Extremfall eines mit zufälligen Daten gefüllten 64 TiB Mediums. In Realität wird die Tabelle natürlich den Daten entsprechend kleiner sein. Vor allem wenn nicht alles randvoll ist.

    Ohne Deduplizierung ist's natürlich viel genügsamer, was Speicher angeht.

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

    Also ich danke Bier.jpg für diese ausführliche Einführung. Überlege mir schon länger, selbst so etwas aufzusetzen. Allerdings müßte ich auch unter DOS darauf zugreifen können. Immerhin hab ich jetzt schon mal eine Stelle, wo ich anfangen kann nachzulesen. :thumbup:

    Ich werde mich von keinem einzzzigen Prozzzessor trennen.
    Jedoch lockt es mich beinahe, ihn Dir zu überlassen, nur um zu sehen, wie er Dich in den Wahnsinn treibt :evil:

    Meine Begehren

    Mh. Ich nutze FTP dafür.

    Also Client auf dem PC (egal welches OS, DOS, Win95/98, 2000 oder XP) und der Server läuft auf dem Laptop, der natürlich Vollzugriff auf NAS hat.

    Da ich den FTP Client auf der DS218 irgendwie nicht gebacken bekomme 🙈

    Moin Bier, sehr ausführliches howto, dafür erstmal Respekt. Auch für deine Zeit, das hier zu dokumentieren.

    Wie schnell ist der Zugriff von und zu Windows 98? Tweakstone hat ein sehr altes NAS als Brücke zwischen Win10 und Windows98 und kommt da teilweise auf sehr schnelle 6MB/s.

    Für viele andere ist bestimmt interessant, den Win98 Zugriff mit "weniger" Hardware zu realisieren.

    Ich denke ein ein howto mit Raspian und Samba config dazu wäre vielleicht noch interessant.

    So DoublePost....

    ich hab den Spaß mal nachgestellt auf einem alten Notebook (Thinkpad X120e) und mit Raspberry Pi OS.

    Alles default und stock, KEIN ZFS -> ext4.

    Läuft ganz gut. Ich bekomme immerhin 4MB/s von Win98 zum Thinkpad.

    Ziehe ich ein ISO vom Win98 bekomme ich ca. 1.1MB/s.

    hier das howto in Kurzform:

    i use an old laptop with Raspberry Pi OS x86:

    1. Download and install Raspberry pi OS

    2. On Desktop, start the terminal: sudo raspi-config

    3. Set your desired hostname and network settings (IP)

    4. Reboot

    5. Terminal: sudo apt-get install samba samba-common-bin

    6. use nano to change smb.conf to Bier.jpg smb.conf:

    sudo nano /etc/samba/smb.conf

    Highlight everything, delete with Strg+K

    paste the content

    edit paths as you need it

    Strg+X to safe

    7. Restart samba service: systemctl restart smbd

    8. edit permissions with chmod 777

    Meine smb.conf habe ich aber nochmal etwas angepasst:


    Wenn jemand zur LAN ohne Spiele kommt, könnte man mit ner LiveLinux CD booten und alles recht zügig ziehen.

    Einmal editiert, zuletzt von Grindhavoc (5. Januar 2023 um 21:18)

    Ist es euer Ernst, eine Datei offen wie ein Scheunentor zu machen?

    Ich meine, ich weiß, was ihr damit erreichen wollt, aber 777? Das ist ja grausam.

    "Du bist und bleibst a Mensch und du kannst eben net deine menschlichkeit überwinden."

    Dennis_50300

    Einmal editiert, zuletzt von CryptonNite (6. Januar 2023 um 06:33)