[Sammelthread] ZFS Stammtisch

[docsnydor]

Irgendwie fühlt sich Windows für mich so "falsch" an. Ich hätte sogar Windows LTSC oder Server (2022) im Angebot. Wäre natürlich super bequem, aber ich traue der Sache nicht. Bauchgefühl... Auf der anderen Seite läuft Windows als Hypervisor (in meinem Fall 2012R2) wirklich gut und unauffällig.
Was würdest du unter Windows empfehlen, um die Daten zu replizieren? Batch-Datei über SMB und via "Geplante Tasks" triggern?
Server hat jetzt 16GB RAM, Windows könnte ich auf eine kleine SSD installieren...

 

[gea]

Ich nehm gerne robocopy um Ordner zu syncronisieren. Ist ultra robust und bei Windows dabei. Kann man direkt mit Optionen aufrufen oder in einer Batchdatei. Als Alternative zu ZFS kann man unter Windows (größere Varianten) ReFS nehmen. Das hat die beiden wichtigsten ZFS Datensicherheits Features Copy on Write und Prüfsummen auf Metadaten und auf Wunsch auch Daten. ZFS würde unter Windows zusätzlich viel einfacheres Raid Management, Echtzeit Dedup, Compress und Verschlüssellung per Dateisystem, erweiterbares Raid-Z, sicheres sync write und flexible Hybrid Pools (Platten+SSD) bieten.

 

[sandreas]

Was würdest du unter Windows empfehlen, um die Daten zu replizieren?

Geht es nur um ein vollständiges Replikat oder um eine Snapshot basierte Backup-Lösung?

Ich verwende für einen einfachen Dateisystemsync gerne `rclone` - das ist ein kleines Kommandozeilentool ähnlich zu `rsync`, aber da es in go geschrieben ist, ist das bloß eine binary / exe-Datei und es funktioniert auf allen Betriebssystemen. Alternativ ist `syncthing` sehr schön, aber für einen einfachen Dateisync fast schon overkill.

Wenn du snapshots mit der Option auf zurückrollen brauchst, würde ich `restic` empfehlen. Das legt ein verschlüsseltes Backup-Repository an, was blockweise dedupliziert und für jeden Backup-Vorgang einen Snapshot enthält, den man wieder herstellen kann. Sehr mächtiges Tool.

 

[Bzzz]

Zwei Optane 1600 -118G sind das schnellste was man überhaupt haben kann, für größere sbs aber oft zu klein Hängt sehr von der Art der Daten ab.

Bitch Please, wie man neudeutsch so sagt

Optane kam hier im Thread ja bisher nur in den "Normalo"varianten vor, nicht aber als NVDIMM/PMem/DCPMM. Für 35,50€ bin ich mit dem Ergebnis knapp zufrieden

=

 

[docsnydor]

Danke @sandreas und @gea
Ich werde wohl Windows mal eine Chance geben ;-)

 

[gea]

Danke @sandreas und @gea
Ich werde wohl Windows mal eine Chance geben ;-)

Ich würde dann Open-ZFS für Windows rc4 installieren.
Die aktuelle rc5 zeigt zfs Pools jetzt als zfs an und nicht mehr ntfs.

Durch die Umstellung gibt es ein Problem, den mountstatus z.B. mit zfs get mounted anzuzeigen. Die rc5 sollte man daher nicht nehmen. In der rc6 die bereits angekündigt isr, soll das behoben werden.

Die rc6 Preview sollte auch gehen
OpenZFSOnWindows-debug-.99-149-gf9ec771f74.exe

Beitrag automatisch zusammengeführt: 07.06.2024

Release Notes for OmniOSce v11 r151050
r151050d (2024-05-31)

Release Notes

illumos based server OS with ZFS, DTrace, Crossbow, SMF, Bhyve, KVM and Linux zone support

omnios.org

Weekly release for w/c 27th of May 2024.

This update requires a reboot

Security Fixes

• ncurses has been updated to version 6.4.20240309.

Other Changes

• The algorithm for picking a hot spare to use in a ZFS pool has been updated so that spares are first sorted in ascending size order. This means that the smallest appropriate usable spare will be selected.
• Added support for Open File Descriptor (OFD) locks to the lx zone brand in order to support systemd v254 and newer.
• The bhyve emulated USB tablet device which is used for mouse support under VNC has been fixed so that it works properly with Linux guests running newer kernel versions.
• If given a very large input (2^29 bytes or more), the illumos crypto code could previously produce incorrect SHA1 hashes. This has been resolved in this update.

Beitrag automatisch zusammengeführt: 07.06.2024

Bitch Please, wie man neudeutsch so sagt

Optane kam hier im Thread ja bisher nur in den "Normalo"varianten vor, nicht aber als NVDIMM/PMem/DCPMM. Für 35,50€ bin ich mit dem Ergebnis knapp zufrieden
=

Ich nehme an das ist die sync write Performance und da sind 424 MB/s extrem gute Werte. Das ist immerhin das was man z.B. per SMB ohne viel Tuning im 10G Netz hat.

Nur zum Vergleich
Eine mechanische Platte liegt bei sync write gerne unter 10 MB/s, eine normale SSD bei 50-150 MB/s

 

[Bzzz]

fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=4k --size=4g --numjobs=1 --iodepth=1 --runtime=60 --time_based --end_fsync=1 --filename=ssd-test.file

auf ext4:

random-write: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=posixaio, iodepth=1
fio-3.36
Starting 1 process
random-write: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [w(1)][100.0%][w=149MiB/s][w=38.2k IOPS][eta 00m:00s]
random-write: (groupid=0, jobs=1): err= 0: pid=5880: Fri Jun  7 20:55:13 2024
  write: IOPS=52.8k, BW=206MiB/s (216MB/s)(12.2GiB/60512msec); 0 zone resets
    slat (nsec): min=416, max=195728, avg=1172.49, stdev=364.64
    clat (nsec): min=658, max=1094.0k, avg=8299.65, stdev=2580.62
     lat (usec): min=5, max=1104, avg= 9.47, stdev= 2.73
    clat percentiles (nsec):
     |  1.00th=[ 6880],  5.00th=[ 7136], 10.00th=[ 7264], 20.00th=[ 7456],
     | 30.00th=[ 7520], 40.00th=[ 7648], 50.00th=[ 7776], 60.00th=[ 7968],
     | 70.00th=[ 8160], 80.00th=[ 8512], 90.00th=[ 9536], 95.00th=[11200],
     | 99.00th=[16512], 99.50th=[18816], 99.90th=[26240], 99.95th=[41216],
     | 99.99th=[56064]
   bw (  KiB/s): min=79376, max=456912, per=100.00%, avg=388387.45, stdev=77624.60, samples=65
   iops        : min=19844, max=114228, avg=97096.89, stdev=19406.10, samples=65
  lat (nsec)   : 750=0.01%
  lat (usec)   : 4=0.01%, 10=91.73%, 20=7.88%, 50=0.37%, 100=0.01%
  lat (usec)   : 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
  lat (msec)   : 2=0.01%
  cpu          : usr=7.92%, sys=54.15%, ctx=3240267, majf=0, minf=22
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.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.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,3194757,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=206MiB/s (216MB/s), 206MiB/s-206MiB/s (216MB/s-216MB/s), io=12.2GiB (13.1GB), run=60512-60512msec

Disk stats (read/write):
  pmem0: ios=0/0, sectors=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%

und auf zfs mit zfs-2.2.2-0ubuntu9 / zfs-kmod-2.2.2-0ubuntu9,
zpool status
pool: pmem
state: ONLINE
config:

NAME STATE READ WRITE CKSUM
pmem ONLINE 0 0 0
pmem0 ONLINE 0 0 0

errors: No known data errors

...mit Standardeinstellungen, d.h. compression=on

random-write: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=posixaio, iodepth=1
fio-3.36
Starting 1 process
random-write: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [w(1)][100.0%][w=56.0MiB/s][w=14.3k IOPS][eta 00m:00s]
random-write: (groupid=0, jobs=1): err= 0: pid=7917: Fri Jun  7 21:00:15 2024
  write: IOPS=14.8k, BW=57.9MiB/s (60.7MB/s)(3484MiB/60181msec); 0 zone resets
    slat (nsec): min=389, max=5553.5k, avg=2619.91, stdev=16475.75
    clat (nsec): min=361, max=23951k, avg=63079.08, stdev=127597.44
     lat (usec): min=10, max=23954, avg=65.70, stdev=129.98
    clat percentiles (usec):
     |  1.00th=[   13],  5.00th=[   19], 10.00th=[   20], 20.00th=[   39],
     | 30.00th=[   43], 40.00th=[   47], 50.00th=[   49], 60.00th=[   52],
     | 70.00th=[   57], 80.00th=[   62], 90.00th=[   90], 95.00th=[  139],
     | 99.00th=[  347], 99.50th=[  529], 99.90th=[ 1336], 99.95th=[ 2212],
     | 99.99th=[ 4555]
   bw (  KiB/s): min=41568, max=86112, per=100.00%, avg=59502.61, stdev=9062.30, samples=119
   iops        : min=10392, max=21528, avg=14875.61, stdev=2265.57, samples=119
  lat (nsec)   : 500=0.01%, 750=0.01%, 1000=0.01%
  lat (usec)   : 2=0.01%, 4=0.01%, 10=0.01%, 20=10.52%, 50=43.54%
  lat (usec)   : 100=37.45%, 250=6.75%, 500=1.14%, 750=0.32%, 1000=0.08%
  lat (msec)   : 2=0.11%, 4=0.04%, 10=0.01%, 20=0.01%, 50=0.01%
  cpu          : usr=7.29%, sys=7.65%, ctx=908956, majf=0, minf=24
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.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.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,891952,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=57.9MiB/s (60.7MB/s), 57.9MiB/s-57.9MiB/s (60.7MB/s-60.7MB/s), io=3484MiB (3653MB), run=60181-60181msec

und compression=off:

random-write: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=posixaio, iodepth=1
fio-3.36
Starting 1 process
random-write: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [w(1)][100.0%][w=32.5MiB/s][w=8307 IOPS][eta 00m:00s]
random-write: (groupid=0, jobs=1): err= 0: pid=13135: Fri Jun  7 22:06:54 2024
  write: IOPS=8437, BW=33.0MiB/s (34.6MB/s)(1998MiB/60606msec); 0 zone resets
    slat (nsec): min=459, max=1854.8k, avg=6923.91, stdev=13613.65
    clat (nsec): min=380, max=7709.9k, avg=106181.25, stdev=135376.03
     lat (usec): min=11, max=7712, avg=113.11, stdev=138.95
    clat percentiles (usec):
     |  1.00th=[   19],  5.00th=[   24], 10.00th=[   31], 20.00th=[   42],
     | 30.00th=[   51], 40.00th=[   59], 50.00th=[   69], 60.00th=[   80],
     | 70.00th=[   91], 80.00th=[  115], 90.00th=[  192], 95.00th=[  396],
     | 99.00th=[  693], 99.50th=[  758], 99.90th=[  930], 99.95th=[ 1221],
     | 99.99th=[ 2245]
   bw (  KiB/s): min=27264, max=49512, per=100.00%, avg=34165.16, stdev=3873.69, samples=119
   iops        : min= 6816, max=12378, avg=8541.26, stdev=968.39, samples=119
  lat (nsec)   : 500=0.01%, 750=0.01%, 1000=0.01%
  lat (usec)   : 2=0.01%, 4=0.01%, 10=0.02%, 20=2.03%, 50=27.62%
  lat (usec)   : 100=45.90%, 250=16.79%, 500=4.07%, 750=3.01%, 1000=0.47%
  lat (msec)   : 2=0.06%, 4=0.01%, 10=0.01%
  cpu          : usr=11.89%, sys=11.89%, ctx=513113, majf=0, minf=23
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.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.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,511365,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=33.0MiB/s (34.6MB/s), 33.0MiB/s-33.0MiB/s (34.6MB/s-34.6MB/s), io=1998MiB (2095MB), run=60606-60606msec

Heftig, wie die Performance mit ZFS leidet. Zusätzlicher Performancedrop mit compression=off ist reproduzierbar. CPU ist ein Xeon Silver 4215R.

Mit engine=sync sieht es so aus:
ext4:

random-write: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=sync, iodepth=1
fio-3.36
Starting 1 process
random-write: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [w(1)][100.0%][eta 00m:00s]                          
random-write: (groupid=0, jobs=1): err= 0: pid=14953: Fri Jun  7 22:22:26 2024
  write: IOPS=80.9k, BW=316MiB/s (332MB/s)(20.0GiB/64780msec); 0 zone resets
    clat (nsec): min=1213, max=222730, avg=1730.17, stdev=1385.04
     lat (nsec): min=1242, max=222805, avg=1761.14, stdev=1386.47
    clat percentiles (nsec):
     |  1.00th=[ 1320],  5.00th=[ 1416], 10.00th=[ 1464], 20.00th=[ 1512],
     | 30.00th=[ 1544], 40.00th=[ 1576], 50.00th=[ 1592], 60.00th=[ 1624],
     | 70.00th=[ 1656], 80.00th=[ 1720], 90.00th=[ 2128], 95.00th=[ 2576],
     | 99.00th=[ 2896], 99.50th=[ 3472], 99.90th=[ 6176], 99.95th=[36608],
     | 99.99th=[64768]
   bw (  MiB/s): min=  773, max= 1894, per=100.00%, avg=1638.40, stdev=375.63, samples=25
   iops        : min=198090, max=484896, avg=419430.32, stdev=96160.57, samples=25
  lat (usec)   : 2=89.22%, 4=10.51%, 10=0.19%, 20=0.03%, 50=0.03%
  lat (usec)   : 100=0.02%, 250=0.01%
  cpu          : usr=3.33%, sys=95.84%, ctx=8463, majf=0, minf=11
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.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.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,5242881,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=316MiB/s (332MB/s), 316MiB/s-316MiB/s (332MB/s-332MB/s), io=20.0GiB (21.5GB), run=64780-64780msec

Disk stats (read/write):
  pmem0: ios=0/0, sectors=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%

ZFS, compression=on:

fio --name=random-write --ioengine=sync --rw=randwrite --bs=4k --size=4g --numjobs=1 --iodepth=1 --runtime=60 --time_based --end_fsync=1
 --filename=ssd-test.file
random-write: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=sync, iodepth=1
fio-3.36
Starting 1 process
Jobs: 1 (f=1): [w(1)][100.0%][w=60.4MiB/s][w=15.5k IOPS][eta 00m:00s]
random-write: (groupid=0, jobs=1): err= 0: pid=13277: Fri Jun  7 22:15:15 2024
  write: IOPS=18.8k, BW=73.5MiB/s (77.1MB/s)(4441MiB/60430msec); 0 zone resets
    clat (usec): min=3, max=6955, avg=51.85, stdev=59.28
     lat (usec): min=3, max=6956, avg=51.93, stdev=59.31
    clat percentiles (usec):
     |  1.00th=[    5],  5.00th=[    5], 10.00th=[    6], 20.00th=[   27],
     | 30.00th=[   42], 40.00th=[   45], 50.00th=[   48], 60.00th=[   50],
     | 70.00th=[   53], 80.00th=[   58], 90.00th=[   95], 95.00th=[  122],
     | 99.00th=[  297], 99.50th=[  404], 99.90th=[  562], 99.95th=[  775],
     | 99.99th=[ 1467]
   bw (  KiB/s): min=61524, max=222720, per=100.00%, avg=75908.74, stdev=17648.19, samples=119
   iops        : min=15381, max=55682, avg=18977.16, stdev=4412.18, samples=119
  lat (usec)   : 4=0.23%, 10=17.84%, 20=1.81%, 50=42.85%, 100=27.80%
  lat (usec)   : 250=8.25%, 500=1.06%, 750=0.10%, 1000=0.02%
  lat (msec)   : 2=0.02%, 4=0.01%, 10=0.01%
  cpu          : usr=2.03%, sys=95.82%, ctx=5836, majf=0, minf=8
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.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.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,1136910,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=73.5MiB/s (77.1MB/s), 73.5MiB/s-73.5MiB/s (77.1MB/s-77.1MB/s), io=4441MiB (4657MB), run=60430-60430msec

ZFS, compression=off

Starting 1 process
Jobs: 1 (f=1): [F(1)][100.0%][w=248KiB/s][w=62 IOPS][eta 00m:00s]    
random-write: (groupid=0, jobs=1): err= 0: pid=13251: Fri Jun  7 22:14:00 2024
  write: IOPS=13.2k, BW=51.6MiB/s (54.1MB/s)(3159MiB/61254msec); 0 zone resets
    clat (usec): min=3, max=69083, avg=71.68, stdev=232.52
     lat (usec): min=3, max=69083, avg=71.87, stdev=232.65
    clat percentiles (usec):
     |  1.00th=[    6],  5.00th=[    6], 10.00th=[    6], 20.00th=[    7],
     | 30.00th=[   11], 40.00th=[   31], 50.00th=[   34], 60.00th=[   35],
     | 70.00th=[   38], 80.00th=[   49], 90.00th=[  161], 95.00th=[  412],
     | 99.00th=[  652], 99.50th=[  709], 99.90th=[  848], 99.95th=[ 1074],
     | 99.99th=[ 4228]
   bw (  KiB/s): min=36566, max=95624, per=100.00%, avg=53827.12, stdev=11516.32, samples=119
   iops        : min= 9141, max=23906, avg=13456.71, stdev=2879.16, samples=119
  lat (usec)   : 4=0.01%, 10=29.44%, 20=2.38%, 50=48.85%, 100=4.46%
  lat (usec)   : 250=7.10%, 500=4.31%, 750=3.18%, 1000=0.23%
  lat (msec)   : 2=0.03%, 4=0.01%, 10=0.01%, 20=0.01%, 50=0.01%
  lat (msec)   : 100=0.01%
  cpu          : usr=4.14%, sys=88.52%, ctx=24987, majf=0, minf=10
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.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.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,808724,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=51.6MiB/s (54.1MB/s), 51.6MiB/s-51.6MiB/s (54.1MB/s-54.1MB/s), io=3159MiB (3313MB), run=61254-61254msec

 

[gea]

Heftig, wie die Performance mit ZFS leidet. Zusätzlicher Performancedrop mit compression=off ist reproduzierbar. CPU ist ein Xeon Silver 4215R.

Ist zfs sync aktiviert?

Nur zur Erinnerung.
ZFS sync ist eine ganz spezielle ZFS Einstellung um Schreibaktionen zu protokollieren damit im Falle eines Absturzes fehlende aber bestätigte Schreibaktionen beim nächsten Reboot nachgeholt werden, quasi die BBU Funktion eines Hardwareraid in Software. Im Endeffekt hat das aber zur Folge, dass jedes Write zweimal passiert, einmal schnell als großes sequentielles Write über den RAM Schreibcache und einmal ganz langsam bei jedem Commit.

Das hat zunächst nichts mit ZFS zu tun sondern ist eine Frage wie man Datenverlust bei Stromausfall trotz schnellem Schreibcache vermeiden will. Bei ext4 ist das klar, da gibt es diese Sicherung nicht. Bei ZFS wird aber auch gerade überlegt, ob das sync write Konzept mit schnellen NVMe noch ideal ist oder ob nicht direct io ohne RAM Schreibpuffer nicht scnneller wäre (vermutlich ja)

Bei Hybrid Pools (Disks + NVMe) ist das ZFS Syncwrite Konzept mit Slog nach wie vor "state of the Art"

 

[Bzzz]

Stand auf "standard".
Mit sync=disabled und compression=on

fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=4k --size=4g --numjobs=1 --iodepth=1 --runtime=60 --time_based --end_fsync=1 --filename=ssd-test.file
random-write: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=posixaio, iodepth=1
fio-3.36
Starting 1 process
random-write: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [w(1)][100.0%][w=49.5MiB/s][w=12.7k IOPS][eta 00m:00s]
random-write: (groupid=0, jobs=1): err= 0: pid=16696: Fri Jun  7 23:47:21 2024
  write: IOPS=15.5k, BW=60.4MiB/s (63.3MB/s)(3623MiB/60001msec); 0 zone resets
    slat (nsec): min=426, max=5382.1k, avg=2653.21, stdev=17404.63
    clat (nsec): min=269, max=32131k, avg=60619.68, stdev=126484.36
     lat (usec): min=10, max=32146, avg=63.27, stdev=128.97
    clat percentiles (usec):
     |  1.00th=[   13],  5.00th=[   18], 10.00th=[   19], 20.00th=[   38],
     | 30.00th=[   42], 40.00th=[   45], 50.00th=[   48], 60.00th=[   51],
     | 70.00th=[   56], 80.00th=[   61], 90.00th=[   86], 95.00th=[  131],
     | 99.00th=[  338], 99.50th=[  529], 99.90th=[ 1287], 99.95th=[ 1991],
     | 99.99th=[ 4178]
   bw (  KiB/s): min=45704, max=90656, per=100.00%, avg=61971.38, stdev=10049.50, samples=119
   iops        : min=11426, max=22664, avg=15492.82, stdev=2512.37, samples=119
  lat (nsec)   : 500=0.01%, 750=0.02%, 1000=0.01%
  lat (usec)   : 2=0.01%, 4=0.01%, 10=0.01%, 20=13.53%, 50=43.85%
  lat (usec)   : 100=34.66%, 250=6.49%, 500=0.86%, 750=0.33%, 1000=0.08%
  lat (msec)   : 2=0.11%, 4=0.04%, 10=0.01%, 20=0.01%, 50=0.01%
  cpu          : usr=7.37%, sys=8.00%, ctx=947051, majf=0, minf=23
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.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.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,927420,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=60.4MiB/s (63.3MB/s), 60.4MiB/s-60.4MiB/s (63.3MB/s-63.3MB/s), io=3623MiB (3799MB), run=60001-60001msec

bzw.

fio --name=random-write --ioengine=sync --rw=randwrite --bs=4k --size=4g --numjobs=1 --iodepth=1 --runtime=60 --time_based --end_fsync=1 --filename=ssd-test.file
random-write: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=sync, iodepth=1
fio-3.36
Starting 1 process
Jobs: 1 (f=1): [w(1)][100.0%][w=63.6MiB/s][w=16.3k IOPS][eta 00m:00s]
random-write: (groupid=0, jobs=1): err= 0: pid=16749: Fri Jun  7 23:49:42 2024
  write: IOPS=18.3k, BW=71.6MiB/s (75.0MB/s)(4294MiB/60001msec); 0 zone resets
    clat (usec): min=3, max=8867, avg=53.59, stdev=59.61
     lat (usec): min=3, max=8867, avg=53.69, stdev=59.65
    clat percentiles (usec):
     |  1.00th=[    5],  5.00th=[    5], 10.00th=[    5], 20.00th=[   17],
     | 30.00th=[   44], 40.00th=[   47], 50.00th=[   49], 60.00th=[   51],
     | 70.00th=[   54], 80.00th=[   60], 90.00th=[  104], 95.00th=[  126],
     | 99.00th=[  318], 99.50th=[  412], 99.90th=[  562], 99.95th=[  758],
     | 99.99th=[ 1385]
   bw (  KiB/s): min=60383, max=200904, per=100.00%, avg=73391.97, stdev=16743.10, samples=119
   iops        : min=15095, max=50226, avg=18347.97, stdev=4185.83, samples=119
  lat (usec)   : 4=1.00%, 10=17.70%, 20=1.37%, 50=39.05%, 100=30.41%
  lat (usec)   : 250=9.16%, 500=1.16%, 750=0.10%, 1000=0.03%
  lat (msec)   : 2=0.02%, 4=0.01%, 10=0.01%
  cpu          : usr=2.09%, sys=95.85%, ctx=5781, majf=0, minf=10
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.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.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,1099248,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=71.6MiB/s (75.0MB/s), 71.6MiB/s-71.6MiB/s (75.0MB/s-75.0MB/s), io=4294MiB (4503MB), run=60001-60001msec

 

[gea]

Standard bedeuted dass das schreibende Programm selber entscheiden darf ob langsames/sicheres sync benutzt wird oder nicht. Will mans wissen, sync fest auf ein oder aus stellen. Will man nicht wissen, wie gut compress arbeitet sondern wie schnell das Storage ist, compress immer auf off stellen.

Bleibt natürlich dass ZFS Prüfsummen benutzt=mehr io,
bleibt auch ZFS Copy on Write. bei dem man um ein Byte in einem 1GB recsize Block zu ändern 1 GB lesen/schreiben muss. (oder halt kleinere recsize) anstatt nur das Byte zu überschreiben. (ok, immer 514B oder 4K weise). Ext oder ntfs ist da natürlich schneller, ist halt dafür kaputt wenn der Hund im falschen Moment das Stromkabel vom Rechner zieht,

Das ist halt der Preis den man bezahlen muss damit man kein defektes Dateisytem hat wenn der Rechner beim schreiben abstürzt. Erzähl mit jetzt keiner dass man dafür bei ext4 fschk hat und das bei ZFS fehlt..........(braucht man nicht)

ZFS ist die Antwort auf die Frage wie man Datenverlust konzeptionell vermeiden kann (außer bei defekter Hardware oder human error)

Frage:
Warum ist das Fahrrad schneller als mein Porsche?
Kein Problem (im freien Fall)

 

[Woozy]

Ich bin aktuell dabei meine beiden Server auf TrueNAS umzustellen, da meine aktuellen SMB-Shares unter Windows einfach abgeschafft werden sollen (EOL von W10 etc.). Bisher hat sich Server A immer auf Server B repliziert, ein ext. Backup mit ext. HDDs gab es ebenso und das würde ich auch grob gerne so Beibehalten. Bisher lief das OS auf einer m.2 SSD, das würde ich ebenso beibehalten - dieses Installieren auf USB sieht für mich einfach nicht sinnvoll aus.

Es werden keine Medien über die Server gestreamt, der Datenstand sind hauptsächlich Bilder und Videos vom Wandern, Dashcam-Aufnahmen und ebenso 3D-Modelle von Cults 3D und Patreon, die lokal Vorgehalten werden. Ebenso liegen Samples für Ableton auf den Geräten, diese werden aber zum Arbeiten für Gewöhnlich vorgefiltert und dann Lokal auf die WS kopiert um damit zu arbeiten. Die 4TB SSD die ohne RAID läuft wird meist als "Zwischenspeicher" genutzt bzw. für Daten die ich Zeitweise öfter brauche.

Hardware:
CPU: Intel i3 10100T
Board: B560M PRO VDH WIFI (Wifi, Onboard Audio etc. deaktiviert)
RAM: 4x 8GB DDR4 (Non ECC)
NIC: Intel X520 SFP+ mit 1x 10Gbit LC-LC

Aktuell habe ich 6x 10TB + 4x 12TB HDDs, bei denen ich noch Prüfen muss ob es eventuell SMR-Platten sind, hier. Ansprüche an Geschwindigkeit habe ich wenig bis gar keine, die 10Gbit-Anbindung der Server ist einfach nur aufgrund der vorhandenen Hardware entstanden und wird eigentlich / voraussichtlich NICHT benötigt. Die Platten laufen aktuell wie folgt:
- 2x 12TB HDD in Software-RAID 1
- 3x 10TB HDD in Software-RAID 5
- 1x 4TB SSD ohne RAID

Der neue Plan wäre:
- 2x 12TB HDD in RAID 1 oder RAID z1
- 3x 10TB HDD in RAID Z1
- 1x 4TB HDD ohne RAID

Die Probleme bzw. Rebuild von großen Platten kenne ich, in wie weit sich da die theoretischen Zahlen mit den realen Zahlen überein bringen lassen kenne ich ebenso. Ob der Plan von oben Sinnvoll ist weis ich nicht, weil a) das TrueNAS-Forum bis auf "Raid is no Backup", "It depends" und "Use Google and the Forum Search" absolut keine Antworten liefert.

Alle Clients im Haus sind via 2.5Gbit angeschlossen, absehbar (1-2 Jahre) werden 1-2 weitere Workstations von mir mit 10Gbit angebunden (weil es so ist ). Ebenso sehe ich bei der aktuellen Hardware das Problem, das ich bei 6x SATA gecapped bin außer ich baue noch einen m.2 auf SATA-Adapter ein, bei denen sich die Geister scheiden was Qualität angeht, alternativ könnte man über einen m.2 zu x4-Riser natürlich auch sinnvollere Hardware einsetzen - da gibt es dann ja auch wieder Diskussionen zwischen ASM1166 und JMB585.

Kurzum: Sinnvoller Plan oder nein?

 

[gea]

2 Platten im Z1 sind möglich aber relativ sinnfrei im Vergleich zu einem Mirror, der ist beim Lesen doppelt so schnell.

Wenn man nicht jedes TB braucht, würde ich 5 Platten im Z2 machen (30TB usable). Da können 2 beliebige Platten ausfallen. Die 4TB z.B. als Disaster Backup (Wechseleinschub oder USB) ist ok.

 

[HansBohne]

Hmmm kann das neue OpenZFS nicht erweitert werden? Keine Ahnugn bei welchen Konstellationen das geht. Aber vielleicht auch sinnvoll damit zu planen?

 

[gea]

Open-ZFS 2.2.3 Master kann Raid-Z Erweiterung.
Ist aber außer in der Windows rc meines Wissens noch nirgends dabei wenn mans nicht selber kompilieren will.

Wobei man bei kritischen Sachen nicht unbedingt erste/r sein muss. Es gibt nämlich keinen Weg zurück. Derzeitiges Open-ZFS egal ob BSD, Illumos oder Linux kann einen Pool nach Expansion nicht mehr importieren.

 

[millenniumpilot]

die neue TrueNAS Alpha 24.10.0 hat das schon drinnen und auf einem Testserver konnte ich damit ein Z1 schon um eine Platte erweitern. Hat soweit erst einmal funktioniert, Pool größer und vorher vorhandene Daten waren alle noch da.

 

[HansBohne]

Naja er kann ja trotzdem das auch mit aktuellem zfs so installieren dass wenn er irgendwann mal auf eine neuere zfs version > 2.2.2 upgraded das dann erweitern kann

Glaub auf youtube gibt es nen Video dass das seit jahren implementiert und von devs richtig gut getestet wurde

 

[you]

@gea - nappit 24.01d

So sollte es sein: siehe Bild "richtig.png". Und so ist es, wenn ich mich einlogge und ACC ausgeschaltet ist.

Schalte ich ACC ein, dann baut sich die Übersicht neu auf (immernoch korrekt). Aber, sobald, etwas verzögert, auch der rpool angezeigt wird, kommt es nach einem automatischen Refresh zu der folgenden, fehlerhaften Ansicht: siehe Bild "falsch.png" ... es sieht so aus, als ob in der Tabelle Alles eins nach rechts verschoben wird

Schalte ich ACC wieder aus, ist die Anzeige wieder normal. Teilweise aber erst nach einem Refresh der Seite. Interessant: der rpool wird dann nicht mehr angezeigt.

Die SMB Shares funktionieren ohne Probleme normal weiter.

 

[gea]

Ich kann das Problem nicht nachvollziehen, bei mir bleibt in 24.01 die Tabellenanordnung gleich.

- Page reload ist klar je nach Browser, sonst wird die alte Version gezeigt.
Insgesamt mal Cache leeren oder mit Shift-F5 ein reload erzwingen.

- Rpool selber wird bei der Anzeige unterdrückt (Da sollten keine Nutzdaten oder Shares hin)
außer man legt ein Dateisystem unter rpool an (z.B. Damit Server mit nur einer Platte möglich ist)

- Für den Betrieb wird napp-it nicht benötigt, nur zum Ändern von Einstellungen.

 

[you]

Spannend.

rpool erscheint, wenn ich ACC einschalte. Und sobald es erscheint, verschiebt sich die Tabelle. Die 2-4 Sekunden vorher schaut alles normal aus.

Also: ACC auf on schalten, dann baut sich Tabelle mit meinen 2 Pools neu auf. Tabelle OK. 2-4 Sekunden später erscheint rpool. Dann verschiebt sich die Tabelle.

Mein rpool:

rpool                            18,1G  12,4G       24K  /rpool
rpool/ROOT                       1,60G  12,4G       24K  legacy
rpool/ROOT/r151050e              1,60G  12,4G     1,60G  /
rpool/dump                       8,00G  12,4G     8,00G  -
rpool/export                       48K  12,4G       24K  /export
rpool/export/home                  24K  12,4G       24K  /export/home
rpool/swap                       8,50G  20,8G     41,5M  -

PS: Cache löschen und so habe ich alles schon gemacht. Ich kann o.g. Verhalten reproduzieren. Egal ob cache-geleerter Safari oder Opera.

 

[you]

Ich habe jetzt noch mal ein bissl probiert. Bootenvironments gelöscht, Reboot, Runter-/Hochfahren, Update auf dev und zurück auf d. Es gibt einen gemeinsamen Nenner: Schalte ich ACC ein, erscheint das rpool in der Liste, wenn ich ZFS Filesystems anklicke. Und sobald dieses erscheint, verschieben sich die Infos in der Tabelle. Irgendwas ist da krum. Schalte ich ACC aus, verschwindet nach einem Refresh rpool und die Tabelle passt.

Nach einem Update auf dev funktionierte es 1x. Ich habe dann den napp-it Dienst auf der Konsole testweise gestoppt, wieder gestartet und ich war wieder beim Fehler. Der dann auch nicht mehr wegging. Ich konnte das Funktionieren nach einem Update allerdings nicht mehr reproduzieren.

Ich habe an der Installation nichts geändert. Ich habe napp-it auch wie im Handbuch beschrieben gelöscht, noch mal neu eingespielt und meine Konfiguration aus dem Backup zurückgeladen. Immer dasselbe wie oben beschrieben.

 

[gea]

Im Moment ist mir die Ursache nicht klar.
Ich setze das mal auf Beobachten.

Dass rpool nicht angezeigt wird sofern kein eigenes Dateisystem darunterliegt ist eigentlich Absicht,
Also alles wie es sein soll, bis auf das die verschobene Tabelle.

 

[LuxSkywalker]

würde ich 5 Platten im Z2 machen (30TB usable)

bitte nicht 5 Platten als RaidZ2 - wenn dann 6 😉

RAIDZ2​

	4 drives	5 drives	6 drives	7 drives	8 drives	9 drives	10 drives
16k	44.44%	44.44%	66.66%	66%	66%	66%	66%
64k	48.48%	53.33%	66.66%	66.66%	66.66%	66.66%	76.19%
expected	50%	60%	66.66%	71.42%	75%	77.77%	80%

du hast sonst zuviel "Verlust" an verfügbarem Speicherplatz aufgrund der Paritätsdaten - alles ausser 6 Devices macht bei RaidZ2 m.e. nach keinen Sinn - siehe Tabelle

ist ähnlich wie RaidZ1 - da macht alles andere als 3 Devices auch keinen Sinn aufgrund dem Verlust an verfügbarem Speicherplatz wegen der Paritätsdaten

 

[gea]

Die Empfehlung 2^n Datenplatten (ohne Parität) für Raid-Z zu nehmen z.B. 3/5 für Z1 oder 6/10 für Z2 ist richtig wenn man davon ausgeht, dass ZFS Datenblöcke auch 2^n K groß sind z.B. 128K. Das war früher generell der Fall, ist heute aber die absolute Ausnahme. Das liegt daran, dass neuere Kompressionsverfahren wie LZ4 auch bei bereits komprimierten Daten fast keinen Performanceverlust aufweisen. Man kann also die Empfehlung aussprechen, z.B. LZ4 generell einzuschalten. Kostet fast nichts und bringt bessere Performance und geringeren Platzverbrauch.

Dadurch hat man aber variable Datenblöcke je nach Komprimierung und damit ist auch die "goldene Regel" 2^n von früher hinfällig. Daher einfach soviel Platten pro Raid-Z vdev nehmen wie man möchte und LZ4 einschalten.

How I Learned to Stop Worrying and Love RAIDZ

The popularity of OpenZFS has spawned a great community of users, sysadmins, architects and developers, contributing a wealth of advice, tips…

www.delphix.com

 

[pwnbert]

Hab das mit der Kompression schon mal getestet und auch etwas ausführlicher gepostet. Ich bin zum Schluss gekommen, dass LZ4 super ist. Weils komprimierbare Daten recht brauchbar komprimiert und dabei sauschnell ist... Gibt zwar Algos die besser komprimieren, dabei aber ein vielfaches (Zehner Potenzen mehr!) Rechenleistung brauchen.

Für die allermeisten Anwendungen kann man wohl das Default LZ4 einfach lassen und gut is.

 

[pwnbert]

Liebe ZFS Kenner, ich hab hier noch eine Frage offen, bezüglich L2arc.

Ich hab den Fall, dass ich ein recht großes ZFS Datengrab hab (4x 20tb Ultrastar im Z1).
Eigentlich läuft die Sache ganz gut, wenn sie sich mal "eingearbeitet" hat und soweit im Arc Cache liegt (ich verwende hier 64gb der 128gb RAM, wies bie TNS standardmäßig konfiguriert ist, funktioniert für mich so ganz gut, der Rest reicht mir bequem für die VMs).

Wenn ich wo länger nicht zugegriffen hab bzw. rebootet hab (kommt nicht oft vor, aber doch mal), muss sich dieser natürlich erst aufbauen. Da dauert das in entsprechend großen Ordnern eine gewisse Zeit, bis man die Dateien schön angezeigt hat bzw. auch enstprechend flott nach Datum, Zeit, Name etc. sortieren kann. Wenns mal "eingelesen" ist, läfuts eh gut.

L2arc ist ja persistent, der sollte mir in dem Fall ja einen deutlichen Vorteil bringen, da die Metadaten alle im ARC bzw. L2arc sein sollten, wenn ich das richtig verstehe.
=> Stimmt das?

A) Macht ein L2arc die Sache der Ordernzugriffe und Listungen deutlich(!) flotter?
B) Wenn A=true, wie groß wählt man den? Man liest, nicht mehr als 10x ARC, wobei das schon recht groß wäre, mit 640gb... wie ist das mit den TBW, wie hart ist die Workload, wahrscheinlich ists eher lesen? Ich würde wohl eine 1 TB M.2 nehmen (da die 500gb nicht so viel billiger sind und weniger TBW haben), nachdem mein NAS nur PCIe 3.0 hat, tendiere ich zu einer WD red M.2 mit 1 tb, die hat schön viel TBW und ist vom Preis her im Rahmen. IOPS sind jetzt nicht so prall, aber ne WD_black oder 980/990pro wird auf PCIe 3.0 auch nicht die besseren IOPS ausspielen können, fürchte ich.
Ich würde momentan dazu tendieren, eine WD red ( https://geizhals.at/western-digital-red-sn700-nvme-nas-ssd-1dwpd-1tb-wds100t1r0c-a2609975.html ) rein zu machen und davon "nur" so 200-400gb als l2arc zu verwenden (ist es nachteilig ihn zu groß zu machen, "Verwaltungsaufwand"?), sollte sich ja positiv auf die TBW auswirken. Die 250/500gb SN700 ist nicht viel billiger als die 1tb...

Ich weiss, is ein Luxusproblem irgendwie, aber die 85€ wärs mir schon wert.
Seh ich das so richtig? Wäre das zielführend?


Und noch eine Frage, ich könnte von einem Kumpel eine Intel Optane H10 1tb bekommen.
Diese ist natürlich keine "echte" Optane sondern 1tb QLC mit 16 oder 32gb xpoint NAND.
=> Könnte ich diese als SLOG einsetzen, mit einer einer "freigegebenen" Größe von 16/32gb (die Hoffnung wäre, dass hier eben zuerst der xpoint genutzt wird, diese kleine Größe sollte für ein SLOG ja reichen)?
Ich bin mir jetzt natürlich nicht sicher, ob ich das überhaupt brauche, mir ist immer noch nicht so klar, welche Schriebe (was ist denn der "write" auf Deutsch ) nun synchron sind und welche nicht, aber nachdem ich sowiso nen M.2 Adapter in den Graka Slot machen kann, wäre das ja "geschenkt".


PS:
svdev möchte ich nicht machen, das ist mir zu riskant und bräuchte ja wieder einen extra Mirror, damit das halbwegs sicher ist. Das ist sicher nice, aber es ist mir too much.
L2arc und SLOG sollten ja unkritisch sein beim Ausfall, wenn ich das recht verstehe.

 

[gea]

some remarks

L2Arc und Slog dürfen ausfallen, daher ist da Redundanz eine "Luxus" Option.
Hilft natürlich um die Performance trotz Ausfall zu halten.

L2 Arc ist viel langsamer als RAM, braucht RAM zum Verwalten, ist dafür persistent.
Mit ausreichend RAM eine "Luxus" Option.
Hilft aber die Performance nach Reboot zu halten.

Special vdev ist kein Cache, sondern Data Tiering, darf genausowenig ausfallen wie andere vdevs,
sollte daher gleiche Redundanz Sicherheit haben, gerne auch 3 way Mirror.
Hilft dafür beim Lesen und Schreiben kleiner io und bei Metadaten oder Dedup.

 

[pwnbert]

braucht RAM zum Verwalten

CPU auch nennenswert?
Wie viel RAM? Kann man das Pauschal übern Daumen benennen, wie viel % RAM pro L2arc oder so?

L2 Arc ist viel langsamer als RAM, braucht RAM zum Verwalten, ist dafür persistent.

Ja... 300 mb/s die HDD, 3.000 mb/s die M.2 u nd 30.000 mb/s der RAM... so ca.
Ist die Frage, obs mit IOPS SSD vs. HDD noch besser wird, bezüglich dem Laden der Ordnerinhalte und so.

Special vdev ist kein Cache, sondern Data Tiering, darf genausowenig ausfallen wie andere vdevs,

Ich weiss, würde aber helfen um Metadaten schnell zu halten, fällt für mich aber raus, is mir zu viel des Guten.


Nachdem die Metadaten ja im ARC sein sollen, meinem Verständnis nach, dachte ich, es wäre vielleicht ein "Trick" einen L2arc zu verwenden, da diese dann ja persistent auch dort drin liegen sollten.
Somit hätte ich den Vorteil von Metadaten auf der SSD ohne ein special vdev haben zu müssen. => So dachte ich....

Mir gehts ja gar nicht so darum, dass die Dateien schnell geöffnet werden, zumindest bei größeren Dateien ist mein Pool eh schneller als das Netzwerk.
Eher um die schnelle Navigation durch wirklich volle Ordner, so dass die entsprechende Sortierung etc. flott geht.

Wobei ich sagen muss, jetzt, wo das NAS ne Zeit läuft und ich genug in allen Ordern drin war, fluppt das eh wieder. Ist wahrscheinlich mit Kanonen auf Spatzen, deshalb einen L2arc anzuschaffen.
Spielen würd ich trotzdem irgendwie gern damit.

PS: Hab mir auch schon überlegt, dass man die Metadaten ja mit irgend einem Crawler-Script "in den ARC zwingen" könnte, indem man einfach mal von einer VM oder einem Container aus die SMB Shares "durchstöbert"... bin aber nicht gut in sowas, kann das selbst nicht realisieren (und dann ist noch die Frage, ob sowas von irgendwelchen Sicherheitsfunktionen als "Schadsoftware" erkannt wird).



Ich hoffe, ich hab mich nicht zu wirr ausgedrückt.

 

[gea]

Im Prinzip könnte man mit "find" die Platte durchsuchen lassen um den Arc mit Metadaten zu füllen. Aber ganz ehrlich, mit soviel RAM für ZFS, das OS und die Web-GUI würde ich da garnichts machen. Der Aufwand ist groß und der Performancegewinn ist vernachlässigbar wenn man nicht gerade 100 User mit 1 Mio Dateien hat z.B. den Mailserver einer Hochschule. Da lohnt sich dann ein L2Arc.

Die einzige Maßnahme die wirklich die Performance drastisch verbessert wäre ein Hybrid Pool mit special vdev z.B. einem Mirror aus 2 x Optane 1600 128GB, dazu eine recsize von 256GB oder mehr und eine small blocksize von 64 oder 128GB. Damit landen nicht nur Metadaten sondern alle Dateien die komprimiert kleiner sind als 64 oder 128K auf der Optane und das wäre fast alles bis auf Videos und Bildern. Wenn man bei einem einzelnen Dateisystem eine recsizse <= small blocksize einstellt, landen sogar alle Daten dieses Dateisystems auf der Optane, z.B. VMs.

 

[pwnbert]

Ja, das dachte ich dann auch, dass das vielleicht doch mit Kanonen auf Spatzen ist. Aber wir sind hier ja im Luxx und machen das (auch) weil wirs lustig finden...

Im Prinzip könnte man mit "find" die Platte durchsuchen lassen um den Arc mit Metadaten zu füllen.

Ja, sowas in die Richtung war meine Idee. Reicht find dafür? Einfach irgendwas suchen, weil ohnehin alles durchgegangen wird?
Muss ich das über eine SMB/NFS Freigabe machen, oder reicht das, wenn am TNS in der Admin Shell gesucht wird?
Man könnte da dann doch ein Startup Script machen, oder?

 

[gea]

Der ZFS Cache weiß nichts von NFS oder SMB. Den interessieren nur read last/ read most ZFS Datenblöcke.
Als wenn find, dann lokal.