[Sammelthread] ZFS Stammtisch

Fakt ist:
ZOL + set sharenfs/smb = on --> Arg langsam!
ZOL + smbd --> sehr schnell!

ZOL + set sharenfs/smb = on --> Arg langsam! = SAMBA
ZOL + smbd --> sehr schnell! = SAMBA

ergo
(ZOL + set sharenfs/smb = on --> Arg langsam!) = (ZOL + smbd --> sehr schnell!)

offensichtlich falsch.


Das Problem liegt also weder in ZoL oder ZFS noch SAMBA sondern allenfalls in der unterschiedlichen Konfiguration bzw Aktivierung eines SAMBA Shares, eventuell daran dass SAMBA das ja nichts von ZFS weiß, sondern normalerweise nur das einfache Dateisystem sieht und bei dieser Art der Aktivierung plötzlich ZFS Dateisystemeigenschaften folgen und beachten muss, insbesondere bei Schachtelung der SMB Freigaben über tieferliegende ZFS Dateisysteme
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
besterino wusste es

also weiß ZOL + smbd mehr über zfs als ZOL + set sharenfs/smb = on ?:hmm:
 
auf jeden Fall weiß "es" mehr als du :rofl:
sorry coulnt resist

Sonst geht's dir noch gut? Woher möchtest du wissen, was ich weiß? Ich bin vielleicht nicht so allwissend wie du ( :hail: )oder manch andere hier, aber ich nehme Probleme wenigstens an und versuche sie zu lösen, was meistens auch klappt.

Manch einer von euch macht den ganzen Kram vielleicht beruflich, ich betreibe das lediglich privat als hobby und habe mir alles selbst angeeignet ohne das irgendwo gelernt zu haben.
 
Zuletzt bearbeitet:
Sonst geht's dir noch gut? Woher möchtest du wissen, was ich weiß? Ich bin vielleicht nicht so allwissend wie du ( :hail: )oder manch andere hier, aber ich nehme Probleme wenigstens an und versuche sie zu lösen, was meistens auch klappt.

Manch einer von euch macht den ganzen Kram vielleicht beruflich, ich betreibe das lediglich privat als hobby und habe mir alles selbst angeeignet ohne das irgendwo gelernt zu haben.

Mann du liest wohl deine eigenen Beiträge nicht mal richtig, sonst hättest du den Gag verstanden.
Schreibst du sie wenigstens selbst?

Was also soll ZOL über zfs "wissen" ? :stupid:
Was "weiß" Software überhaupt und wo liegt der Unterschied zwischen ZOL und zfs?

cu
 
Liest du eigentlich die Beiträge anderer Leute?

Das Problem liegt also weder in ZoL oder ZFS noch SAMBA sondern allenfalls in der unterschiedlichen Konfiguration bzw Aktivierung eines SAMBA Shares, eventuell daran dass SAMBA das ja nichts von ZFS weiß, sondern normalerweise nur das einfache Dateisystem sieht und bei dieser Art der Aktivierung plötzlich ZFS Dateisystemeigenschaften folgen und beachten muss, insbesondere bei Schachtelung der SMB Freigaben über tieferliegende ZFS Dateisysteme
 
Du kapierst es echt nicht, nicht auf die hintersinninge und nicht auf die brutale Weise, das du total daneben liegst mit deinen Behauptungen.
Irgendwelche Behauptungen in die Welt setzen, von verschiedenen Seiten erst ganz normal, dann deutlich auf den Denkfehler hingewiesen und zum Schluss immer noch drauf beharren, das ist einfach nur Dummheit. Hoffnungslose Dummheit.
 
Man kann auch einen ZFS Pool auf verschlüsselten Dateien per lofiadm anlegen. Wenn man daraus einen Raid-Z Pool macht, gibt es sogar Fehlertoleranz. Diese Dateien kann man dann auf unsichere Datenträger oder die Cloud sichern. Wenn man Dateien <2GB anlegt, kann man die auf beliebigen Dateisystemen sichern - selbst USB Sticks mit FAT32.

Die ZFS Sicherheit (Prüfsummen) bleibt erhalten und wenn man aus den Dateien ein Raid-Z oder Mirror macht, können auch Datenfehler behoben werden. Prinzip, siehe Introducing Sparse Encrypted ZFS Pools

Ok das hört sich sehr gut, auch das die Snapshots nicht aus einem großem File bestehen. Wollte das ganze über die Napp-it Gui erstellen und bin auf folgendes gestoßen:

Screenshot 2019-05-09 at 19.05.58.jpg

Permission denied. An was kann das liegen?


Dank im Voraus.
 
Wo liege ich denn bitte daneben? Habe ich mir die niedrigen Datenraten eingebildet oder was?

Ich hatte weder Denkfehler noch haltlose Behauptungen getätigt.

Dass ihr das nicht kapiert ist hoffnungslose Dummheit.
 
Lass doch mal gut sein. Dass Du nicht der Experte bist, schriebst Du selbst. Dass Du Ratschläge von Mehr-oder-minder Experten des jeweiligen Gebietes ignorierst, konnte ich in diesem Thread erahnen und im Mikrotik Threads hast Du es bewiesen.

Solch eine Diskussion ist immer schnell zu Ende, wenn eine der Parteien den Spaß daran verliert und aufhört zu schreiben. Nachdem Du in diesem Fall einer ziemlich überwältigenden Übermacht Andersdenkender gegenüberstehst und nicht jeder aufhören wird, Deine Meinung zu kommentieren, solltest Du vielleicht dem Grundsatz "der Klügere gibt nach" folgen.

Und noch einen kleinen Seitenhieb: Dass Du mühsam verfasste, seitenweise Erklärungen auf Deine Fragen auch ignorieren kannst ohne auch nur Danke oder irgendwas zu der Erläuterung zu sagen, hast Du ebenfalls im Mikrotik Threads gezeigt ;-) Wenn ich mich recht entsinne, hatte Dir per PN sogar WhatsApp Support angeboten.

Insofern: Lass doch einfach gut sein und wir wenden uns wieder der sachlichen Ebene des Threads (ZFS - nicht welche CIFS Funktionalität ist die bessere) zu. Wäre ich Moderator, hätte ich hier vermutlich auch schon eingegriffen, zum Glück tragen Andere diese Last...
 
Um wieder aufs Thema zurückzukommen:

Was ist denn die sinnvollste Variante, ZFS und napp-it mit AD Anbindung (Rechtevergabe muss zu 100% per W-Client möglich sein) unter Proxmox laufen zu lassen? Hatte kurzzeitig wieder mit Solaris 11.4. geliebäugelt, aber da ist die Integration (Agent, VirtIO Netzwerk/Platten/Balloning) eben doch ziemlich dürftig. Verschlüsselte Filesystems hätte ich zwar gerne, aber das kann ich auch später noch in Angriff nehmen.
Nachdem das Ganze auf Microservern gen8 laufen soll, ist der zugewiesene RAM leider möglichst knapp zu halten. gea schreibt von 2GB, aber unter Oracle Solaris 11.4 hatte ich erst ab ca. 4GB dauerhaft/nicht einbrechende Übertragungsraten.
@gea: Du hattest es mir schonmal gesagt, aber was nutzt du nochmal?

Kann jemand sagen, ob es unter Proxmox ebenfalls deutlich sinnvoller ist, den ganzen Controller statt einzelner Platten durchzurechnen? Nachdem der MS neben zu wenig RAM ja nur einen PCI-E (10G) Steckplatz bietet, nicht von USB3 booten kann (ggf. per Grub auf USB2 im internen USB Slot) und nur einen B120i hat, überlege ich schon länger, was der beste Weg ist.
Die Variante ESXi mit Storage VM auf Consumer USB Stick ging ziemlich schnell in Rauch auf und ESXi ist mir bzgl. der RAM Verteilung zu unflexibel. Das Schreddern des Sticks würde ich entweder über einen Proxmox/nappit Sandisk ExtremePro USB3 Stick oder notfalls eine externe SSD auffangen wollen. Blöderweise ist ein USB2 Stick in jedem Fall nötig, um die USB3 Platten zu booten (der PoC steht noch aus, aber ich denke, dass es funktionieren sollte)

Ja, MSs verscherbeln und was passendes kaufen ist auch eine bekannte Variante, aber ich hänge so sehr an den Zwergen, dass ich gerne damit arbeiten würde.
 
Ok das hört sich sehr gut, auch das die Snapshots nicht aus einem großem File bestehen. Wollte das ganze über die Napp-it Gui erstellen und bin auf folgendes gestoßen:

Anhang anzeigen 466076

Permission denied. An was kann das liegen?


Dank im Voraus.


Das aktuelle Poef Modul ist ein recht aufwändiger freier Community Beitrag.
Ich habe mir das kurz angeschaut. Das Problem scheint in der kürzlichen Umstellung von Sun SSH zu OpenSSD in OmniOS zu liegen. Damit laufen pfexec Befehle im aktuellen OmniOS nicht mehr.

Bis zur Behebung muss ich um etwas Geduld bitten.

Workaround:
Manuell anlegen, siehe Pools > Encrypt Pool on files > help

- - - Updated - - -

Um wieder aufs Thema zurückzukommen:

Was ist denn die sinnvollste Variante, ZFS und napp-it mit AD Anbindung (Rechtevergabe muss zu 100% per W-Client möglich sein) unter Proxmox laufen zu lassen? Hatte kurzzeitig wieder mit Solaris 11.4. geliebäugelt, aber da ist die Integration (Agent, VirtIO Netzwerk/Platten/Balloning) eben doch ziemlich dürftig. Verschlüsselte Filesystems hätte ich zwar gerne, aber das kann ich auch später noch in Angriff nehmen.
Nachdem das Ganze auf Microservern gen8 laufen soll, ist der zugewiesene RAM leider möglichst knapp zu halten. gea schreibt von 2GB, aber unter Oracle Solaris 11.4 hatte ich erst ab ca. 4GB dauerhaft/nicht einbrechende Übertragungsraten.
@gea: Du hattest es mir schonmal gesagt, aber was nutzt du nochmal?

Ausgehend von Proxmox ist mein Wissenstand dass Unix Clients wie Solarish nicht so perfekt laufen. Eine Solarish Storage VM ist also nicht so perfekt und die Linux Variante von napp-it mit SAMBA ist ZFS Management only also ohne AD support. Auch unterstützt SAMBA keine Windows sid, keine SMB Gruppen (können mehr als Unix Gruppen z.B. Gruppen enthalten) und keine Windows ntfs artigen NFS4 ACL sondern üblicherweise allenfalls einfachere Posix ACL. Management von Windows aus ist immer möglich aber mit genannten Einschränkungen.

Meist wird Proxmox daher ohne Storage VM und CLI henutzt. Vom Speicherhandling finde ich aber ESXi perfekt. Balloning ist Mist mit ZFS (das will alles nehmen was da ist). Feste Speicherzuweisung mit ESXi und Pass-through ist perfekt für eine Storage VM. Auch braucht ESXi für sich selber eher weniger als Proxmox wo man ja ein komplettes Debian unter die VMs legt.

Die 2 GB bei Solaris betreffen die Stabilität. Es stürzt also nicht ab hat aber keinen Speicher für Schreib/Lesecache. Mit einem Pool aus Intel Optane mag das sehr schnell sein, mit einem Platten-Pool ist das natürlich grottenlangsam. Immerhin braucht Solaris oder OmniOS mit napp-it erheblich weniger RAM als z.B. ein FreeNAS.

Ich selber nutze ausschließlich ESXi + OmniOS (Solaris ist mir auch zu teuer, trotz F&L und die freie Version kann ich da nicht nutzen)

Der übliche Weg unter Proxmox dürfte sein
Proxmox + SAMBA (CLI)
 
Samba hat IMO einen Vorteil für Windows-Clients: Ich kann geschachtelte und im Mountpoint geänderte Datasets (z.B. von anderen Zpools), über ein einziges Share freigeben, da es dem Samba-Server wurscht ist, wie sich das Freigabeverzeichnis zusammensetzt.
Und der Client merkt nichts davon, für den ist das alles z.B. als ein Laufwerksbuchstabe ansprechbar. Einzig verschieben zwischen Unterverzeichnissen, die in unterschiedliche Datasets liegen, sind halt langsamer weil tatsächlich die Dateien rumgeschubst werden müssen.
 
Das ist richtig und manchmal sehr angenehm.
ZFS Snaps als Windows "vorherige Version" kann dann aber Probleme bereiten weil es für SAMBA kein eindeutiges Snapverzeichnis mehr gibt. SAMBA weiß dann halt nicht, was ist dummer Ordner und was ZFS Dateisystem mit zugehörigen Snaps.
 
Setzt hier jemand FreeNAS als Storage VM ein und kann etwas über die Performance insbesondere gegenüber OmniOS (napp-it) sagen? Ich setzte ganz normal ne SSD für die Storage VM (16GB RAM) + ESXi ein und einen Raid Mirror für die einzelnen OS VMs.

Ich finde napp-it super und muss sagen das gea hier einen super Job macht (er hilft immer usw.). Nochmal vielen Dank dafür! Napp-it läuft auch absolut ohne Problem, manchmal wünsche ich mir aber, dass ich mehr über die GUI machen kann (Backup, Serverdienste, Rechtevergabe etc.). Napp-it ist da zwar schon ganz gut, zum Teil muss man aber trotzdem Hand anlagen. Bin zwar Informatiker, mir fehlt aber schlecht Weg oft die Zeit mich da groß einzulesen, zumal ich in der SW Entwicklung tätig bin und kein Admin bin :)
 
@martingo: mein Tipp wäre dein letzter Satz. Hol dir eine Plattform, die dich nicht zu solchen - überspitzt: halbgaren - Kompromissen zwingt und mit der du es gescheit umsetzen kannst. ;) Noch bekommst du bestimmt ganz gute Preise für den (die?) MS.

@Rest: kommt mal runter. Hier pflegen wir doch sonst einen sehr freundlichen Umgangston, wäre schade, wenn wir das nicht wieder hinbekämen. Durchatmen, mal Faust in der Tasche machen, dem anderen mal beste Absichten und nicht das Schlechteste unterstellen und dann tanzen wir alle wieder fröhlich unsere Namen, die Sonne scheint, die Vöglein zwitschern und alle haben sich wieder lieb. :d
 
Zuletzt bearbeitet:
@besterino: Ich weiß, aber ich bin hier leider unbelehrbar und möchte trotzdem daran festhalten :d Vielleicht kommt in Zukunft mal noch ein zusätzlicher Server her, der dann das Storage macht, aber ich habe das Wunschgerät noch nicht gefunden.

@gea: Grundsätzlich unterstützt Samba schon Windows ACLs ( Setting up a Share Using Windows ACLs - SambaWiki ), die sich auch über Windows sauber konfigurieren lassen. Die POSIX ACLs sind es, die recht hemdsärmlig daher kommen: Setting up a Share Using POSIX ACLs - SambaWiki
Bisheriger Plan war, das ZFS unter Proxmox einzurichten, aber über einen internen Mountpoint an einen LXC Container durchzureichen. Dieser Container sieht dann nur den Inhalt, hat aber keine Ahnung, dass ZFS darunter liegt. Das ist Fluch und Segen zugleich - zum einen funktioniert ZFS in einem LXC nicht, zum anderen kann der Container dann aber auch keine ZFS Features wie Vorgängerversion verwenden. Ich habe nun drei Alternativen (wenn Proxmox gesetzt bleibt):
- Mountpoint innerhalb eines LXC: wenig Ressourcenbedarf, Vorteil der sehr guten Sicherungsmöglichkeiten, man kann beliebig experimentieren etc. Nachteil: Verlust einiger ZFS/SAMBA Features
- HDD/PCI Passthrough an eine VM: mehr Ressourcenbedarf, Einschränkung bzgl. Notwendigkeit USB Boot etc, allerdings volle Featurenutzung des VM-Systems. Hier ist Dein Hinweis sehr gut, dass Solaris* unter Proxmox nicht taugt
- SAMBA Server auf dem Proxmox: geringster Overhead, volle Featurenutzung; allerdings höchster Konfigurationsaufwand auf dem Hostsystem

Hauptgrund wieso ich überhaupt nochmal Solaris* ins Spiel gebracht hatte, war, dass ich auf zugunsten sssd auf winbind verzichten wollte und die Lösung noch nicht ganz rund ist. Vielleicht doch nochmal ansehen.

Ich weiß auch noch nicht so recht.... :-(
 
Zuletzt bearbeitet:
Ok das hört sich sehr gut, auch das die Snapshots nicht aus einem großem File bestehen. Wollte das ganze über die Napp-it Gui erstellen und bin auf folgendes gestoßen:

Anhang anzeigen 466076

Permission denied. An was kann das liegen?


Dank im Voraus.

Das Anlegen eines verschlüsselten ZFS Z2 Pools auf Dateien via napp-it GUI im aktuellen OmniOS sollte nach einem Re-download (About > Update) der aktuellen napp-it Version wieder gehen.
 
Zuletzt bearbeitet:
OpenIndiana Hipster 2019.05 ist da
Release notes: 2019.05 2019.05 Release notes - OpenIndiana - OpenIndiana Wiki

Editions:
-GUI/live für Server und Desktop use mit Mate 1.22 Desktop
-Text (am Besten für Server geeignet)
-Minimal (minimales Ilumos)

über OpenIndiana.
OpenIndiana ist eine Illumos Distribution (wie OmniOS, NexentaStor, SmartOS etc) die sich als Nachfolger von OpenSolaris sieht. Jedes halbe Jahr kommt ein getesteter Snapshot des aktuellen Illumos. Ein pkg update bringt dann jeweils das neueste Illumos.

OpenIndiana hat ein recht umfangreiches Repository mit Server und Desktop Apps Das ist anders als bei OmniOS das strikt auf Storage Minimalismus (= Stabilität) getrimmt ist. Das aktuelle OmniOS 151030 long term stable friert den aktuellen Illumos Stand ein und liefert für die nächsten 2 Jahre nur Sicherheits und Bugfixes, keine neuen Features. Dazu gibt es keinen kommerziellen OI Support als Option wie bei OmniOS.

Bis auf OmniOS Extras wie LX zones und Bhyve ist OmniOS 151030 (Mai 2019) ziemlich ähnlich zu OpenIndiana 2019.05 text.
 
Zuletzt bearbeitet:
Habe 2 Probleme mit Nappit

Einmal spinnt die Prozentanzeige wie auf dem Screenshot zu sehen. Und der farbige Punkt hinter "Cap" verschwindet bei jedem Umschalten der Sekunde kurz und was links davon ist rückt dann nach rechts auf.
Benutze Firefox

2019-05-13.png

edit: jetzt grade sind die Probleme wieder verschwunden, ich werds mal beobachten weiter
 
Zuletzt bearbeitet:
Ja hallöchen :)

bin neu hier in der ZFS welt und wollte mich vorher mal bei den Experten hier erkundigen , wie es denn heute so üblich ist einen "fileserver" aufzubauen.


Aktueller fileserver läuft mit einem Adaptec Controller im Raid 5 unter Windows Server. Das volume wird per SMB freigegeben. denke das ist bissl "out"

da ich nun einen neuen server bekommen habe (HPe DL60 Gen9 e5 2607V3 64GB DDR4 Ecc),will ich meinen windows server ablösen.

ich hätte mir das ganze folgendermaßen vorgestellt.

Freenas auf 1 ssd installieren. in den anderen 3 Käfigen dann die 2 tb hdd´s als Raidz
das ganze dann per SMB wieder an meine Windows clients freigeben / in der Active Directory freigeben.


jetzt meine frage: wenn ich das Freenas aufs blech installiere , hab ich da energiesparmeschanismen? also nicht hdd slowdown sonder zB:Package State c6/7 ,ASPM
C1e usw..???

das 2 Szenario wäre das Freenas auf Windows Server zu Virtualisieren , die HDDs einzeln durch reichen und dann ein raidz anlegen.

habe einen ersten test gemacht , und habe 2x wd red und 1x 500gb Samsung (uralt) via Hyper-v durchgereicht. Ergebnis: war sogar etwas schneller als mein Hardware Raid5 102/107 MB/s via Lan (1Gbe). bei den kleineren Dateien waren Welten zwischen dem ZFS und dem Hardware raid !!!


ich hoffe ich frage nicht im falschen forum

Grüße
 
Zum Energie-Sparen kann ich nichts sagen.

Für eine reine FreeNAS Installation reicht auch ein USB Stick aus. M.w.n. lädt FreeNAS sich zu Anfang einmal in den Arbeitsspeicher und schreibt dann auf den Stick nur noch Logs etc...Meine zwei 5€ USB Sticks haben 6 jahre durchgehalten, bevor sie dann durch Virtualisierung überflüssig wurden. Für diesen Fall also, dass du NUR FreeNAS installierst, kannst du dir die SSD also sparen (da ist FreeNAS wirklich hervorragend, kannst auch mehrere Sticks anstecken - falls einer abschmiert, fängt der nächste es auf usw. usf.).

Virtualisieren habe ich nun unter ESXI gemacht. Meinen ehemaligen Raid-Controller im IT Mode geflasht und durchgereicht und klappt perfekt. Leistung satt und vollkommen problemlos. Nur musst du natürlich sehr vorsichtig sein, dass man sich das RaidZ nicht zerschießt, wenn man unbedacht / durch ein Update Änderungen vornimmt.
 
Das hat mit ZFS zwar nur begrenzt zu tun, aber für das ZFS-RAID1 habe ich ashift=12 angegeben im Glauben, dass es sich bei meinen Crucial MX500 SSDs (zwei Stück gleichzeitig bestellt) um Platten mit einer physikalischen Sektorgröße von 4096Byte handelt. Nun scheint die eine trotz gleicher Revision eine physikalische Sektorgröße von 512B, die andere von 4096B zu haben.
Habt ihr dafür eine kluge Erklärung?

Code:
root@seu-proxmox-a:~# cat /etc/debian_version
9.9
root@seu-proxmox-a:~#
root@seu-proxmox-a:~#
root@seu-proxmox-a:~# lsblk -o NAME,PHY-SEC,LOG-SEC,MODEL,SERIAL,REV | grep -E 'sd(a|c) '
sda                 512     512 CT500MX500SSD1   1840E1D0D0E4     022
sdc                4096     512 CT500MX500SSD1   1840E1D0D17C     022
root@seu-proxmox-a:~#
root@seu-proxmox-a:~#
root@seu-proxmox-a:~#
root@seu-proxmox-a:~# hdparm -I /dev/sda | head -n25

/dev/sda:

ATA device, with non-removable media
        Model Number:       CT500MX500SSD1
        Serial Number:      1840E1D0D0E4
        Firmware Revision:  M3CR022
        Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
        Used: unknown (minor revision code 0x006d)
        Supported: 10 9 8 7 6 5
        Likely used: 10
Configuration:
        Logical         max     current
        cylinders       16383   0
        heads           16      0
        sectors/track   63      0
        --
        LBA    user addressable sectors:   268435455
        LBA48  user addressable sectors:   976773168
        Logical  Sector size:                   512 bytes
        Physical Sector size:                   512 bytes
        Logical Sector-0 offset:                  0 bytes
        device size with M = 1024*1024:      476940 MBytes
        device size with M = 1000*1000:      500107 MBytes (500 GB)
root@seu-proxmox-a:~#
root@seu-proxmox-a:~#
root@seu-proxmox-a:~#
root@seu-proxmox-a:~#
root@seu-proxmox-a:~# hdparm -I /dev/sdc | head -n25

/dev/sdc:

ATA device, with non-removable media
        Model Number:       CT500MX500SSD1
        Serial Number:      1840E1D0D17C
        Firmware Revision:  M3CR022
        Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
        Used: unknown (minor revision code 0x006d)
        Supported: 10 9 8 7 6 5
        Likely used: 10
Configuration:
        Logical         max     current
        cylinders       16383   0
        heads           16      0
        sectors/track   63      0
        --
        LBA    user addressable sectors:   268435455
        LBA48  user addressable sectors:   976773168
        Logical  Sector size:                   512 bytes
        Physical Sector size:                  4096 bytes
        Logical Sector-0 offset:                  0 bytes
        device size with M = 1024*1024:      476940 MBytes
        device size with M = 1000*1000:      500107 MBytes (500 GB)
 
Intern arbeiten die wahrscheinlich sogar mit 8k, 512b ist sicher falsch.
Aus Hardware - OpenZFS :

As of 2017, NAND-flash SSDs are tuned for 4096-byte IOs. Matching the flash page size is unnecessary and ashift=12 is usually the correct choice. Public documentation on flash page size is also nearly non-existent.

cu
 
Zum Energie-Sparen kann ich nichts sagen.

Für eine reine FreeNAS Installation reicht auch ein USB Stick aus. M.w.n. lädt FreeNAS sich zu Anfang einmal in den Arbeitsspeicher und schreibt dann auf den Stick nur noch Logs etc...Meine zwei 5€ USB Sticks haben 6 jahre durchgehalten, bevor sie dann durch Virtualisierung überflüssig wurden. Für diesen Fall also, dass du NUR FreeNAS installierst, kannst du dir die SSD also sparen (da ist FreeNAS wirklich hervorragend, kannst auch mehrere Sticks anstecken - falls einer abschmiert, fängt der nächste es auf usw. usf.).

Virtualisieren habe ich nun unter ESXI gemacht. Meinen ehemaligen Raid-Controller im IT Mode geflasht und durchgereicht und klappt perfekt. Leistung satt und vollkommen problemlos. Nur musst du natürlich sehr vorsichtig sein, dass man sich das RaidZ nicht zerschießt, wenn man unbedacht / durch ein Update Änderungen vornimmt.

/var und /tmp dann aber dringend auslagern! Mein SLC USB-Stick war nach einem Jahr FreeNAS kaputt.
 
Hallo,

ich setzte einen ZFS Storage unter Napp-IT als Backup Target unter Veeam ein. Nun möchte ich den Server nicht 24/7 laufen lassen, wenn ich ihn nur ein halbe Stunde für ein inkrementelles Backup brauche.
Gibt es irgendwie die Möglichkeit den Server von einem Windows Server über eine *.bat Datei (Before the job und After the job scripts in Veeam) zu starten und herunterzufahren?

MfG
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh