[Sammelthread] ZFS Stammtisch

So, ein guter Morgen, der zweite Scrub ist nun auch durch und tadaaa...der Fehler ist weg. Also war vermutlich meine Reigenfolge falsch, man muss wohl zuerst ein Clear machen und dann erst ein Scrub. Wär trotzdem klasse wenn mir noch jemand erklären könnte, wie das genau zustande gekommen sein könnte

Was mir aber immer noch nicht klar ist, wie dieses Szenario zustande kommt. Snapshots hab ich auf dem betreffenden Datasets keine, gelöscht hab ich auch nix. Wie kann denn so etwas dann zustande kommen?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Die Freude war leider nur von kurzer Dauer, mein System hat wohl ein schwerwiegendes Problem. Beim Versuch eine 90GB Datei vom HD-Pool auf eine externe USB-Platte zu kopieren, ist das System erneut gecrashed, dieses mal liefen allerdings gerade auch noch zwei VM's auf dem SSD Pool. Danach hatte ich wieder zig CKSUM Fehler, dieses mal allerdings auf beiden Pools, vermutlich weil ja auf dem SSD Pool die VM's liefen und vom HD Pool kopiert wurde. Nach einem Reboot waren die CKSUM Fehler wieder weg, die Pools meldeten allerdings "Permanent errors":

Code:
zpool status -v
  pool: raid1-hd
 state: ONLINE
status: One or more devices has experienced an error resulting in data
	corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
	entire pool from backup.
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: scrub repaired 0 in 10h9m with 0 errors on Tue Feb 24 20:22:51 2015
config:

	NAME        STATE     READ WRITE CKSUM
	raid1-hd    ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    ada2    ONLINE       0     0     0
	    ada3    ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        /mnt/raid1-hd/backup/Server - Archiv.vmdk

  pool: raid1-ssd
 state: ONLINE
status: One or more devices has experienced an error resulting in data
	corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
	entire pool from backup.
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: scrub repaired 0 in 0h5m with 0 errors on Mon Feb 23 21:07:00 2015
config:

	NAME          STATE     READ WRITE CKSUM
	raid1-ssd     ONLINE       0     0     0
	  mirror-0    ONLINE       0     0     0
	    ada0.nop  ONLINE       0     0     0
	    ada1.nop  ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        /mnt/raid1-ssd/pve/images/105/vm-105-disk-1.qcow2
        /mnt/raid1-ssd/pve/images/101/vm-101-disk-1.qcow2

Ich bin dann schon vom schlimmsten Fall ausgegangen, dass meine beiden VM's geschrottet sind, weil die Dateien ja als "Permanent errors" angezeigt wurden. Also mal wieder Scrub gestartet auf dem SSD Pool, der beindruckender Weise mit über 500M/s in kurzer Zeit durchgerauscht ist. Danach waren die Fehler seltsamer Weise komplett weg, ohne das etwas "repaired" wurde!?

Code:
  pool: raid1-ssd
 state: ONLINE
status: The pool is formatted using a legacy on-disk format.  The pool can
	still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
	pool will no longer be accessible on software that does not support feature
	flags.
  scan: scrub repaired 0 in 0h5m with 0 errors on Wed Feb 25 11:13:57 2015
config:

	NAME          STATE     READ WRITE CKSUM
	raid1-ssd     ONLINE       0     0     0
	  mirror-0    ONLINE       0     0     0
	    ada0.nop  ONLINE       0     0     0
	    ada1.nop  ONLINE       0     0     0

errors: No known data errors

Ich hab die betroffenen VM's (1x Linux, 1x Windows) gestartet und intern jeweils ein Filesystem-Check laufen lassen, die auch ok waren. Also scheinen die glücklicherweise tatsächlich nix abbekommen zu haben. Ist das normal, dass Fehler als "Permanent errors" angezeigt werden und evtl. trotzdem wieder repariert werden können?
 
Ich habs mir vorhin verkniffen, deine Euphorie durch ein "na warts ab..." zu dämpfen. Ich hab auch so nen komischen Metadata-Fehler, den kann man clearen, da kann man mal erfolgreich scrubben, aber ganz weg geht der wohl nie. Allerdings stehen bei mir weder Checksumfehler aufm Zähler, noch krieg ich reale Daten mit "permanent errors" angezeigt. Und es MUSS sich um einen Fehler im Pool selbst handeln, denn alle ZFS, die beim Aufkommen des Fehlers existierten, gibts längst nicht mehr. Ich hab die zwischendurch mal umgeschichtet, der Fehler bleibt. Aber für ne komplette Neuanlage des Pools fehlt mir neben dem (redundanten) Platz zum Auslagern auch die Motivation, wenns halt nur eine nervige, aber bisher folgenlose Meldung ist.
Dennoch, Checksumfehler sollen nicht vorkommen, ich würd auch Fehlerprüfung der Kabel (wie genau hast du verkabelt?) und RAM/CPU vorschlagen.
 
Der usprünfgliche Fehler ist ja weg und kam auch nicht wieder. Hier handelt es sich leider um ein neues Problem. Zu meinem System schreib ich nachher noch was, ich wollte zuerst mal nur wissen, ob das so normal sein kann, das Dateien in "Permanent errors" angeziegt werden und nach einem Scrub wieder ok sind?
 
Liefer doch mal den SSD Typ, Smart Werte dazu und deine sync-Einstellung:

zfs get sync raid1-ssd

irgendwelche sonstigen Settings, die vom ZFS Standard abweichen?


ciao
 
Zuletzt bearbeitet:
Das Problem liegt meines erachtens an meinem System oder Mainboard. Ich hatte das AIO-System genau so wie es ist, über 2 Jahre lang mit einem Intel-DQ67SW (kein ECC RAM!) im Einsatz - ohne jegliche Probleme, ohne Fehler. Angeregt durch die ECC RAM Diskussion vor ein paar Monaten hier, hab ich mir kürzlich dann ein Supermicro-X10SAE mit 16GB ECC Ram zugelegt und das System umgebaut. Kurz danach fingen dann die Probleme an.

Das Hostsystem ist wie schon erwähnt Proxmox-3. Der Intel Onboard-Controller mit den 4 Platten (2x SSD Samsung-840-Pro, 2x HDD Hitachi HDS5C3030ALA630) wird an Nas4Free durchgereicht (ZFS: 2 Pools, 1x SSD Mirror, 1x HD Mirror), das stellt per NFS Proxmox den Datastore zur Verfügung und dient zusätzlich noch als NAS, eben nach dem Prinzip von Gea's ESXi-AIO, nur eben mit Proxmox. Was jetzt noch erschwerend hinzu kommt ist, dass ich kurz nach dem Umbau auch noch Proxmox von 3.3 auf 3.4 upgegraded habe. Somit habe ich nun also zwei mögliche Fehlerursachen: Entweder kommt das SM-Board mit dem Passthrough nicht perfekt zu recht, oder das Problem liegt an der neuen Proxmox Version. Laut SM Support kommt demnächst für das MB ein neues Bios raus, dass wohl auch Verbesserungen im Bereich Passthrough beinhalten soll. Vielleicht ändert sich ja dann was. Bis dahin hoffe ich mal, dass nix mehr passiert. Rückwirkend betrachtet kamen die Probleme immer nur dann, wenn das System stärker belastet wurde, im "normalen" Betrieb mit 3-4 VM's und ohne große Kopieraktionen lief alles problemlos, aber das ist natürlich kein Zustand so. Sollte das Bios Update auch nichts verbessern oder ich nicht noch eine andere Ursache finden, muss ich mich wohl oder übel vom AIO Konzept verabschieden und einen sep. ZFS Datastore aufbauen :(

Trotz allem würde mich aber das mit den "Permanent errors" / Scrub / wieder ok (meine Frage oben) noch interessieren, einfach ob das so normal ist/sein kann, ich hab ja glücklicherweise noch keine großen Erfahrungen mit ZFS-Problemen :)
 
Hi,
ZFS ist für mich noch Neuland. Was ich bisher gelesen habe und ausprobiert habe begeistert mich sehr. Nun habe ich eine Frage bzgl. Nested Datasets.

Macht es Sinn auf meinem Server für jedes home directory ein eigenes Dataset und da drin ebenso noch mal nested datasets anzulegen. Z.b.

/mnt/pool/home
/mnt/pool/home/marko
/mnt/pool/home/marko/Documents
/mnt/pool/home/marko/Pictures
/mnt/pool/home/marko/Movies

So wie ich es verstehe wäre der Vorteil das ich pro Dataset z.b. Compression anschalten kann. In meinem obigen Beispiel macht das für das Dataset `Documents` sinn für `Movies` jedoch nicht. Desweiteren kann ich von jedem Dataset Snapshots machen kann.

Ist diese Struktur ok oder gibt es eine Art recommendation oder common usage über die Struktur von Datasets?
Gibt es Vorteile oder Nachteile bei diesem Setup?

Danke
Marko
 
Hi,
Macht es Sinn auf meinem Server für jedes home directory ein eigenes Dataset und da drin ebenso noch mal nested datasets anzulegen. Z.b.

/mnt/pool/home
/mnt/pool/home/marko
/mnt/pool/home/marko/Documents
/mnt/pool/home/marko/Pictures
/mnt/pool/home/marko/Movies

So wie ich es verstehe wäre der Vorteil das ich pro Dataset z.b. Compression anschalten kann. In meinem obigen Beispiel macht das für das Dataset `Documents` sinn für `Movies` jedoch nicht. Desweiteren kann ich von jedem Dataset Snapshots machen kann.

Ist diese Struktur ok oder gibt es eine Art recommendation oder common usage über die Struktur von Datasets?
Gibt es Vorteile oder Nachteile bei diesem Setup?
Marko

Nachteile sehe ich bei dieser Struktur nicht, ZFS kommt auch mit einer größeren Anzahl von ZFS-Filesystems klar. Bei nested Filesystems erben die untergeordneten Filesystems die properties des übergeordneten Filesystems, sofern diese nicht explizit abweichend gesetzt werden.

Ein weiterer Vorteile neben Snapshots ist auch die einfache Möglichkeit von Backups mit zfs send | zfs receive sowie die Nutzung weiterer zfs-properties (Bspw. sharesmb, sharenfs, oder auch quota und reservation).

Was die property compression angeht, gibt es durchaus Empfehlungen, diese grundsätzlich zu nutzen (siehe unter 7.), das ist aber bei bereits komprimierten Daten sicher auch Geschmackssache.
 
Vielen Dank!
Mal sehen ob ich zfs send / zfs receive als backup verwende. Technisch interessiert mich das sehr. Bin jedoch halt noch sehr unsicher dabei. Backups sind mir jedoich sehr wichtig. Mit CarbonCopyCloner kann ich halt easy meine "verlorenen" files suchen und finden. Ich werde send/receive einfach mal testen. Vlt geht es ja recht gut.
Die Snapshots sollten ja, so wie ich es verstanden habe, nicht so viel Festplattenlatz belegen solange sich die files nicht ändern oder gelöscht werden.
 
Wie hiessen die "perfekten" Controller zum durchreichen noch mal genau?
IBM-M1015 und?
Gibt es da auch schon was in SATA-III bzgl. SSD's ?


Edit:
Ok, habs gefunden. Der LSI ist der Originale und teurere, der M1015 ist OEM und kann entsprechend umgeflasht werden.
Aber ist der jetzt SATA II oder III? Hier http://direkt.jacob-computer.de/_artnr_1066806.html?ref=109 "SATA-300", irgendwo anders hatte ich aber SATA-III gelesen?
 
Zuletzt bearbeitet:
[root@freenas] ~# smartctl -a /dev/da0
smartctl 6.3 2014-07-26 r3976 [FreeBSD 9.3-RELEASE-p8 amd64] (local build)

=== START OF INFORMATION SECTION ===
Model Family: Western Digital Red (AF)
Device Model: WDC WD30EFRX-68EUZN0
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)



Von einer WD Red 3TB an einem IBM M1115 (nahezu baugleich M1015) im Passthrough unter FreeNas
 
sata-300 = sata 2
sata-600 = sata 3

Das ist mir schon bewusst, deshalb hatte ich ja gefragt, weils bei Jacob so steht. Hab vorhin dort angerufen, sei wohl ein Fehler in der Beschreibung. :)

- - - Updated - - -

Von einer WD Red 3TB an einem IBM M1115 (nahezu baugleich M1015) im Passthrough unter FreeNas

Wo liegt denn der genaue Unterschied zwischen den Beiden?
 
Ich meine mich zu erinnern, dass es etwas damit zu tun hat, wie man spezielle RAID Level Features freischalten kann, ich glaube beim M1015 musste man beim Kauf schon die entsprechende Version wählen, beim M1115 konnte man die Lizenz nachträglich ordern!? Aber als HBA ist das uninteressant. Ich glaube es sind sogar für beide die gleichen LSI Files beim Cross-flashen.
Google sollte dazu was ausspucken, aber als HBA im IT Mode nicht relevant.
 
Kann ich eigentlich einen Pool bedenkenlos zwischen FreeBSD und Linux hin und her wechseln?
Die Pool-Version ist noch "28". Er hängt momentan an einem "FreeBSD 9.2-RELEASE-p4", aber ich möchte mal ein paar Tests unter Linux (ZoL) machen.
Nach dem was ich bis jetzt dazu gefunden habe, müsste es eigentlich funktionieren, "zpool export ..." & "zpool import ...".
Hat da schon jemand Erfahrungen damit gemacht?

Ich hatte ihn schon mal kurz am Linux System hängen, mit "zpool import" wird jedenfalls schon mal richtig erkannt., allerdings wird für die Fetplattenbezeichnungen "ata..." genommen. Ich hatte aber kürzlich irgendwo gelesen, dass man da "/dev/disk/by-id/scsi..." benutzen sollte?
 
@trendco
ich bin mit meinem Pool schon zwischen Linux, FreeBSD 10, OmniOS und zurück zu Linux gewechselt, ohne Probleme. Statt Version "28" gibt es im open source-Bereich ja jetzt nur noch verschiedene Features, die abhängig der Aktualität der OpenZFS-Implementierung und des jeweiligen Systems sind. Wenn du für möglich hältst, dass du bald wieder auf ein "älteres System" zurück wechselst, würde ich auf ein zpool upgrade verzichten. Von 28 kannst du aber gerne mal upgraden, allein wegen der Komprimierung. Die Features von der stabilen Version ZoL 0.6.x sollten recht kompatibel mit anderen Systemen sein. Ob es wirklich Features gibt die ein Downgrade unmöglich machen weiß ich aber garnicht.

Mein kürzlicher Import in Linux sah so aus: zpool import -d /dev/disk/by-id/ tank
Macht Sinn weil sich so die Platten anhand der Namen deutlich leichter identifizieren lassen und bei anderer Verkabelung nicht anders heißen, denn default ist sdX.

Warnungen kann es nur geben wenn Freigaben mit zfs set (z.B. smbshare) gesetzt sind (Solaris ftw.) aber z.B. Linux das nicht unterstützt. Ist aber nicht tragisch.
 
Ok, schon mal gut zu hören, vielen Dank. Kann man beim Import noch irgendwie beeinflussen, welchen Bezeichner er bei "/dev/disk/by-id/" benutzt? Da stehen ja für jede Platte drei Bezeichner drin, "ata-...", "scsi-...", "wwn-...". Keine Ahnung ob man einen gewissen nehmen muss/sollte, ich finde die Quelle leider auch nicht mehr wo ich das gelesen hatte, dass man "scsi-..." nehmen soll.

Bzgl. Pool Upgrade: Wäre das egal, ob ich den unter FreeBSD oder unter Linux upgrade?
 
Kommt auf die Version von FreeBSD an. Laut Features - OpenZFS hat FreeBSD die deutlich aktuellere Unterstützung und ZFS on Linux wäre quasi der kleinste gemeinsame Nenner. Allerdings wird hier FreeBSD mind. 9.3 (eher 10?) mit ZoL 0.6.3 verglichen, dessen release schon eine Weile her ist. Aktuelle Entwicklerversion ist deutlich weiter. Wäre schön wenn noch jemand was zum "Downgrade" bei Wechsel auf eine Version mit fehlenden Features sagen könnte, aber grundsätzlich bist mit ZoL 0.6.3 gut dran.

aus man zpool-features
"The pool format does not affect file system version compatibility or the ability to send file systems between pools."
Heißt das sobald man auf 5000 ist, beeinflussen aktivierte Features nicht die Kompatibiltät?

Wie die Platten im Pool heißen ist ja eigentlich egal, die ata-/scsi-/wwn- Namen sind ja auch nur symlinks. Aber eindeutiger im Problemfall, bei mir z.B.:
ata-WDC_WD20EARS-00MVWB0_WD-WCAZA5508763 -> kann ich direkt auf dem Aufkleber ablesen welche Platte betroffen ist.
 
Napp-it Add-On's / neue Versionsstände

Joyent hat jüngst sein SmartOS-Repo aktualisiert (2014Q4), so dass ich u.a. das AMP-Script (Apache, MySQL, PHP, phpMyAdmin) aktualisiert habe.

Bis gea es auf www.napp-it.org bereitgestellt hat, kann es mit "wget -O - http://www.wp10455695.server-he.de/amp | perl" gestartet werden.

Eine Neuerung im Script ist die zusätzliche Installation der In-Memory Datenbank Redis. Diese findet Verwendung u.a. bei ownCloud und Tine 2.0, welche ja ebenfalls als freie napp-it add-on's verfügbar sind.

Die Komponenten von AMP haben derzeit folgende Versionsstände:
- Apache 2.4.10
- MySQL 5.6.22
- Redis 2.8.18
- PHP 5.6.5
- phpMyAdmin 4.3.10

Außerdem gibt es noch neue Versionen der add-on's
- ownCloud (Version 8.0.0, Installation des Scriptes mit "wget -O - http://www.wp10455695.server-he.de/owncloud | perl")
- Pydio (Version 6.0.3, Installation des Scriptes mit "wget -O - http://www.wp10455695.server-he.de/pydio | perl")
- VirtualBox (Version 4.3.22, phpVirtualBox Version 4.3-2, Installation des Scriptes mit "wget -O - http://www.wp10455695.server-he.de/phpvbox | perl")

Bei mir lief in einer aktuellen OmniOS-VM alles sauber durch. Falls es Probleme gibt, bitte Feedback (kann mich aber vermutlich erst übernächste Woche darum kümmern...).
 
Noch ein Nachtrag:
Im Log (siehe /opt/local/share/serviio/log/serviio.log) erscheinen zunächst Fehlermeldungen, dass "dcraw" und "ffmpeg" nicht gefunden werden.

Auf die Schnelle ist das wie folgt zu lösen:
(1) svcadm disable serviio
(2) Datei /opt/local/share/serviio/bin/serviio.sh editieren:
(3) Suche nach Zeile die mit "JAVA_OPTS=" beginnt
(4) In dieser Zeile zum Ende navigieren und die Parameter
(4a) "-Dffmpeg.location=ffmpeg" ändern in "-Dffmpeg.location=$SERVIIO_HOME/ffmpeg"
(4b) "-Ddcraw.location=dcraw" ändern in "-Ddcraw.location=$SERVIIO_HOME/dcraw"
EDIT: und speichern nicht vergessen :)
(5) svcadm enable serviio

Jetzt sollten die Fehlemeldungen im Log verschwunden sein.

Release Notes - 1.5.1

gibt noch nen neues bugfix release :)
 
Nachdem ich mich lange gewundert habe mit der Napp-IT Appliance nicht mehr als 50-60 MB/sec Durchsatz über Gigabit zu kommen, habe ich in einer Xpenology Installation die Netzwerkfreigabe vom Napp-It als Shared Folder durchgereicht. Intern per vmxnet3 mit eigenem Netz verknüpft. Habe jetzt den Vorteil der schönen Synology Oberfläche und nebenbei Übertragungsraten um bis zu 115 MB/sec auf meinem Windows PC.

Ist dies ein Problem von Windows zu Napp-IT, oder ist der Netzwerkstack / SMB Freigabe bei ZFS schlechter und läuft dann nur mit Linux effektiv?

Auf jeden Fall empfehle ich jedem mit einer Synology/Xpenology das mal zu testen. (CIFS / "Remote Ordner bereitstellen")
 
Zuletzt bearbeitet:
mauorrizze:
Hattest Du zufällig mal die Geschwindigkeiten unter den verschiedenen Betriebssystemen getestet?
Ich habe heut mal ein paar dd Tests gemacht und war doch recht erstaunt:

- Mirror SSD Pool, KEINE Kompression (2x Samsung 840 Pro)
- zwischen den Tests neu gebottet, damit nix im RAM ist.

Code:
[U]Linux (ZoL):[/U]

root@proxmox:~# dd if=/mnt/raid1-ssd/pve/images/110/vm-110-disk-1.qcow2 of=/dev/null bs=2M count=3000
3000+0 records in
3000+0 records out
6291456000 bytes (6.3 GB) copied, 9.47247 s, [COLOR="#0000FF"]664 MB/s[/COLOR]

root@proxmox:~# dd if=/mnt/raid1-ssd/pve/images/104/vm-104-disk-1.qcow2 of=/dev/null bs=2M count=3000
3000+0 records in
3000+0 records out
6291456000 bytes (6.3 GB) copied, 8.42852 s, [COLOR="#0000FF"]746 MB/s[/COLOR]


Code:
[U]Nas4Free (FreeBSD):[/U]

nas4free: ~ # dd if=/mnt/raid1-ssd/pve/images/110/vm-110-disk-1.qcow2 of=/dev/null bs=2M count=3000
3000+0 records in
3000+0 records out
6291456000 bytes transferred in 5.985437 secs (1051127276 bytes/sec) -> [COLOR="#0000FF"]1002 MB/s[/COLOR]

nas4free: ~ # dd if=/mnt/raid1-ssd/pve/images/104/vm-104-disk-1.qcow2 of=/dev/null bs=2M count=3000
3000+0 records in
3000+0 records out
6291456000 bytes transferred in 5.829766 secs (1079195326 bytes/sec) -> [COLOR="#0000FF"]1029 MB/s[/COLOR]

Kann das sein?
 
Zuletzt bearbeitet:
Klar, ZFS kann in deinem Fall (Mirror) von beiden SSDs parallel lesen. Beim schreiben würde das schon anders aussehen.

cu
 
Das ist mir schon klar, aber warum so ein krasser Unterschied zwischen Linux & FreeBSD ?
 
Nachdem ich mich lange gewundert habe mit der Napp-IT Appliance nicht mehr als 50-60 MB/sec Durchsatz über Gigabit zu kommen, habe ich in einer Xpenology Installation die Netzwerkfreigabe vom Napp-It als Shared Folder durchgereicht. Intern per vmxnet3 mit eigenem Netz verknüpft. Habe jetzt den Vorteil der schönen Synology Oberfläche und nebenbei Übertragungsraten um bis zu 115 MB/sec auf meinem Windows PC.

Verstehe ich das richtig

OmniOS CIFS >> Windows: langsam
OmniOS CIFS >> Linux/SAMBA >> Windows: schnell

Normalerweise ist der Umweg immer langsamer, auch ist der Solaris CIFS Server meist schneller als SAMBA

Ich würde vermuten, dass auf Windows etwas läuft, was auf Windows oder SAMBA optimiert ist, z.B.
- Copy Tools (TeraCopy ist da so ein Kandidat)
- manche (ältere) Realtek Treiber kommen mit Solaris CIFS auch nicht ganz klar

- - - Updated - - -

Joyent hat jüngst sein SmartOS-Repo aktualisiert (2014Q4), so dass ich u.a. das AMP-Script (Apache, MySQL, PHP, phpMyAdmin) aktualisiert habe.

Bis gea es auf www.napp-it.org bereitgestellt hat, kann es mit "wget -O - http://www.wp10455695.server-he.de/amp | perl" gestartet werden.

Top und Danke.
Ich werde es morgen auf napp-it.org hochladen
 
Verstehe ich das richtig

OmniOS CIFS >> Windows: langsam
OmniOS CIFS >> Linux/SAMBA >> Windows: schnell

Normalerweise ist der Umweg immer langsamer, auch ist der Solaris CIFS Server meist schneller als SAMBA

Ich würde vermuten, dass auf Windows etwas läuft, was auf Windows oder SAMBA optimiert ist, z.B.
- Copy Tools (TeraCopy ist da so ein Kandidat)
- manche (ältere) Realtek Treiber kommen mit Solaris CIFS auch nicht ganz klar

Nein, Stock Win7/Win8.1, kein CopyTool, der Umweg über Xpenology ist schneller als direkt, ich hab mich auch ziemlich gewundert.

Wenn ich direkt mit Linux, z.B. Ubuntu vom napp-it lese ist der Speed auch um 100mb/sec

Habe im Windows PC eine Intel Gigabit Karte. Kein Realtek Zeugs.

Aber mal ganz davon ab, ich bin so am glücklichsten. Greife mit dem root Account auf die NappIT Freigaben von der Xpenology aus zu.
Mit der Xpenology verwalte ich die User Konten und von der GUI einfach unübertroffen. (Das soll kein Hieb auf Napp-It sein!!! Habe großen Respekt vor deiner Arbeit gea, aber Napp-It ist ja eher für Sysadmins als für Otto Normal, die Napp-IT Oberfläche benutze ich dann nur für die ZFS Administration.)
 
Zuletzt bearbeitet:
Ich hab jetzt mal noch ein anderes Linux System zum Test hergenommen, das Ergebnis bleibt aber leider gleich.
ARC min/max ist übrigens gleich eingestellt wie auf dem Nas4Free System.

Hat jemand eine Idee an was ich unter ZoL noch drehen könnte?
30% Unterschied kommt mir doch ein bisschen zuviel vor.
 
Laut ZoL Mailingliste sind wohl einige Patches in Bezug auf Mirror's und SSD's noch nicht im Linux Zweig gelandet, ausserdem sei das "Memory Management" unter Linux noch nicht optimal.

-> Dann soll das eben so sein, vielleicht tut sich ja mit dem nächsten Release von ZoL noch was.
 
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