XigmaNAS

Habe den ketzerischen Titel gewählt damit möglichst viele reinschauen.

Einen Teil der Diskussion begann gegen Ende dieses Threads falls jemand das auch noch lesen mag.
viewtopic.php?f=29&t=2169&p=13433#p13433

Ich schlage mich seit geraumer Zeit mit der Problematik herum, daß Directory Scans (um z.b nach einem Dateinamen zu suchen
oder aber um die Größe eines Verzeichnisbaumes zu ermitteln) von zwei Windows 7 Clients aus schneckenlangsam sind.
Dasselbe Phänomen von einem Multimedia Player (Xtreamer Sidewinder Pro)

Insbesondere Verzeichnisbäume mit tausenden Dateien (also noch weit weg vom Zetta Bereich) fallen unangenehm auf.
Ich habe 2 Pools. Einer ist Raidz1 mit 4 Platten und der zweite Pool ist eine 4TB Platte als Single ZFS ohne Redunanz.
Hardware ist ein Asus E-350 Dual Core 1600 Mhz Board mit 8GB Ram.

Wie unangenehm , gemessen in Zeiten anhand eines Beispieles.

Ein Verzeichnisbaum auf dem RaidZ1 mit MP3 Dateien (Unterverzeichnissen A-Z ) dauert beim ersten Scan vom Client aus fast 7 Minuten.
Wiederholende Scans sind dann in ca 5 Sekunden durch.

Über die 4 TB gesucht würden wir von ca 2 Stunden reden !!!
Natürlich hab ich als eifriger Leser sofort die L2Arc Cache Karte gezückt. Erstmal ne SSD ausgeliehen. Brachte so gut wie nichts.
Dann auf USB 3.0 Stick gewechselt. War bei mir vergleichbar und die SSD mußte ich wieder abgeben.
Hab den Secondarycache der beiden Pools auf Metadata gestellt. Den Primarycache wollte ich erstmal auf ALL stehen lassen um
beim kopieren auch noch etwas vom Caching zu profitieren.

Dann hab ich tagelang diverse Tests gemacht. Es verhält sich im Prinzip so daß ich mühevoll über Stunden die Metadaten aufbaue
und dann bei wiederholten Zugriffen es auch halbwegs flott geht. Logisch nicht so schnell wie lokal auf NTFS aber damit kann ich
durchaus leben. Aber sobald ich irgendeinen größeren Film aufs NAS kopiere haut der Primary ARC die Metadaten wieder über Bord.
Da nun ein L2Arc werkelt landen die Daten zwar auch dort aber der Geschwindigkeitsgewinn liegt allenfalls in der schnelleren
Zugriffszeit des Sticks. Beim Transfer kommt er natürlich nie an den Primary Cache (Ram) heran. Ist ja auch noch logisch bis hierhin.

Da ich keinen Bock habe 2 Stunden nach einer Datei zu suchen hab ich nach Lösungen gesucht. Mir kam die Idee direkt auf dem NAS
einen Cronjob laufen zu lassen der zu bestimmten Zeiten halt sowas macht ...

Also über Putty ins System und es auf der CLI ausprobiert. So und dann kam der spannende Moment.

Pool1 -> find /mnt/SP1 -iname "*pillepalle*"
Pool2 -> find /mnt/RZ1 -iname "*pillepalle*"

Damit gehts rekursiv über alle Dateien und am Ende sind alle Metadaten im Primary Cache.
Das dauert auf der 4TB Platte beim ersten Mal ca 2 Minuten. (ca 600000 Dateien)
Auf dem Raidz1 Pool sind fast nur große Dateien. Da ist er in ca 45 Sekunden drüber gehuscht.

Das ist eine Metadaten Aufbauzeit mit der ich bestens leben könnte.

Also erneut die find Kommandos ausgeführt und auf der 4TB Platte ist er dann in 7 Sekunden durch und im RaidZ1 quasi unmittelbar nach
drücken der Entertaste. Feine Sache. Kann ich den ganzen Abend machen. Superschnell. So wollte ich es.

Irgendwie hatte ich beim Bau des NAS aber wohl fälschlicherweise daran gedacht so ein NAS Server genau diese Funktionalitäten wie
Caching den Clients zur Verfügung stellt und nicht ausschließlich dem User Root der sich lokal via SSH an die Büchse hockt.
Dumm gelaufen. Aber so sieht es aus. Daher der Titel "Die Metadaten Lüge".

Wenn ich direkt nach dem das Kommando -> sysctl vfs.zfs.arc_meta_used
auslöse kann ich sehen daß der Meta Speicher noch leer ist.
Dann setze ich die beiden o.g Find Kommandos über beide Pools ab. Anschließend nochmals
das -> sysctl vfs.zfs.arc_meta_used Kommando und ich sehe daß nun ca 2.5 GB Metadaten im Cache sind.
Von da ab kann ich lokal via SSH innerhalb weniger Sekunden alles lokal scannen.

Dann dasselbe vom Windows Client aus. Schneckenlangsam wie eh und je. Beide Clients mit Windows 7 und auch der
Hardware Player profitieren nicht die Bohne von den Metadaten im Cache. Im Gegenteil. Im Schneckentempo bauen sie nun
ihrerseits noch mehr Metadaten auf. Wenn ich dieses stundenlange Szenario laufen lasse hab ich hinterher tatsächlich
5 GB Metadaten im Speicher. Also aus meiner Laiensicht quasi zweimal die gleiche Information für ein und dieselbe Sache.
Kann das so gewollt sein. Ich glaube nicht. Da wirds dann auch mit 8GB schnell knapp.
Sobald nun irgendeine Kopieraktion läuft werden die Metadaten wieder rausgekickt und ich fang wieder bei Null an.

Gleich mal die relevanten Einstellungen aus meiner Loader.conf für 8GB Speicher

Die Variable -> vfs.zfs.arc_meta_limit
hab ich raufgesetzt weil default 1/4 des ARCs für Metadaten reserviert sind. Das wären bei mir 1.4GB
Da ich aber "mehr" Metadaten im Cache haben wollte und die Variable "meta_limit" im real Betrieb überschritten wurde
hab ich den Wert erhöht. Es hat aber alles keinen Unterschied gemacht.

kern.maxfiles="65536"
kern.maxfilesperproc="50000"
kern.cam.boot_delay="8000"
vm.kmem_size="7G"
vfs.zfs.arc_max="5832M"
vfs.zfs.arc_min="3584M"
vfs.zfs.txg.timeout="5"
vfs.zfs.txg.synctime="1"
vfs.zfs.txg.write_limit_override="1073741824"
vfs.zfs.vdev.min_pending="1"
vfs.zfs.vdev.max_pending="1"
vfs.zfs.prefetch_disable="0"
vfs.zfs.arc_meta_limit="2384M"

Als letzte Idee hab ich dann heute den Primarycache auch auf Metadata gestellt.
Die Idee dahinter ist halt , daß nur noch Metadaten gecached werden. Also auch kein Grund mehr für den ARC sie beim kopieren
aus dem Speicher zu werfen. Das klappt lokal auch. Sind meine 2.5 GB via Find Kommando erstmal wieder aufgebaut
geht der Scan in Sekunden. Ich kann nun auch übers Netz kopieren bis der Arzt kommt und sie bleiben im Primary Cache.
Leider nützt die ganze Idee ja nichts , via geplantem Cron Job , wenn der Sambazugriff nicht gecached wird so wie es meiner
Meinung nach sein sollte. Trotzdem, testweise in den sauren Apfel gebissen und vom Client wieder einen Scan gestartet
über mein MP3 Verzeichnis. Nach langen 7 Minuten dann den zweiten Scan angeworfen. Was soll ich sagen ...
Ich mußte wieder 7 Minuten warten. Nun wird gar nichts mehr gecached.
Der Metadatenspeicher wächst auch nicht mehr wie vorher von 2.5Gb auf bis zu 5GB an. Er bleibt völlig unverändert.
Lokal via Putty SSH geht weiterhin die Post ab. Das ist gelinde gesagt zum kotzen.

Ich habe nur eine Einzige Schlußfolgerung .. und bitte jetzt nicht den Pauschal Hinweis -> mehr RAM.
Selbst wenn Ram immer gut ist, keine Frage. Aber das Board gibt zum einen nicht mehr wie 8GB her laut Doku und zum
anderen ist das für mich ein BUG oder schöner ausgedrückt ein Designfehler, wenn ein Fileserver nicht die Directory Zugriffe cached.

Meine Schlußfolgerung ist die daß Zugriffe von Windows aus über das SMB Protokoll auf der ZFS Seite nicht wie Metadaten gehandled
werden. Da ich ja mit der Einstellung vorher -> Primarycache ALL wenigstens beim zweiten Zugriff eine Beschleunigung hatte
und diese nun völlig wegfällt muß ZFS anscheinend diese Zugriffe wie Daten oder Kopieraktionen interpretieren.

Selbes Phänomen auch vom Hardware Media Player aus zu sehen. Wechsel ins Verzeichnis MP3 -> Buchstabe A ... 15 Sekunden
wieder raus und nochmal rein. Wieder 15 Sekunden. Das war vorher beim zweiten Zugriff nach ca 3 Sekunden da.

Nebenbei gesagt hat die Einstellung Primarycache= Metadata auch die Kopiergeschwindigkeit deutlich reduziert.
Wenns beim Scan geholfen hätte, würde ich damit durchaus leben können.
Aber so wie es sich mir derzeit darstellt , ist das einfach nur Mist. Ich kann mir nicht vorstellen daß das so gewollt ist.

Hab dann heute auch noch das Update auf die 636 Version gemacht. Es hat sich nichts geändert.

Wäre vieleicht jemand so nett und kann ggf versuchen dieses Phänomen auf seinem NAS mal nachzustellen.
Ich hab es extra sehr ausführlich beschrieben. Es sollte relativ einfach nachzuvollziehen sein.

Vieleicht entdeckt ja auch jemand noch einen Bug in meiner Loader.conf.

Nachtrag:
Da ich Samba in Verdacht hatte, hab ich sowohl das SMB2 Protokoll wie auch NT1 mit Async I/O wechselweise ausprobiert.
Bei beiden Protokollvarianten derselbe unangenehme Effekt.

Hier hatte vor 4 Jahren schonmal einer denselben Problemansatz
http://thr3ads.net/zfs-discuss/2008/10/ ... che-almost

Naja das hat nix mit Nas4free zu tun liegt eher am zfs system bzw samba. solange sich da nix ändert schwierig zu sagen.
Da ich eh gerade ne testbox am laufen haben für infiniband, wed ich am we mal testen ob da was geht.

Hast du mal versucht ob das auch auftritt wenn du statt Samba/Cifs NFS nutzt(ja klar keine windows clients aber rein der funktion halber).

Das magst Du Recht haben. Aber wo soll ich die Frage sonst stellen. Leider weiß ich nicht wie ich die Entwickler direkt kontaktieren kann.
Falls Dir ein besseres Forum bekannt sein sollte wo die Frage nicht verpufft , Gerne

NFS
Ich habs vor Wochen mal versucht. Bin aber auf der Windows Seite gescheitert (obwohl W7 Ultimate und Enterprise einen NFS Client haben).
Da mein Hardwareplayer kein NFS kann hab ich es dann aber nicht weiter verfolgt.
Sollte NFS für dich ein Kinderspiel sein wäre es sehr nett wenn Du das ggf ausprobieren könntest.

In der Tat würde das bedeuten daß wenn der Fehler bei NFS nicht auftritt das Problem bei Samba/Cifs liegt.
Andererseits wäre es ein Indikator für ZFS. Mit der Gewissheit könnte man dann entweder an die Samba oder ZFS Entwickler
gezielter die Frage stellen (falls ich sie ausfinding machen kann)

Also ich hab jetzt mal 2 h rumprobiert(geh jetzt erst mal zu ne Party mal sehen ob dann morgen noch was geht), und kann das nicht reproduzieren das funkt einwandfrei bei mir.
Aufbau: Testnas4free 636 ,AMD A6-5400K,8GB Ram, fullinstall auf ner 20GB HDD, 2 160GB Samsung als zfs stripe, 32GB SSD als L2arc.
loader.conf zfs settings Arc und l2arc auf all(standard).
l2arch wird bei mir garnicht für metadaten genutzt weil das alles in den arc passt in meinem Testaufbau.
hab wild draufkopiert 97 Verzeichnisse 31.162 Dateien.Ein großer Testfolder mit 11728 Dateinen(Jpeg).
Ersten lesen des Folders via Samba(Totalcommander) 1min+.(Hdds ratterten auch gut).(hab dann alle Folder über cd Verzeichnisbaum einlesen lassen(TC))
Danach ca 2 sek(kein Hdd zugriff) getestet von Win7 Rechner via kabel und nem Schleppi Win7 via Wlan.
Hab dann paar Mkv 4-20GB insgesamt ca 40gb mehrfach hoch und wieder runtercopiert, blieb dabei folder werden instant geöffnet.
Allerding ist meine metadata menge auch nicht so hoch sind knapp 400mb bei diesen 30k Dateinen Sprich bei 8GB passen ca 100K dateien in den Metacache, wenn du mehr hast und oft suchst hilft nur ram size erhöhen(metadatasize erhöhen...) oder l2arc nutzen.
Dabei ist aber zu beachten das der l2arc ne gewisse warming up zeit braucht sprich wenn der ram voll ist wird nicht instant alles in den l2arch gepackt erst bei mehrfacher nutzung(ka wie genau der Algo funzt).Darüber hinaus ist die schreibperformance bei l2arc gedrosselt auf ca 8mb/s unm den Read nicht auszubremen(dafür is er ja da), sprich der füllt sich langsam.
Das kann man aber auch einstellen, und optimieren.zb
http://forums.freebsd.org/showthread.php?t=29907

Wieviel Dateien hast den ca. eventl morgen sonst mehr draufpacken zum testen bei mir.
Evetl mal nen 2ten stick mit ner neuen install machen und nur mit einem Pool testen mit allem auf standard....

MFG Alex

Ps was mir noch auffällt, hat damit allerdings nichts zu tun das nen E350 natürlich für grosse zfs pools auch bissl schwach ist , is ja quasi wie nen nen oller X2 64 auf 800 Mhz, dazu nur singlechannelmemory denn er sich noch mit der grafik teilt.

Hi, ich hab heute auch noch was vor. Deshalb kann ich nicht ausführlich antworten. Auf der 4TB sind ca 600.000 Dateien.

Aber wir können ruhig bei deinem 31.000 testen. Ich lese zwar heraus daß Du das Caching getestet hast ,
und auch all die anderen Infos sind für mich bestimmt noch sehr nützlich ( aka Schreibperformance auf 8Mb gedrosselt etc etc).
Jedoch vermisse ich den SSH Putty Test am Anfang um meine Kernmeckerei zu untermauern

Mich würde dringend interessieren wie es sich bei Dir äußert wenn Du direkt nach einem Reboot (cache ist dann wieder leer)
via Putty und so einem Find Kommando deine 31000 Dateien scannst.
Ich hab gerade leider nur die Werte im Kopf bei meinen 600.000 Dateien.

1.tes Mal via Putty das Find Beispiel ausgeführt dauert ca 2 Minuten
2.tes Mal Find Kommando dauert dann noch 7 Sekunden (nicht schlecht für olles 800Mhz im SingleChannel, oder ?)
ab da kann ich es aufrufen bis der Arzt kommt. Immer nur 7 Sekunden ...
Die Metadaten liegen bei o.g Dateianzahl dann ungefähr bei 2GB !!
Mein Metadatenlimit ist auf ca 3GB raufgesetzt

Dann, erst dann mache ich den Totalcommander Test via Netzwerk. Hier erwarte ich daß er nun bereits auf die gecachten Informationen
des PrimaryCaches (Ram) zurückgreift. Und genau das passiert nicht.
Ein Scan via Rechtsclick -> Eigenschaften würde, wenn ich ihn durchlaufen lassen würde , dann 2 Stunden dauern (bei 600.000)
Parallel sehe ich daß meine 2GB Metadaten immer mehr werden. Das sollte schon nicht sein. Sie sind ja bereits da !!

Solange der Wert unter 3GB liegt kann ich parallel via Putty immer noch im 7 Sekundentempo suchen !!!
Aber sobald die 3GB überschritten werden , schmeißt der Arc die lokalen Cacheinformationen raus
und dann wirds via Putty irgendwann auch langsam.

Mir geht es darum daß die Metadaten schon drin sind (via Find ein Prefill gemacht) und sich an den 2GB gar nichts mehr ändern sollte !!!
Das ist der entscheidende Punkt. Das sich Caches erst warmlaufen oder mittels abenteuerlichen Algorithmen die kurz vor der KI stehen
später noch ihr Ding machen ... Akzeptiert , zieh ich auch den Hut vor, aber es interessiert mich an dem Punkt gar nicht.

Das müßte sich auch mit 31000 Dateien und logischerweise anderen Sekundenzeiten nachstellen lassen. Wichtig wäre nur die Reihenfolge
um den Effekt nachzustellen. Deine Metadaten müßten sich dann beim ersten Mal auf einen Wert X via Putty und Find einstellen
und sich bei einem späteren Netzzugriff via Totalcommander quasi verdoppeln !

Ich erwarte daß ein Fileserver seinen gefüllten Cache den Clients z.V stell und nicht nur dem lokalen User Root auf der CLI.
Darum gehts. Ein weiterer Test via NFS könnte dann tatsächlich Licht ins dunkle bringen ob dieser Designfehler/Bug im Samba oder ZFS
seine Ursache hat. Dann könnte ich versuchen das Problem zielgerichteter weiterzugeben ...

Vielen Dank aber nochmals, daß Du dir überhaupt die Mühe gemacht hast es nachzustellen. Das finde ich sehr, sehr nett.

Ok habe ich gerade getestet metadaten aufgebaut mit ls -R.
Zugriff via Samba werden neu aufgebaut, also wir bei dir, aber zugriff via nfs kein neuaufbau.
Sprich liegt am samba halt kein unix, windows metadaten sind anderes format und müssen deshalb neu aufgebaut werden.
Also kannst du das ganze nu umgehen via nfs oder indem du sie per netzwerk aufbaust.
Wenn das bei dir so lange dauert hilft nur samba optimieren, Folderstruktur optimieren....
eventl gibts da auch noch erwiterte smb optionen, aber so tief hbb ich jetzt nicht gegraben.

zb http://www.osst.co.uk/forums/samba-slow ... -t843.html
http://www.samba.org/samba/docs/man/Sam ... efile.html
Alternativ gibt es noch den kernel integrierten Cifs/SMB service dieser soll schneller sein bei solchen sachen als samba(man kann wohl weniger einstellen=


Mit verkatertem Gruß Alex

Jetzt bin ich gerade verwirrt, hab noch bissl mit dem l2arc gespielt dabei den pool mal neuerstellt 180k dateien draufgehauen, und jetzt funzt das ganze auch wenn ich mit ls -R über putty scane dann via smb laufwerk reingehe.
Habe das jetzt mehrfach reproduzieren können funktionert einwandfrei. über putty scan Ls -R ann zugriff über SMB .
Folder mit 29k dateinen ca 2s.
Gesamtes Laufwerk 186k Dateinen 17k Verzeichnisse mit Treesize einlesen üner smb ca 12 sek.

Denke du solltest wirklich mal einen anderen stick mit nur einem pool testen mit default werten.

Hallo Alex
Also bei mir ist anhand deiner Tests nun der Knoten geplatzt.
Ich habe gerade über die 4TB Platte einen Scan in 3 Mintuten laufen lassen können. Siehe Anhang.

Es verhält sich so daß ich nach Aufbau des Primary Caches ca 1.99GB Metadaten habe.
Wenn ich nun über den Client via Netzwerk zugreife geht es auch rasend schnell. Die Metadaten wachsen wohl weiterhin noch
an. Daran hat sich nichts geändert. Am Ende hab ich ca 3.6GB Metadaten im Speicher.
Ich habe den Wert Metadata Limit dementsprechend angepasst.

Die Einzigste Änderung die ich hier gemacht habe ist ein Häkchen in den Samba Einstellungen weggenommen.

Dienste -> CIFS/SMB -> Aktiviere Speicherung der DOS-Attribute
Den Haken hatte ich an (warum weiß ich nicht).
Ich hab auch nicht genau verstanden was dann intern wirklich passiert.
Aber sobald ich den Haken wegnehme ist das Problem weg.
Lediglich die Verdopplung des Metaspeichers ist sagen wir mal "unschön". Aber damit kann ich durchaus leben.

Ich werde noch ein bischen feineinstellen und dann zwischendurch auch mal Kopierorgien machen.
Melde mich dann nochmal zurück. Danke für deine Hilfe. Dein NFS Test hat die Suche auf Samba eingegrenzt
und das hat schlußendlich die Wende gebracht.

Hi redline!

Die Attribute hatte ich auch an. Wurde in nem Tutorial zu Active Directory empfohlen, warum auch immer. Standard ist aus.

Diese Attribute sind schreibgeschützt, versteckt und archiv und noch 'system', wie schön zu sehen auf dem Eigenschaftenscreen.

Für mein Verständnis (und ich kenne das noch aus echten DOS-Zeiten) wurde eine versteckte Datei nicht angezeigt, wenn man 'dir' angab.
bei schreibgeschützt wurde doppelt nachgefragt, wenn man sie löschen wollte. Mit den anderen beiden kann ich nichts anfangen.

If this parameter is set, Samba attempts to first read DOS attributes (SYSTEM, HIDDEN, ARCHIVE or READ-ONLY) from a filesystem extended attribute, before mapping DOS attributes to UNIX permission bits. When set, DOS attributes will be stored onto an extended attribute in the UNIX filesystem, associated with the file or directory.

So steht es als Info nebenbei. Ist etwas irreführend, weil die Attribute unter Windows noch Gültigkeit haben. Sie entstammen eben DOS. Dh es sind wohl dann nochmal zusätzliche Metadaten (die Attribute) und mit denen kann ZFS wohl nichts anfangen. Kann man das so interpretieren?

Edit: Active Directory braucht die Attributseinstellungen, sonst geht nichts mehr. Keine Anmeldung, kein Zugriff, nichts. Gemappte Laufwerke laufen ins Leere. Ausserdem im Log: Habs wieder aktiviert, Domänenrejoin gemacht, funzt wieder.

AH jetzt wirds mir auch klar warum es bei mir mal ging und mal nicht hatte das dos häckchen auch einmal an. und wie rostreich schon richtig bemerkt hatte werden dadurch werte gesetzt die nicht mit den normalen zfs metadaten über einstimmen, deshalb doppelt.
AD hatte ich nicht probiert wäre natürlich blöd wenn das nur damit funzt, aber mal schauen in Samba 4 gabs da wohl eh größerer Änderungen.
@Redline jetzt kannst ja nochmal mit l2arch metadata testen sollte ja dann auch funktionieren(eventl. l2arc schreibspeed hochsetzen).

MFG Alex

Es ist ja mit der 636 eine neue Sambaversion integriert worden, daher geht jetzt auch AIO (Spaßfakt: Ich muß immer an Aioli denken, wenn ich das sehe ) und generell der Domänenjoin, was ja vorher ein wahrer Graus war!

Wann soll denn die 4er integriert werden?

Ka muss mal ein Dev was sagen, kann aber dauern das es wohl doch größere Änderungen gab.
Im Samba 4 ist nen richtiger AD server mit drinne.
http://www.heise.de/newsticker/meldung/ ... 66883.html

Habs wieder aktiviert, Domänenrejoin gemacht, funzt wieder

Da bin ich ja beruhigt, daß Du dir nichts zerschossen hast ... beim Versuch mir zu helfen.

Obwohl ich selber lange Zeit Fan von Dos 3.3 und später dann noch Novell Dos war wundert es mich schon daß heute dieser Ballast doch noch
mit rumgeschleppt wird. Noch mehr wundert es allerdings daß ggf so ein Häkchen auch für modernes AD überhaupt eine Rolle spielt.
Wenn ich das richtig verstehe kann ich im Moment froh sein daß ich selber kein AD oder ACL nutze ...

@Jasch
Mit diesen Einstellungen erreich ich anscheinend was ich wollte.
vfs.zfs.arc_max="5832M"
vfs.zfs.arc_min="3600M" <- ob der hier auch richtig gewählt ist bin ich unsicher, funktioniert aber scheinbar
vfs.zfs.arc_meta_limit="3500M"

Eine Cronjob baut nun einmal am Tag (vor dem Rsync Routine Job) die Metadaten auf oder sorgt für einen Refresh.
Ich hab den Wert Limit so gewählt das wirklich alle Metadaten reinpassen und noch etwas Luft bleibt.
Nun kann ich auch kopieren wie ich möchte. Die Metadaten werden in Ruhe gelassen. (vieleicht ist der Cronjob gar nicht mehr notwendig)
Da der Arc nun fürs kopieren nicht mehr soviel abzwackem kann wirkt es sich etwas auf die Kopiergeschwindigkeit aus.
Aber das ist für mich ein guter Kompromiss. Den Directory Scan brauche ich sehr oft und auch Operationen wie Move oder Delete
gehen nun deutlich schneller.
Da auch nach dem Update auf die 636 , das Problem weiter besteht daß ein USB (3.0) Stick als Cache konfiguriert einen Reboot verhindert ,
habe ich den L2Arc nach weiteren Tests erstmal komplett rausgeworfen. Zum Einen sehe ich bei dem angepassten arc_meta_limit
keinerlei Zugriffe (es gibt nichts zum auslagern weil alles reinpasst) und zum zweiten möchte ich nicht bei einem Reboot den
USB Stick immer händisch vorher aus dem Pool entfernen via "zpool remove RZ1 cache da0p1".
Wenn ich das nicht mache bliebe der Rechner nach dem USB Controller Shutdown hängen und ich müßte immer über 3 Etagen laufen.

Derzeit könnte ich das nur einbauen wenn ich wüßte wie ich "zpool add" und "zpool remove" Kommandos , so in Scripts einbauen könnte daß
sie beim Systemstart und Shutdown ausgeführt werden. Bei der Embedded Installation weiß ich nicht wo ich da ansetzen kann.
Viele Konfigurationsdateien werden ja beim Reboot extrahiert und jedes Mal neu erstellt.
Hab noch nicht rausbekommen in welchen Bereichen ich da dauerhaft ändern kann (außer bei der loader.conf).

Wird Samba 4 wenn es mal kommt immer noch Single Threaded sein ?

jasch wrote:Ka muss mal ein Dev was sagen, kann aber dauern das es wohl doch größere Änderungen gab.
Im Samba 4 ist nen richtiger AD server mit drinne.
http://www.heise.de/newsticker/meldung/ ... 66883.html

Gibt es überhaupt deutsche DEVs bei N4F? Außerdem glaube ich nicht, dass die in der German-Section lesen.
Jeppa, die Meldung hatte ich damals auch gelesen und mich wie ein kleines Kind gefreut.
Aber wenn die Sysvol und DNS Replikation noch nicht implementiert wurde und man dann noch etwas in den Kommentaren stöbert kommt man zum Schluß, dass es sich für ne Produktivumgebung noch nicht lohnt. Ich weiß ja nicht, wie es euch geht, aber wenn ich irgendwem was installiere, dann 'trau' ich mich das nur, wenn ich selbst jahrelange Erfahrung mit Fehlermeldungen/Fehlfunktionen der Software habe.
Beispiel N4F-> Das kenn ich mittlerweile so gut und würde es jedem als Filer empfehlen. Wenn dann derjenige anruft und sagt, dass irgendwas hakt, werd ich ihm sicher helfen können. Das beste Beispiel war ja SMB2 und AIO in den älteren Versionen.
Mit Active Directory kenne ich mich mittlerweile auch aus, seit ich mal ins kalte Wasser gestoßen wurde. Als es mit 2k rauskam, hatte das noch keinen Belang für mich.
Ich war bei nem Kunden und 'durfte' ein vollausgebautes AD mit Terminalserver, Exchange, BlackBerry-Server, SQL-Server, Sage, Bandbackup und 3 VPN Standorten aka 500 User administrieren.
Ich hatte mich am Anfang nicht getraut, überhaupt irgendwelche Updates zu installieren und die Kisten zu rebooten, zumal die unter 2k aufgesetzt wurden und man das 2k3 als Update drüberbügelte. Sowas würde ich immer frisch aufsetzen.

Da ich durch meine Tätigkeit immer mal wieder alte Rechner geschenkt bekam (besser mir geben, als zum Schrott fahren ), hab ich mir dann daheim mal ne Testdomäne hingesetzt mit allen sonstigen gängigen Dienste. Viel lesen + Try'n'Error und Effekte am Client beobachten hat mich dann zwar Zeit gekostet, aber ich wurde fitter damit.

Da bin ich ja beruhigt, daß Du dir nichts zerschossen hast ... beim Versuch mir zu helfen.

AD habe ich ja auch wie oben beschrieben mit Try'n'Error eingerichtet und im schlimmsten Fall müßte man das NAS als Domänenmitglied rauswerfen, Samba neustarten, Domäne rejoinen und nen chown übers Dataset jagen. Die feingranulare Freigabeconfig ist ja auf dem Domaincontroller und dem vertraue ich, weil länger gewöhnt.

Obwohl ich selber lange Zeit Fan von Dos 3.3 und später dann noch Novell Dos war wundert es mich schon daß heute dieser Ballast doch noch
mit rumgeschleppt wird.

Die Attribute an sich sind ja kein Ballast, sondern Features (höhö) und UNIXe haben das ja auch. Ob das jetzt auf Fat16, Fat32 oder NTFS abgebildet wird, ist ja schnurz. Bei NTFS kamen ja noch weitere (sinnvolle) Attribute wie das Filelock hinzu und dann eben die Berechtigungssachen, sind alles Attribute.

Wenn ich das richtig verstehe kann ich im Moment froh sein daß ich selber kein AD oder ACL nutze ...

Es funktioniert ja, wenn auch ohne Feintuning. Es sind eben 2 komplett unterschiedliche Systeme und wenn man bedenkt, dass die Sambaentwickler bei der Entwicklung die Netzpakete von einem AD auslesen mußten um das alles zu verstehen und Reengineering betreiben zu können, dann ist es dennoch eine großartige Leistung. Und nochmal weiter weggedacht, ist es freie Software, die nichts kostet. Stille Helden oder so.
Etwas abschweifend: Habe gestern wegen iscsi was googlen müssen und stieß auf einen älteren Thread im administrator Forum, wo irgendeiner ein kommerzielles Storage von der Stange erworben hatte und die Geschwindigkeit unterirdisch war. Im Endeffekt ging das so ab: Er sagte: mein Storage bringt nur Geschwindigkeit X, was tun? Die Patzigkeit ging dann schon los, als wer nach der Raidconfig, den Platten und der Verkabelung fragte. Aus Frust über die Hilfestellung hat der Kasper dann im Vmware Forum den gleichen Thread eröffnet mit dem Hinweis 'guckt mal, was die Leute in dem anderen Forum für doofe Antworten geben'.
Zurück im administrator Forum haben die dortigen User Wind davon bekommen und sich verständlicherweise darüber aufgeregt und dann die Hilfe generell verweigert. Der Protagonist hatte da immer noch kein Einsehen und maulte in Richtung 'ich hab hier eine Produktivumgebung, ihr habt mir zu helfen'. Köstlich! Worauf ich hinauswill ist, dass es hier sehr respektvoll und nett zugeht. Schräge Vögel wie der Protagonist kenne ich auch aus dem RL zuhauf. Am schlimmsten ist es noch, wenn man mit Ihnen zusammenarbeiten muß.

Hast du es mal mit nem USB2.0 Stick versucht? Gute Sticks sind ja immer noch schneller als Platten in der Zugriffszeit. ReadyBoost war ja genau dafür ausgelegt und da gab es noch kein USB3.0.
Ich meine, wenn du ein paar Sticktestberichte liest und dich dann für den schnellsten entscheidest, fährst du ganz gut. Und rausgeschmissenenes Geld isses nicht, der Stick dürfte nicht mehr als 15€ kosten, du hast deinen Test im Rebootfall, ob er blockt oder nicht und sollte der Cache langsamer sein als ohne Stick, dann hast du einen Ersatzstick zum Einlagern für die embedded.

Wird Samba 4 wenn es mal kommt immer noch Single Threaded sein ?

Kein Plan. Im CIFS-Wiki ist nichts zu finden. Da das aber der größte Flaschenhals bei der Sache ist, kann man stark davon ausgehen, dass das geändert wird.

AD habe ich ja auch wie oben beschrieben mit Try'n'Error eingerichtet und im schlimmsten Fall müßte man das NAS als Domänenmitglied rauswerfen, Samba neustarten, Domäne rejoinen und nen chown übers Dataset jagen. Die feingranulare Freigabeconfig ist ja auf dem Domaincontroller und dem vertraue ich, weil länger gewöhnt.

Bahnhof Was immer Du sagst

Bezüglich Attribute hab ich mich wohl falsch ausgedrückt. Es wunderte mich nicht daß diese noch da sind sondern daß anscheinend alte Strukturen und Dos Kompatibilität gewahrt
bleibt. Ich hätte gedacht daß das quasi frisch aufgesetzt wurde.

Ironie AN : Nicht daß der alte Code noch 16 , ach was 8 biitig in einer 64 Bit Emu mitläuft Ironie AUS

Ein USB 2.0 Stick verhielt sich übrigens genauso. Bezüglich Performance hätte ich zu dem hier gegriffen wenn es funktionieren würde.
http://www.hardwareboard.eu/artikel/usb ... st-3979/6/
Der takeMS MEM-Drive Easy III überraschte im Test wohl damit, daß er fast 40% über Herstellerangabe performte.

Ich werd aber bei Zeiten eh mal versuchen meinen Embedded Stick via Acronis zu duplizieren (Ersatz). Bis ich das mit DD kann (oder will) dauert es wohl noch.
Dann teste ich auch mal ob das OS selber vom USB 3.0 arbeiten würde und ob ich ggf den Rest auf dem Stick als Cache nutzen kann.

Worauf ich hinauswill ist, dass es hier sehr respektvoll und nett zugeht.

Schön gesagt. Kann ich nur unterstreichen.

Da der Fall ja quasi geklärt ist könnte ein Mod den Titel ggf in "jawohl, er war zu doof" umändern.
Auf den Dos Attribute Haken wäre ich Alleine in 3 dunklen Wintern nicht gekommen. NFS sein Dank.

Nachtrag :
Hab gerade realisiert daß man über Befehlsscript sowohl beim Start und Shutdown Kommandos ausführen könnte.
Da werd ich mal die Zpool And und Remove Kommandos bei Gelegenheit einbauen und ausprobieren.

Bahnhof Was immer Du sagst

Bezüglich Attribute hab ich mich wohl falsch ausgedrückt. Es wunderte mich nicht daß diese noch da sind sondern daß anscheinend alte Strukturen und Dos Kompatibilität gewahrt
bleibt. Ich hätte gedacht daß das quasi frisch aufgesetzt wurde.

Ironie AN : Nicht daß der alte Code noch 16 , ach was 8 biitig in einer 64 Bit Emu mitläuft Ironie AUS

Ah, ok. Nene, die Attribute sind alle soweit geblieben. Ich kenne mich sooo tief auch nicht in der Materie aus und weiß daher nicht, wie es genau abgespeichert wird. Bin auch ne Programmierniete und in Photoshop, Excel usw. bin ich auch ne Niete.

Ein USB 2.0 Stick verhielt sich übrigens genauso.

Hast du mal die EHCI unterstützung im BIOS ausgemacht? So wie das aussieht, liegt das nicht am Stick sondern an irgendwas, was der Controller hat/macht, was BSD nicht mag.
Oder USB-Legacy mal ausmachen?

Ich werd aber bei Zeiten eh mal versuchen meinen Embedded Stick via Acronis zu duplizieren (Ersatz). Bis ich das mit DD kann (oder will) dauert es wohl noch.

dd if=/dev/ad1 (quellstick) of=/dev/ad2 (zielstick)

Das sollte es gewesen sein.
dd steht ja für diskdump, also wirklich raw r/w.

Bei Acronis wirst du aber ne Sector-by-Sector-Kopie machen müssen. USB Sticks und Bootsektor sind immer ne Sache für sich. Dh auch, dass die Partition statisch bleibt und nicht bei einem größeren Stick verhältnismäßig vergrößert wird.
Das nur als Anekdote, falls es nicht hinhaut und du keinen Anhaltspunkt hast. Würde mich aber freuen, wenn du das mit dem normalen Klonvorgang mal testest und berichtest.

Dann teste ich auch mal ob das OS selber vom USB 3.0 arbeiten würde und ob ich ggf den Rest auf dem Stick als Cache nutzen kann.

Würde da nicht lange rummachen und 2 Sticks, für jeden Einsatz einen, nehmen.
Mir rollen sich da auch immer bös' die Fußnägel, wenn hier danach gefragt wird, ob man n4f auf HD insten kann und wie man dann per Partition den Rest der Platte für Nutzspeicher nimmt. -> Ist halt einfach nicht sauber und wenn die Platte dann 2 Xe in den Augen hat, ist das Geschrei eh groß. Hat bis auf die zentrale Erreichbarkeit im Netz dann keinen Unterschied zu ner externen Festplatte.
Und bei der Bucht kann man nen Stick oder ne 20 GB Festplatte immer fürn 5er schießen.

Da der Fall ja quasi geklärt ist könnte ein Mod den Titel ggf in "jawohl, er war zu doof" umändern.

Kannst du doch selbst ändern (??), finde nicht, dass es nem Mod so zusteht.

Auf den Dos Attribute Haken wäre ich Alleine in 3 dunklen Wintern nicht gekommen. NFS sein Dank.

Jeppa, ich fühlte mich erschlagen, als ich die CIFS Einstellungen zum ersten Mal sah. Wahrscheinlich kommen mit Samba4 nochmal 50 neue Einstellungen hinzu, wo man x mit y nicht kombinieren darf. Hast du mal die Feineinstellungen vom ESXi gesehen? Komm ungefähr hin.

Hab gerade realisiert daß man über Befehlsscript sowohl beim Start und Shutdown Kommandos ausführen könnte.
Da werd ich mal die Zpool And und Remove Kommandos bei Gelegenheit einbauen und ausprobieren.

Das ist nicht neu? Geht bei jedem unixoiden Gedöhns.
Aber ich lerne auch nie aus.