[Sammelthread] ZFS Stammtisch

900P,905P bzw. die Enterprise-Versionen DC-P4800X/4801X. Die kleinen Cache-SSDs mit 16 oder 32GB kannste dafür vergessen.

Die WD ist 3D TLC Flash mit seinen Nachteilen, die Optanes brauchen kein GC und kein Trim. Letzteres ist sogar eher schädlich im Enterprise-Bereich, da es die Latenzen erhöht.
Die Latenzen der Optanes liegen lt. Datenblatt fast bei einem Drittel der WD. Und für ZFS-SLOGs ist wichtig, dass es bei kurzen Queues möglichst kurze Antwortzeiten gibt. Latenzen sind da wichtiger als nackte IOPS.

Die schnelleren Optanes sind derzeit dieeee idealen Slogs und Cache-Devices für ZFS.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hmm. Die Enterprise-Versionen 4800X/4801X sind derzeit kaum lieferbar. Die 4800er sind meist mit U.2, womit ich wieder Adapter besorgen müsste und des weiteren sind die auch Schweine-Teuer.

4801X mit 100Gb wäre im Budget gewesen, ist aber ebenfalls nicht lieferbar. Die 900P/905P haben kein Power-Loss-Protection, was widerum egal wäre da USV, aber ich will da lieber auf Nummer sicher gehen und nichts dem Zufall überlassen... somit ist die Auswahl schon wieder relativ beschränkt.
 
Die 900P wurde in den ersten Datenblattversionen übrigens mit Powerloss beschrieben, die P4800X mit extended Powerloss. Und aufeinmal ist das Feature bei der 900P nicht mehr erwähnt worden. Die Optanes haben und brauchen auch keinen Ram-Cache.
Jetzt kannst Du über die Gründe von Intel nachsinieren, warum das bei der 900P auf einmal nicht mehr angegeben wurde. Und ob sies hat oder nicht. Ob da mit einer Firmware evtl. was deaktiviert (werden konnte) oder nicht.
Viel passieren kann auch mit der 900P, die mutmasslich auf dem gleichen Design wie die P4800X beruhen dürfte, vermutlich nicht.

Unternehmen sollte natürlich die DC-Version mit der garantierten Powerloss nehmen, aber fürs Homelab dürfte man meiner Meinung nach mit der 900P ausgezeichnet und relativ sicher fahren. Und potentiell mit der 905P auch.
Ne USV hab ich eh davor, weil ich die Wahrscheinlichkeit von Verlust nicht geschriebener Daten bei nonsync-Datasets (und da können ja ggf. Gigabytes im Ram noch warten) sowieso verringern wollte.
 
Zuletzt bearbeitet:
Die 900P wurde in den ersten Datenblattversionen übrigens mit Powerloss beschrieben, die P4800X mit extended Powerloss. Und aufeinmal ist das Feature bei der 900P nicht mehr erwähnt worden. Die Optanes haben und brauchen auch keinen Ram-Cache.
Jetzt kannst Du über die Gründe von Intel nachsinieren, warum das bei der 900P auf einmal nicht mehr angegeben wurde. Und ob sies hat oder nicht. Ob da mit einer Firmware evtl. was deaktiviert (werden konnte) oder nicht.
Viel passieren kann auch mit der 900P, die mutmasslich auf dem gleichen Design wie die P4800X beruhen dürfte, vermutlich nicht.

Unternehmen sollte natürlich die DC-Version mit der garantierten Powerloss nehmen, aber fürs Homelab dürfte man meiner Meinung nach mit der 900P ausgezeichnet und relativ sicher fahren. Und potentiell mit der 905P auch.
Ne USV hab ich eh davor, weil ich die Wahrscheinlichkeit von Verlust nicht geschriebener Daten bei nonsync-Datasets (und da können ja ggf. Gigabytes im Ram noch warten) sowieso verringern wollte.

Habe jetzt doch noch einen Lieferanten gefunden der mir die 4801X mit 100Gb besorgen kann. Bin gespannt.

Sollte man dann die komplette Kapazität als SLOG anlegen oder lieber partitionieren?

Anlegen dann mit:

Code:
zpool add POOL log /dev/sd(x)

?
 
Eine 4801 Optane als Slog wird durch zusätzliche Last relative wenig ausgebremst.
Da ein Slog nur ca 10GB bei Defaulteinstellung verbraucht (10%RAM, max 4GB)
könnte man sich schon überlegen eine zweite Partition als L2Arc zu nutzen.

Generell gilt aber immer, keep it simple.
Mehrere Partitionen/ Funktionen weicht von diesem Grundprinzip ab.
Bei Ausfall einer derartigen Platte macht man in Hektik gerne mal was falsch.
 
So gewonnen so zerronnen. Die 4801X ist maximal erst in 15-20 Werktagen lieferbar und selbst dann nicht sicher.

Die WD SSDC 530 und 300 kann ich auch vergessen. Die haben Dual-Port-SAS. Habe leider noch Single-Port. Kommt also auch nicht in Frage. Im SLC-Bereich gibt es leider nicht mehr zu bieten mit PowerLoss Protection. Dann würden die 900p, 905p und eventuell die M15 in den Fokus rücken. Was ist von der M15 zu halten?

Intel Optane Memory M15 64GB, M.2 2280 ab Preisvergleich Geizhals Deutschland
 
Auch eine Dualport SAS kann man an Singleport anschließen.
Man hat dann halt 1 x 12G statt 2 x 12G und kein High Availability.

Die SS530 wäre die Datacenter Alternative zur 4801.
Etwas langsamer (Flash halt) dafür Hot-Plug.
 
Kann mir mal jemand kurz auf die Sprünge helfen, wo kann ich das napp-it barebone Image finden?
 
Auch eine Dualport SAS kann man an Singleport anschließen.
Man hat dann halt 1 x 12G statt 2 x 12G und kein High Availability.

Die SS530 wäre die Datacenter Alternative zur 4801.
Etwas langsamer (Flash halt) dafür Hot-Plug.

Ahh. Ok. Wusste ich nicht. Das mit dem Dual-Port ist schon ein verdammt nettes Feature. Habe mich darüber etwas belesen. Danke.

Habe jetzt dann auch einfach mal eine bestellt und werde es ausprobieren. Zurzeit ist brauchbarer SLC nicht gerade günstig und schwer zu bekommen.
 
SLC ist wohl out und die Vorbehalte gegen TLC sind wohl auch überholt.

Die DC SS 530 ist TLC.
Hat aber 2x12G SAS, bis zu 320000 write iops (4k), 26us Latenz und bis zu 10 Drive Writes per Day und ist damit eine der schnellsten SSD.

https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/product/data-center-drives/ultrastar-ssd-sas-series/data-sheet-ultrastar-dc-ss530.pdf

Erst die Optane mit höherer Kapazität übertreffen das mit ca 500000 iops und 10 us Latenz. Die 4801-100 GB übertrifft das noch nicht wirklich.
 
Zuletzt bearbeitet:
900P,905P bzw. die Enterprise-Versionen DC-P4800X/4801X. Die kleinen Cache-SSDs mit 16 oder 32GB kannste dafür vergessen.
[...]Die schnelleren Optanes sind derzeit dieeee idealen Slogs und Cache-Devices für ZFS.

Wo hört den der billige Cachecrap auf, und wo fangen die "guten" Optanes an? Für 40€ geb ich mir den Spaß im Heimserverchen, für 400€ nicht...
 
Die günstigste Optane die es meiner Meinung ( und auch anderer ^^) nach Wert ist, ist diese
Intel Optane SSD DC P4801X 100GB, M.2 ab Preisvergleich Geizhals Deutschland
Intel Optane SSD DC P4801X 100GB, U.2 ab Preisvergleich Geizhals Deutschland

Wird u.a auch von STH als SLOG empfohlen.

Von der M.2 Version hatte ich unter anderem auch die ganze Zeit gesprochen und wollte die auch haben. Derzeit nirgends zu bekommen. Lieferzeiten von 15-20 Tagen.

U.2-Variante sieht Liefersituation besser aus. Problem ist aber das ich die nicht in meinem 19"-Chassis unterbekomme. Da müsste ich wieder rumfrickeln um die Kabel zu verlegen, dass stört mich gewaltig.

Ich werde jetzt die WD DC 530 verwenden und mal testen wie die Performance mit einem einfachen Stripe Log Device aussieht. Sollte das in Ordnung sein, kommt eventuell noch eine zweite als Mirror später dazu.
 
Bin jetzt in den entscheidenden Schritten der Fehlersuche und konnte paar Sachen klären:

Das ich auf einen Container mit SMB nur mit 82MB/s eine 1GB-File hochschieben konnte, lag nicht am ZFS. Es lag wohl eher an dem Rechner mit dem ich es hochgeschoben habe. Ich verwende Linux Mint und das scheint nicht wirklich performant bei Netzwerkfreigaben mit SMB zu sein. Habe es dann nochmal mit einem Windows-Client probiert und da habe ich ~117MB/s. Passt also. Habe es auch auf dem Container, als auch auf dem Proxmox-Host, mit bmon überprüft.

Kann man also abhaken.

Die WD DC 530 habe ich jetzt mit einer 10Gb-Partition vergeben und als SLOG zugewiesen. Die Frage ist, wie man am besten einen Benchmark anlegt um valide und vor allem vergleichbare Ergebnisse zu bekommen?

Mein Werkzeug war immer fio. Aber da führt irgendwie jeder das Teil mit anderen Optionen aus und man bekommt irgendwie keine vergleichbaren Werte. Habe jetzt mal folgende Benches durchgeführt:

Code:
fio --name=/rpool/testfile --ioengine=libaio --iodepth=32 --rw=write --bs=4k --direct=1 --size=2G --numjobs=1 --group_reporting
/rpool/testfile: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][w=392MiB/s][w=100k IOPS][eta 00m:00s] 
/rpool/testfile: (groupid=0, jobs=1): err= 0: pid=1363: Thu Sep 19 11:22:16 2019
  write: IOPS=107k, BW=418MiB/s (439MB/s)(2048MiB/4896msec); 0 zone resets
    slat (usec): min=4, max=27764, avg= 8.12, stdev=55.14
    clat (nsec): min=1955, max=28922k, avg=290187.52, stdev=327487.85
     lat (usec): min=8, max=28931, avg=298.41, stdev=332.93
    clat percentiles (usec):
     |  1.00th=[  208],  5.00th=[  223], 10.00th=[  231], 20.00th=[  233],
     | 30.00th=[  251], 40.00th=[  253], 50.00th=[  255], 60.00th=[  273],
     | 70.00th=[  285], 80.00th=[  310], 90.00th=[  383], 95.00th=[  437],
     | 99.00th=[  578], 99.50th=[  742], 99.90th=[ 1418], 99.95th=[ 3556],
     | 99.99th=[20841]
   bw (  KiB/s): min=347856, max=501760, per=100.00%, avg=436962.44, stdev=53407.20, samples=9
   iops        : min=86964, max=125440, avg=109240.78, stdev=13352.01, samples=9
  lat (usec)   : 2=0.01%, 10=0.01%, 20=0.01%, 50=0.01%, 100=0.01%
  lat (usec)   : 250=27.64%, 500=70.74%, 750=1.15%, 1000=0.33%
  lat (msec)   : 2=0.08%, 4=0.03%, 10=0.02%, 20=0.01%, 50=0.01%
  cpu          : usr=16.26%, sys=79.67%, ctx=2230, majf=0, minf=11
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,524288,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
  WRITE: bw=418MiB/s (439MB/s), 418MiB/s-418MiB/s (439MB/s-439MB/s), io=2048MiB (2147MB), run=4896-4896msec

2Gb-File mit durchschnittlich 439MB/s geschrieben und nochmal mit randwrite:

Code:
fio --name=/rpool/testfile --ioengine=libaio --iodepth=32 --rw=randwrite --bs=4k --direct=1 --size=2G --numjobs=1 --group_reporting
/rpool/testfile: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [w(1)][100.0%][w=190MiB/s][w=48.7k IOPS][eta 00m:00s]
/rpool/testfile: (groupid=0, jobs=1): err= 0: pid=10687: Thu Sep 19 11:25:27 2019
  write: IOPS=24.9k, BW=97.4MiB/s (102MB/s)(2048MiB/21029msec); 0 zone resets
    slat (usec): min=5, max=104046, avg=37.98, stdev=430.89
    clat (usec): min=2, max=109906, avg=1244.40, stdev=2620.29
     lat (usec): min=20, max=109993, avg=1282.54, stdev=2668.57
    clat percentiles (usec):
     |  1.00th=[   273],  5.00th=[   293], 10.00th=[   310], 20.00th=[   351],
     | 30.00th=[   437], 40.00th=[   611], 50.00th=[   824], 60.00th=[  1074],
     | 70.00th=[  1434], 80.00th=[  1926], 90.00th=[  2769], 95.00th=[  3228],
     | 99.00th=[  3949], 99.50th=[  4555], 99.90th=[ 14091], 99.95th=[102237],
     | 99.99th=[105382]
   bw (  KiB/s): min=31049, max=348120, per=99.47%, avg=99199.79, stdev=68892.97, samples=42
   iops        : min= 7762, max=87030, avg=24799.90, stdev=17223.26, samples=42
  lat (usec)   : 4=0.01%, 50=0.01%, 100=0.01%, 250=0.03%, 500=34.02%
  lat (usec)   : 750=12.67%, 1000=10.47%
  lat (msec)   : 2=23.88%, 4=18.04%, 10=0.76%, 20=0.08%, 50=0.01%
  lat (msec)   : 250=0.05%
  cpu          : usr=5.84%, sys=43.24%, ctx=109455, majf=0, minf=9
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,524288,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
  WRITE: bw=97.4MiB/s (102MB/s), 97.4MiB/s-97.4MiB/s (102MB/s-102MB/s), io=2048MiB (2147MB), run=21029-21029msec

Also randwrite mit durchschnittlich 102MB/s. Kann das jemand mal auf seinem System verifizieren? Damit man mal weiß ob das in Ordnung ist oder ob da immer noch was vermurkst?
 
Eine 900p/905p reicht privat dicke aus, PlP ist auch nicht ausgeschlossen, das es nicht auch mit den Consumer-Varianten funktioniert, siehe alte Intel Folien.
Habe selbst eine 900p mit 280 GB, die hab ich partitioniert auf 20 GB SLOG, Storage für die NAS-VM und den Rest als L2ARC.
 
Eine 900p/905p reicht privat dicke aus, PlP ist auch nicht ausgeschlossen, das es nicht auch mit den Consumer-Varianten funktioniert, siehe alte Intel Folien.
Habe selbst eine 900p mit 280 GB, die hab ich partitioniert auf 20 GB SLOG, Storage für die NAS-VM und den Rest als L2ARC.

Hast du mal auf deinem System einen Benchmark vollzogen und mal geschaut was der so an Durchsatz bei randwrite hatte? Würde mich mal brennend interessieren.
 
Hast du mal auf deinem System einen Benchmark vollzogen und mal geschaut was der so an Durchsatz bei randwrite hatte? Würde mich mal brennend interessieren.

Wird schwierig, da ZFS unter Solaris kein Direct I/O unterstützt. Aber soweit ich weiß werden die Pools, sofern man sie unter der napp-it Oberfläche anlegt, ohnehin die uncached Devices unter /dev/rdsk/ genommen.

Code:
/opt/csw/bin/fio -name=/saspool/testfile --ioengine=solarisaio --iodepth=32 --rw=randwrite --bs=4k --size=2G --numjobs=1 --group_reporting
/saspool/testfile: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=solarisaio, iodepth=32
fio-2.0.14
Starting 1 process
/saspool/testfile: Laying out IO file(s) (1 file(s) / 2048MB)
Jobs: 1 (f=1): [w] [100.0% done] [0K/333.8M/0K /s] [0 /85.5K/0  iops] [eta 00m:00s]
/saspool/testfile: (groupid=0, jobs=1): err= 0: pid=20457: Thu Sep 19 16:56:12 2019
  write: io=2048.0MB, bw=159552KB/s, iops=39888 , runt= 13144msec
    slat (usec): min=1 , max=2570 , avg= 9.26, stdev=12.76
    clat (usec): min=1 , max=49570 , avg=790.49, stdev=2105.74
     lat (usec): min=23 , max=49574 , avg=799.75, stdev=2106.61
    clat percentiles (usec):
     |  1.00th=[   56],  5.00th=[  173], 10.00th=[  326], 20.00th=[  350],
     | 30.00th=[  358], 40.00th=[  362], 50.00th=[  370], 60.00th=[  378],
     | 70.00th=[  386], 80.00th=[  426], 90.00th=[  596], 95.00th=[ 1020],
     | 99.00th=[10176], 99.50th=[10432], 99.90th=[20096], 99.95th=[20352],
     | 99.99th=[30336]
    bw (KB/s)  : min=11224, max=343264, per=98.78%, avg=157600.69, stdev=139830.01
    lat (usec) : 2=0.01%, 4=0.01%, 20=0.01%, 50=0.70%, 100=2.12%
    lat (usec) : 250=4.16%, 500=79.42%, 750=6.70%, 1000=1.82%
    lat (msec) : 2=0.99%, 4=0.27%, 10=1.84%, 20=1.82%, 50=0.15%
  cpu          : usr=81.01%, sys=137.91%, ctx=627040, majf=0, minf=0
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=0/d=524288, short=r=0/w=0/d=0/opt/csw/bin/fio -name=/saspool/testfile --ioengine=solarisaio --iodepth=32 --rw=randwrite --bs=4k --size=2G --numjobs=1 --group_reporting
/saspool/testfile: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=solarisaio, iodepth=32
fio-2.0.14
Starting 1 process
/saspool/testfile: Laying out IO file(s) (1 file(s) / 2048MB)
Jobs: 1 (f=1): [w] [100.0% done] [0K/333.8M/0K /s] [0 /85.5K/0  iops] [eta 00m:00s]
/saspool/testfile: (groupid=0, jobs=1): err= 0: pid=20457: Thu Sep 19 16:56:12 2019
  write: io=2048.0MB, bw=159552KB/s, iops=39888 , runt= 13144msec
    slat (usec): min=1 , max=2570 , avg= 9.26, stdev=12.76
    clat (usec): min=1 , max=49570 , avg=790.49, stdev=2105.74
     lat (usec): min=23 , max=49574 , avg=799.75, stdev=2106.61
    clat percentiles (usec):
     |  1.00th=[   56],  5.00th=[  173], 10.00th=[  326], 20.00th=[  350],
     | 30.00th=[  358], 40.00th=[  362], 50.00th=[  370], 60.00th=[  378],
     | 70.00th=[  386], 80.00th=[  426], 90.00th=[  596], 95.00th=[ 1020],
     | 99.00th=[10176], 99.50th=[10432], 99.90th=[20096], 99.95th=[20352],
     | 99.99th=[30336]
    bw (KB/s)  : min=11224, max=343264, per=98.78%, avg=157600.69, stdev=139830.01
    lat (usec) : 2=0.01%, 4=0.01%, 20=0.01%, 50=0.70%, 100=2.12%
    lat (usec) : 250=4.16%, 500=79.42%, 750=6.70%, 1000=1.82%
    lat (msec) : 2=0.99%, 4=0.27%, 10=1.84%, 20=1.82%, 50=0.15%
  cpu          : usr=81.01%, sys=137.91%, ctx=627040, majf=0, minf=0
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=0/d=524288, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=2048.0MB, aggrb=159552KB/s, minb=159552KB/s, maxb=159552KB/s, mint=13144msec, maxt=13144msec
 
Zuletzt bearbeitet:
Lt den Mails in Illumos-dev scheint es SSDs zu geben, bei denen Trim zu einem korrupten Dateisystem führt. Im Moment also nicht für einen produktiven Pool geeignet sondern nur zum Testen.

Die Diskussion dreht sich auch darum, wieder auf das (deutlich konservativere) Trim aus Nexenta zu setzen, das seit Jahren funktioniert. Da die Zol Variante eigentlich leistungsfähiger ist, geben die Devs dem aber tendenziell eher den Vorzug.

Als Zwischenlösung wird es wohl eine Blacklist oder Whitelist geben (wie bei Zol). Ist aber nicht der Weisheit letzter Schluß da man bei neuen SSDs dann immer eine Gefahr hat
 
Zuletzt bearbeitet:
Die bisherigen ZFS Raid-Trimmverfahren von Illumos-Nexenta und Free-BSD waren eigenständige Entwicklungen. Trim aus dem Open-ZFS Zweig von ZoL hat aber alle Vorraussetzungen um zum Standard für alle Open-ZFS Varianten zu werden.
 
Kann man eigentlich in der kostenlosen Variante von Oracle Solaris eine RAM-Disk anlegen und diese via SMB3 freigeben?
 
Ich habs nie probiert.

Prinzipiell sollte man eine Ramdisk anlegen können
Creating a ramdisk in Solaris 11 | Oracle, Unix and the world at large

Darauf dann ein ZFS Pool + Dateisystem erzeugen und für das Dateisystem SMB einschalten.


ps
Es gibt keine kostenlose Variante von Solaris.
Man kann Solaris kostenlos herunterladen und nichtkommerziell (z.B. für Demo und Development) nutzen.

Es handelt sich dabei um ein voll funktionsfähiges Solaris mit Software Repository.
Der Zugriff auf das Support Repository (mit Update/Bugfixes) geht aber nur mit Subscription.
 
Danke wie immer für die Informationen!

Ja, ich meinte die kostenfreie nichtkommerzielle Demo-Lizenz nicht eine OS-Version an sich, werde versuchen, mich in Zukunft sorgfältiger auszudrücken
 
Zuletzt bearbeitet:
Kann man eigentlich in der kostenlosen Variante von Oracle Solaris eine RAM-Disk anlegen und diese via SMB3 freigeben?

Ja, tmpfs filesystem erzeugen und mit dem share command freigeben, glaube du musst dafür kein zpool auf dem tmpfs device anlegen.
 
Die Solarish Systeme legen das rambasierte tmpfs (Ordner /tmp) automatisch an. Per default nutzt man aber unter Solarish den kernel/ZFS internen SMB Server. Bei dem ist SMB Sharing eine unabdingbare Eigenschaft eines ZFS Dateisystems. Ohne ZFS Dateisystem, kein SMB Sharing. Den Ordner /tmp kann man damit nicht freigeben.

Lediglich wenn man SAMBA nutzt geht das. SAMBA weiß nichts von ZFS sondern sieht nur einfache Ordner, Hat in dem Fall einen Vorteil, ist oft dafür langsamer, unterstützt nicht in dem Maß Windows ntfs Rechte und SMB Gruppen und ZFS Snaps als Windows vorherige VBersion geht nicht so einfach und universell.
 
Mal ne Frage: Ist es empfehlenswert eine USB Ethernetkarte/Stick zu benutzen als Management Interface? Will dafür keinen PCIE Steckplatz verschwenden und die Onboard Nics für ServerDienste benutzen.
 
Hi

Was bedeutet diese Meldung für mich?:

KeyFehlerNapp-it.PNG
 
Napp-it Pro ist an eine Machine ID gebunden. Ändert sich die Hardware oder die Machine ID sonstwie, muss die Lizenz für die neue Machine ID online getauscht werden, napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana and Solaris : Extensions

Läuft die Pro Lizenz ab, kann man alternativ auf napp-it Free zurückgehen.

In einer früheren Pro Version konnte es passieren, dass eine Machine fälschlicherweise deaktiviert wurde. Dann den alten Key (Submenü oldkeys) erneut registrieren und auf die aktuelle 19.06 Pro updaten.
 
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