OT: FreeNAS Bootzeit mehr als 31 Minuten - wo nachschauen?

[Marc Stibane]

Wie parallel schon beschrieben hat mein N54L letzte Nacht die letzte 4TB
resilvert. Heute morgen war dann im Poolauch nur noch 63% belegt statt
vorher (mit den 3TB-Platten) 82%. Weil die Toshiba außen am eSATA ohne
Luftstrom zu warm (42 Grad im Idle) wurde, habe ich sie einfach mit der
Seagate in Tray-0 getauscht. Jetzt sind alle Platten im Idle zwischen 34
und 37 Grad.

Aber der Server ist auf einmal furchtbar lahm. Ich wollte unter View
Disks in die Description reinschreiben, an welchem Port die Platten
jeweils hängen (Tray0..3, eSATA, ODD), damit man bei Ausfall einer
Platte einfach nachschauen kann welcher Port fehlt (die Angaben
ada0..ada5 sind ja sinnlos, da bei Ausfall einer Platte die höheren
einfach "nachrücken" und somit immer ada5 fehlt, auch wenn z.B. ada2
ausgefallen ist) - und das Schließen des Edit-Fensters dauert Minuten...

Daraufhin habe ich die Kiste ausgeschaltet und mal nachgeschaut was beim
Booten so passiert (VGA-Monitor ist angeschlossen):
1) Das komplette Booten dauert mehr als 31 Minuten.
2) Nach ca. 5 Minuten ist er bei "Starting Network", dann kommt
"Starting devd". und dann passiert 10 Minuten lang nichts.
3) Dann passiert wieder 2-3 Minuten lang was (weitere Statusmeldungen),
und schließlich kommt "Waiting up to 5 seconds for ixdiagnose to
finish... done" und es passiert wieder 11-12 Minuten lang nix bevor es
weitergeht.
4) Nach fast 32 Minuten ist endlich das Konsolenmenü da.

Bis gestern (fünf 4TB Platten resilvert) dauerte das Booten "nur" ca. 5
Minuten (wie gewohnt). Erst heute (nachdem die letzte 4TB Platte fertig
ist) ist es so lahm.

Hat jemand einen Tip wo ich nachschauen kann was da so bremst?
Der Boot-USB-Stick ist nur 4GB groß. Kann es sein dass der voll ist
(logs, updates) und deswegen alles hängt? Wenn ja, wie bekomme ich da
was freigeräumt?

[Thomas Kaiser]

Post by Marc Stibane
Der Boot-USB-Stick ist nur 4GB groß. Kann es sein dass der voll ist
(logs, updates) und deswegen alles hängt?

Ja, klar könnte das sein. Hast Du mal geguckt ("df -h")? Um Platzfresser
zu identifizieren, das "übliche Vorgehen". Man wechselt als root nach /
und dann

du -shx *

(das -x verhindert, dass du -- "disk usage" -- in anderen Partitionen
bzw. auf die Platten klettert, die anderen Parameter siehe man page:
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/du.1 )

Und dann wechselt man dorthin, wo einen Details interessieren, bspw.
/var/db und dann eben wieder "du -shx *" (Achtung, der "*" unterschlägt
natürlich alles, dessen Name mit einem Punkt beginnt, d.h. ggf. separat
per "ls -la" erstmal im jeweiligen Verzeichnis vorab prüfen, ob da sowas
drinliegt)

Gruss,

Thomas

[Marc Stibane]

Marc Stibane schrieb am 17.03.2015

Post by Marc Stibane
Der Boot-USB-Stick ist nur 4GB groß. Kann es sein dass der voll ist
(logs, updates) und deswegen alles hängt?

Ja, klar könnte das sein. Hast Du mal geguckt ("df -h")?

[***@freenas ~]# df -h
Filesystem Size Used Avail Capacity
freenas-boot/ROOT/FreeNAS-9.3 946M 945M 1.0M 100% /
devfs 1.0k 1.0k 0B 100% /dev
tmpfs 32M 5.3M 26M 17% /etc
tmpfs 4.0M 8.0k 4M 0% /mnt
tmpfs 2.6G 32M 2.6G 1% /var
freenas-boot/grub 8.8M 7.8M 1.0M 89% /boot/grub
zpool6 5.1T 192k 5.1T 0% /mnt/zpool6
zpool6/Moof 14T 9T 5.1T 64% /mnt/zpool6/Moof
zpool6/.system 5.1T 296M 5.1T 0% /var/db/system
zpool6/.system/cores 5.1T 1.1M 5.1T 0% db/system/cores
zpool6/.system/samba4 5.1T 303k 5.1T 0% db/system/samba4

sowie noch
/var/db/system/syslog-f36704f2fe794cb6a75657843255655d
und
/var/db/system/rrd-f36704f2fe794cb6a75657843255655d
die ebenfalls unterhalb von zpool6/.system liegen, also 5.1T free.

Der ersten Zeile entnehme ich, dass / zu 100% voll ist. Aber das belegt
nur 1GB des 4GB USB-Sticks. /var ist 2.6GB groß...
Klingt irgendwie nicht sinnvoll...

Um Platzfresser zu identifizieren, das "übliche Vorgehen". Man wechselt
als root nach / und dann
du -shx *

[***@freenas /]# du -shx .rnd *
1.5k .rnd
6.5k COPYRIGHT
1.2M bin
72M boot
512B boot.config
1.5k cfg
19M conf
11M data
4.0k dev
4.5k entropy
5.5M etc
512B home
9.4M lib
130k libexec
1.5k media
8.5k mnt
1.5k proc
6.2M rescue
37k root
6M sbin
512B sys
512B tmp
829M usr
32M var

Und dann wechselt man dorthin, wo einen Details interessieren, bspw.
/var/db und dann eben wieder "du -shx *" (Achtung, der "*" unterschlägt
natürlich alles, dessen Name mit einem Punkt beginnt, d.h. ggf. separat
per "ls -la" erstmal im jeweiligen Verzeichnis vorab prüfen, ob da sowas
drinliegt)

in / sind keine unsichtbaren Ordner. Berücksichtigt "du" solche denn,
wenn es rekursiv durchgeht? Oder sind die Zahlenwerte jeweils nur die
"sichtbaren" Sachen?

Das Problem ist also /usr. Wenn ich da weiterschaue (no invisibles)

[***@freenas /usr]# du -shx *
19M bin
7.6M lib
1.8M libexec
784M local
10k pbi
8.8M sbin
9.0M share

ist nur /usr/local (no invisibles) mit 784MB relevant:

[***@freenas /usr]# du -shx local/*
83M local/bin
512B local/etc
181k local/include
482M local/lib
183k local/libdata
25M local/libexec
38k local/openssl
41M local/sbin
67M local/share
83M local/www
835k local/x86_64-portbld-freebsd9.3

und darin ist der größte Brocken /usr/local/lib, worin sich halt ein
paar Dutzend Libraries tummeln. In /usr/local/bin dasselbe mit binaries.
Der Rest ist Kleinkram.


Sieht alles venünftig aus, IMHO. Oder?

Dann noch /var (no invisibles):

[***@freenas /var]# du -shx *
0B account
0B agentx
4.0k at
4.0k audit
0B authpf
1.9M backups
4.0k cache
8.0k crash
4.0k cron
29M db
0B empty
840k etc
0B games
0B heimdal
4.0k lib
4.0k log
8.0k log.20150317124406
4.0k mail
4.0k md_size
8.0k msgs
20k named
24k netatalk
24k pbi
0B preserve
112k run
0B rwho
16k spool
32k tmp
32k yp

Fast leer, nur /var/db ist 29MB groß.


Bleibt schließlich nur die Frage warum / nur knapp 1GB groß ist (und das
fast leere /var 2.6GB) - und wie man das ändern kann.

[Marc Stibane]

Post by Marc Stibane
Bleibt schließlich nur die Frage warum / nur knapp 1GB groß ist (und das
fast leere /var 2.6GB) - und wie man das ändern kann.

Im FreeNAS Web-GUI sehe ich unter System->Boot 6 Zeilen:
Default, Wizard, und 4 verschiedene FreeNAS-9.3-STABLE Versionen.
Ich habe da mal die ältesten 2 (201412312006 und 201501162230) gelöscht.

[***@freenas /]# df -h
Filesystem Size Used Avail Capacity
freenas-boot/ROOT/FreeNAS-9.3-STABLE 2.2G 945M 1.2G 43% /

das sieht doch gleich vieeeel besser aus...

[Thomas Kaiser]

Post by Marc Stibane

Post by Marc Stibane
Bleibt schließlich nur die Frage warum / nur knapp 1GB groß ist (und das
fast leere /var 2.6GB) - und wie man das ändern kann.

Default, Wizard, und 4 verschiedene FreeNAS-9.3-STABLE Versionen.

Ah, stimmt. Inzwischen liegt ja auch das rootfs auf ZFS und vor dem
Einspielen jedes Updates macht FreeNAS automatisch einen Snapshot, in
den dann auch per GRUB wieder gebootet werden kann, falls das Update
irgendwas versemmelt haben sollte bzw. man das prüfen will.

Post by Marc Stibane
Ich habe da mal die ältesten 2 (201412312006 und 201501162230) gelöscht.

Da kann man eigentlich immer alles außer dem letzten als funkionierend
bekannten Snapshot löschen. Fänd ich sogar sinnvoll, wenn FreeNAS das
bei Platz- knappheit selbst machen würde.

Post by Marc Stibane
das sieht doch gleich vieeeel besser aus...

Und wurde damit die Boot-Performance wieder restauriert?

Gruss,

Thomas

[Marc Stibane]

Post by Thomas Kaiser

Post by Marc Stibane
Default, Wizard, und 4 verschiedene FreeNAS-9.3-STABLE Versionen.

Ah, stimmt. Inzwischen liegt ja auch das rootfs auf ZFS und vor dem
Einspielen jedes Updates macht FreeNAS automatisch einen Snapshot, in
den dann auch per GRUB wieder gebootet werden kann, falls das Update
irgendwas versemmelt haben sollte bzw. man das prüfen will.

Genau. Und das allerneuste Update war noch gar nicht vollständig
installiert, weswegen der N54L noch auf einer zwei Wochen alten Version
lief.
Jetzt läuft er auf der aktuellen 9.3-Stable, und die zeigt auch endlich
an wieviel Platz auf dem USB-Stick (überhaupt und) belegt ist.

Post by Thomas Kaiser

Post by Marc Stibane
Ich habe da mal die ältesten 2 (201412312006 und 201501162230) gelöscht.

Da kann man eigentlich immer alles außer dem letzten als funkionierend
bekannten Snapshot löschen. Fänd ich sogar sinnvoll, wenn FreeNAS das
bei Platz- knappheit selbst machen würde.

Jupp. Allgemein kann man bei automatisch erstellten Snapshots ja
angeben, wie lange die aufgehoben werden sollen (default = 2 weeks),
aber ein Ausdünnen wie TimeMachine es kann wäre natürlich noch viel
besser.

Post by Thomas Kaiser

Post by Marc Stibane
das sieht doch gleich vieeeel besser aus...

Und wurde damit die Boot-Performance wieder restauriert?

Ja, die Kiste bootet wieder in <2 Minuten.

Case closed.

[Marc Stibane]

Post by Thomas Kaiser

Post by Marc Stibane
Default, Wizard, und 4 verschiedene FreeNAS-9.3-STABLE Versionen.

Ah, stimmt. Inzwischen liegt ja auch das rootfs auf ZFS und vor dem
Einspielen jedes Updates macht FreeNAS automatisch einen Snapshot, in
den dann auch per GRUB wieder gebootet werden kann, falls das Update
irgendwas versemmelt haben sollte bzw. man das prüfen will.

Hmm - wäre das Bootvolume dann nicht ein idealer Kandidat für
Deduplication? Bei einem 4GB USB-Stick sollte die dafür nötige Tabelle
auch locker ins RAM (8GB) passen...

Post by Thomas Kaiser

Post by Marc Stibane
habe da mal die ältesten 2 (201412312006 und 201501162230) gelöscht.

Da kann man eigentlich immer alles außer dem letzten als funkionierend
bekannten Snapshot löschen. Fänd ich sogar sinnvoll, wenn FreeNAS das
bei Platz- knappheit selbst machen würde.

Da sich die einzelnen FreeNAS-Versionen wohl nur marginal voneinander
unterscheiden, wäre das mit Deduplication gar nicht mehr nötig.

[Thomas Kaiser]

Post by Marc Stibane
Hmm - wäre das Bootvolume dann nicht ein idealer Kandidat für
Deduplication? Bei einem 4GB USB-Stick sollte die dafür nötige Tabelle
auch locker ins RAM (8GB) passen...

"The dedup tables used during deduplication need ~8 GB of RAM per
1TB of data to be deduplicated"

Für ein Dataset mit randvollen 4 GByte braucht's also sensationelle 32
MByte RAM. Hmm... das schreit nach

zfs set dedup=on freenas-boot/ROOT

oder

zfs set dedup=verify freenas-boot/ROOT

(nachdem Du im FreeNAS-Manual nach »dedup« gesucht und alles mit
Verstand durchgelesen hast :-)

Post by Marc Stibane

Post by Thomas Kaiser

Post by Marc Stibane
habe da mal die ältesten 2 (201412312006 und 201501162230) gelöscht.

Da kann man eigentlich immer alles außer dem letzten als funkionierend
bekannten Snapshot löschen. Fänd ich sogar sinnvoll, wenn FreeNAS das
bei Platz- knappheit selbst machen würde.

Da sich die einzelnen FreeNAS-Versionen wohl nur marginal voneinander
unterscheiden, wäre das mit Deduplication gar nicht mehr nötig.

Äh, doch bzw. Abwägungssache. Wenn Du 30 Snapshots machst und jeweils
sich ca. 1 GByte Daten ändert, dann müssen die dedup-Tabellen schon die
Hashes von 30 GByte speichern obwohl das alles Dank Deduplizierung ja
noch prima auf den 4 GByte Stick paßt. Die dedup-Tabelle würde nach
obiger Schätzungs-Formel dann schon 240 MByte belegen. Außerdem ist mit
Deduplizierung dann wiederum das Löschen von Snapshots CPU- und I/O-
intensiv (anlegen lassen die sich mit null Aufwand, loswerden dann nur
unter Schmerzen... naja, so wild ist es nicht aber es kostet eben
Ressourcen)

Hmm... ich hab grad nur produktive FreeNAS im Zugriff, wäre prima, wenn
Du Deine Installation für einen Test opfern könntest :-)

Immer per "zfs list" und "zfs get all name/des/dataset" parallel gucken.

Gruss,

Thomas

[Marc Stibane]

Post by Thomas Kaiser

Post by Marc Stibane
Hmm - wäre das Bootvolume dann nicht ein idealer Kandidat für
Deduplication? Bei einem 4GB USB-Stick sollte die dafür nötige
Tabelle auch locker ins RAM (8GB) passen...

"The dedup tables used during deduplication need ~8 GB of RAM per
1TB of data to be deduplicated"
Für ein Dataset mit randvollen 4 GByte braucht's also sensationelle 32
MByte RAM. Hmm... das schreit nach
zfs set dedup=on freenas-boot/ROOT
oder
zfs set dedup=verify freenas-boot/ROOT
(nachdem Du im FreeNAS-Manual nach »dedup« gesucht und alles mit
Verstand durchgelesen hast :-)

Hatte ich eh schonmal gemacht (deswegen ja auch diese Idee) - und für
meinen Film-Pool gleich verworfen - da gibt es (hoffentlich) exakt NULL
Duplikate.

Post by Thomas Kaiser

Post by Marc Stibane

Post by Thomas Kaiser
Da kann man eigentlich immer alles außer dem letzten als
funkionierend bekannten Snapshot löschen. Fänd ich sogar sinnvoll,
wenn FreeNAS das bei Platz- knappheit selbst machen würde.

Da sich die einzelnen FreeNAS-Versionen wohl nur marginal voneinander
unterscheiden, wäre das mit Deduplication gar nicht mehr nötig.

Äh, doch bzw. Abwägungssache. Wenn Du 30 Snapshots machst und jeweils
sich ca. 1 GByte Daten ändert, dann müssen die dedup-Tabellen schon die
Hashes von 30 GByte speichern obwohl das alles Dank Deduplizierung ja
noch prima auf den 4 GByte Stick paßt.

Das kann nicht stimmen. Es wird ja wohl hoffentlich nur der Hash jedes
existierenden Blocks_im_Pool im RAM gespeichert, so dass wenn ein neuer
Block geschrieben werden soll erst der Hash berechnet wird, dann
nachgesehen wird ob der schon im RAM existiert, und wenn ja der Block
eben nicht selber neu in den Pool geschrieben wird sondern ins
File-directory die Block-ID des bereits existierenden, inhaltsgleichen
Blocks aufgenommen wird. Das File-directory hätte ja eh eine Liste von
vom File belegten Blöcken enthalten, nur dass jetzt da Block-IDs
drinstehen die eben auch von anderen Files belegt werden.

Post by Thomas Kaiser
Die dedup-Tabelle würde nach obiger Schätzungs-Formel dann schon 240 MByte
belegen.

Die Anzahl unterschiedlicher Blöcke_im_Pool wird aber niemals größer als
4GB/Blocksize, somit braucht auch kein weiterer Hash-Eintrag ins RAM.

Post by Thomas Kaiser
Außerdem ist mit Deduplizierung dann wiederum das Löschen von
Snapshots CPU- und I/O- intensiv (anlegen lassen die sich mit null
Aufwand, loswerden dann nur unter Schmerzen... naja, so wild ist es nicht
aber es kostet eben Ressourcen)

Man braucht für jeden Block einen usage-counter, der dekrementiert wird
wenn ein File gelöscht wird welches diesen Block enthält, und der Block
selber wird freigegeben wenn der usage_counter Null wird.
Also im Prinzip dasselbe Verfahren wie bei SoftLinks, nur eben auf
Block- und nicht auf File-Ebene.

Post by Thomas Kaiser
Hmm... ich hab grad nur produktive FreeNAS im Zugriff, wäre prima, wenn
Du Deine Installation für einen Test opfern könntest :-)
Immer per "zfs list" und "zfs get all name/des/dataset" parallel gucken.

Ich habe mal einen Thread diesbezüglich im FreeNAS-Forum erstellt - mal
sehen was die Gurus dazu sagen:
https://forums.freenas.org/index.php?threads/boot-usb-stick-with-deduplication-anyone-done-this.28523/

Und ich werde mir erst mal einen zweiten USB-Stick (mit 8GB ;-)
besorgen, der ohne Dedup laufen wird, den existierenden Boot-Stick drauf
klonen, und dann beim alten 4GB-Stick dedup=on setzen...

[Thomas Kaiser]

Post by Marc Stibane

Post by Thomas Kaiser
Äh, doch bzw. Abwägungssache. Wenn Du 30 Snapshots machst und jeweils
sich ca. 1 GByte Daten ändert, dann müssen die dedup-Tabellen schon
die Hashes von 30 GByte speichern obwohl das alles Dank Dedupli-
zierung ja noch prima auf den 4 GByte Stick paßt.

Das kann nicht stimmen. Es wird ja wohl hoffentlich nur der Hash jedes
existierenden Blocks_im_Pool im RAM gespeichert, so dass wenn ein neuer
Block geschrieben werden soll erst der Hash berechnet wird, dann
nachgesehen wird ob der schon im RAM existiert, und wenn ja der Block
eben nicht selber neu in den Pool geschrieben wird sondern ins
File-directory die Block-ID des bereits existierenden, inhaltsgleichen
Blocks aufgenommen wird.

Es werden DDT angelegt und da kostet jeder Eintrag 320 Byte. Man kann
sich das mittels zdb auch aus- bzw. vorrechnen lassen:

http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-size-zfs-dedup-1354231.html

Post by Marc Stibane

Post by Thomas Kaiser
Die dedup-Tabelle würde nach obiger Schätzungs-Formel dann schon 240
MByte belegen.

Die Anzahl unterschiedlicher Blöcke_im_Pool wird aber niemals größer als
4GB/Blocksize, somit braucht auch kein weiterer Hash-Eintrag ins RAM.

Die Pointer müssen eben verwaltet werden. Wie groß die wiederum
ausfallen, weiß ich nicht.

Post by Marc Stibane
Man braucht für jeden Block einen usage-counter, der dekrementiert wird
wenn ein File gelöscht wird welches diesen Block enthält, und der Block
selber wird freigegeben wenn der usage_counter Null wird.
Also im Prinzip dasselbe Verfahren wie bei SoftLinks, nur eben auf
Block- und nicht auf File-Ebene.

Wie auch immer, meine Dedup-Experimente mit dicken Datasets sind schon
lange her und gerade das Löschen von Snapshots, wenn Deduplizierung
aktiv war, war extrem "teuer". Hat eine M5000 mit IIRC 24 CPU-Cores
spürbar niedergerungen.

Post by Marc Stibane
Ich habe mal einen Thread diesbezüglich im FreeNAS-Forum erstellt - mal
https://forums.freenas.org/index.php?threads/boot-usb-stick-with-deduplication-anyone-done-this.28523/

LOL, die üblichen "erwartbaren" Reaktionen ;-)

Post by Marc Stibane
Und ich werde mir erst mal einen zweiten USB-Stick (mit 8GB ;-)
besorgen, der ohne Dedup laufen wird, den existierenden Boot-Stick
drauf klonen, und dann beim alten 4GB-Stick dedup=on setzen...

Bin schon gespannt...

Gruss,

Thomas>

[Marc Stibane]

Marc Stibane schrieb am 19.03.2015

Post by Marc Stibane
Ich habe mal einen Thread diesbezüglich im FreeNAS-Forum erstellt -
https://forums.freenas.org/index.php?threads/boot-usb-stick-with-deduplication-anyone-done-this.28523/

LOL, die üblichen "erwartbaren" Reaktionen ;-)

Am Ende wird's doch sinnvoll.

Post by Marc Stibane
Und ich werde mir erst mal einen zweiten USB-Stick (mit 8GB ;-)
besorgen, der ohne Dedup laufen wird, den existierenden Boot-Stick
drauf klonen, und dann beim alten 4GB-Stick dedup=on setzen...

Bin schon gespannt...

Wenn eine neue Version dadurch erzeugt wird, dass man einen Snapshot
macht und dann nur die geänderten Files überschreibt, ist dedup sinnlos,
weil keine identischen Blöcke existieren werden.

Habe einen 8GB-Stick gefunden, den aber nicht geklont (weil es mehrere
Threads im Forum gibt die davor warnen, samt User-Berichten dass es dann
zu Problemen kommt - wahrscheinlich weil die UUID mitgeklont wird),
sondern stattdessen zum Bootdevice attached, also ein RAID-1 erzeugt.
Resilvering, 68% done, 40min remaining... (was zur Hölle dauert so
lange? Sind doch nur 3.6GB...)

Werde mich überzeugen dass von beiden Sticks (ohne den anderen) gebootet
werden kann, und dann den 4er in die Ecke legen (als Notreserve), vom
8er booten, im 6er-Festplattenpool ein temporäres 8GB File anlegen, als
disk mounten, den 4er damit replacen (womit der Boot-Pool nach dem
Resilvern auch 8GB groß wird), dann offline setzen und löschen. Und
schließlich den 8er alleine (degraded pool) benutzen, und evtl. bei
Gelegenheit einen weiteren 8er besorgen und die offline gesetzte "disk"
dadurch ersetzen. Eilt aber nicht...

[Thomas Kaiser]

Post by Marc Stibane

Marc Stibane schrieb am 19.03.2015

Post by Marc Stibane
Ich habe mal einen Thread diesbezüglich im FreeNAS-Forum erstellt -
https://forums.freenas.org/index.php?threads/boot-usb-stick-with-deduplication-anyone-done-this.28523/

LOL, die üblichen "erwartbaren" Reaktionen ;-)

Am Ende wird's doch sinnvoll.

Stimmt, Snapshots arbeiten ja auf identischer Basis, da kann
Deduplizierung schon "by design" nichts bringen :-)

Post by Marc Stibane
Habe einen 8GB-Stick gefunden

"Gefunden"?

Post by Marc Stibane
Resilvering, 68% done, 40min remaining... (was zur Hölle dauert so
lange? Sind doch nur 3.6GB...)

Vorher wenigstens einmal h2testw.exe auf die komplette Kapazität
losgelassen (zur Not in einer VM am Mac, die den Stick per USB
durchgereicht kriegt)? Ich bin regelmäßig amüsiert, wieviele USB-Sticks
wohl thermische Probleme haben und deren Kurzzeit-Performance von 20
MByte/sek brutal einbricht, sobald man viel drauf schreibt (vermutlich
weil das Ding dann überhitzt und Throttling einsetzt -- das Problem hast
Du ja bei so gut wie allen Flash-basierten Medien, dass deren Controller
runterschalten, wenn ihnen Kraft Dauerbeanstandung zu heiß wird )

Gruss,

Thomas

[Marc Stibane]

Marc Stibane schrieb

Post by Marc Stibane
Habe einen 8GB-Stick gefunden

"Gefunden"?

In einer Schublade. Eigentlich war ich auf der Suche nach meinen beiden
99er SoFi-Brillen, aber die habe ich nicht gefunden. Egal, hier in Wien
waren eh nur 2/3 Abdeckung und es war taghell.

Post by Marc Stibane
Resilvering, 68% done, 40min remaining... (was zur Hölle dauert so
lange? Sind doch nur 3.6GB...)

Vorher wenigstens einmal h2testw.exe auf die komplette Kapazität
losgelassen (zur Not in einer VM am Mac, die den Stick per USB
durchgereicht kriegt)?

Nö. Einfach ge-mirror-t.

Ich bin regelmäßig amüsiert, wieviele USB-Sticks
wohl thermische Probleme haben und deren Kurzzeit-Performance von 20
MByte/sek brutal einbricht, sobald man viel drauf schreibt

Am Ende dauerte es 15 Minuten für die letzten 2%, wobei ein "zpool
status" in der shell immer estimated time 2Min angab.

Alles funktioniert, aber der Pool ist degraded (logisch, der 4GB Stick
liegt ja jetzt als Reserve in der Schublade) und nur 3.6GB groß (auch
logisch).
Muss demnächst mal einen weiteren 8GB-Stick besorgen, und den
(unavailable) 4GB damit replacen. Dann habe ich einen mirrored Boot-Pool
mit zwei 8GB-Sticks, und für Notfälle eben den 4GB-Stick.

In der Zwischenzeit würde ich aber gerne den (degraded) Boot-Pool des
8GB-Sticks von 3.6GB auf 7.2GB oder so vergrößern. Der Stick wird als
7.7GB Device angezeigt.
Meine Idee war, eine virtuelle Disk mit 7.2GB zu erzeugen (als Datei auf
dem Datenpool /mnt/zpool6), diese zu mounten, den (unavailable)
4GB-Stick dadurch zu ersetzen, Resilvern... Anschließend sollte der
Boot-Pool 7.2GB groß sein. Danach die virtuelle Disk auf Offline setzen
und löschen.

Kann mir jemand einen Tip geben wie man unter FreeNAS eine virtuelle
Disk anlegt und mountet?

[Marc Stibane]

Post by Marc Stibane
In der Zwischenzeit würde ich aber gerne den (degraded) Boot-Pool des
8GB-Sticks von 3.6GB auf 7.2GB oder so vergrößern. Der Stick wird als
7.7GB Device angezeigt.
Meine Idee war, eine virtuelle Disk mit 7.2GB zu erzeugen (als Datei auf
dem Datenpool /mnt/zpool6), diese zu mounten, den (unavailable)
4GB-Stick dadurch zu ersetzen, Resilvern... Anschließend sollte der
Boot-Pool 7.2GB groß sein.

Satz mit X: Autoexpand funktioniert (momentan) nicht für Bootgeräte...

Also habe ich durch das Mirror-n des 4GB-Sticks auf dem 8GB-Stick auch
nicht mehr Platz.

[Patrick Kormann]

Post by Marc Stibane
Also habe ich durch das Mirror-n des 4GB-Sticks auf dem 8GB-Stick auch
nicht mehr Platz.

Konfiguration sichern, neu installieren, Konfiguration zurückladen.
Dauert nun auch nicht so lange ;)

[Gerald E:scher]

Post by Thomas Kaiser
Vorher wenigstens einmal h2testw.exe auf die komplette Kapazität
losgelassen (zur Not in einer VM am Mac, die den Stick per USB
durchgereicht kriegt)?

F3 leistet das gleiche, ohne dass eine VM nötig wäre.
http://oss.digirati.com.br/f3/

[Thomas Kaiser]

Post by Gerald E:scher

Post by Thomas Kaiser
Vorher wenigstens einmal h2testw.exe auf die komplette Kapazität
losgelassen (zur Not in einer VM am Mac, die den Stick per USB
durchgereicht kriegt)?

F3 leistet das gleiche, ohne dass eine VM nötig wäre.
http://oss.digirati.com.br/f3/

Prima, Danke für die Ergänzung. Was mir da allerdings fehlt, ist eine
kontinuierliche Anzeige der Schreibgeschwindigkeit. Bei h2testw.exe
bekommt man immer so schön mit, wann das Throttling einsetzt und
vermeintlich schnelle Karten oder Sticks zur lahmen Ende mutieren, wenn
man viele Daten am Stück draufschreibt.

Oder laß ich mich grad von der Beispielausgabe täuschen und f3write /
f3read geben nicht nur am Ende "Average speed" aus sondern permanent?

Gruss,

Thomas

[Gerald E:scher]

Post by Thomas Kaiser

Post by Gerald E:scher
F3 leistet das gleiche, ohne dass eine VM nötig wäre.
http://oss.digirati.com.br/f3/

Prima, Danke für die Ergänzung. Was mir da allerdings fehlt, ist eine
kontinuierliche Anzeige der Schreibgeschwindigkeit. Bei h2testw.exe
bekommt man immer so schön mit, wann das Throttling einsetzt und
vermeintlich schnelle Karten oder Sticks zur lahmen Ende mutieren, wenn
man viele Daten am Stück draufschreibt.
Oder laß ich mich grad von der Beispielausgabe täuschen und f3write /
f3read geben nicht nur am Ende "Average speed" aus sondern permanent?

f3write zeigt die Schreibgeschwindigkeit permanent an, f3read WIMRE nur
am Ende die durchschnittliche Lesegeschwindigkeit.

[Patrick Kormann]

Post by Gerald E:scher
f3write zeigt die Schreibgeschwindigkeit permanent an, f3read WIMRE nur
am Ende die durchschnittliche Lesegeschwindigkeit.

Ja. Z.B. so:

Creating file 2.h2w ... 9.44% -- 16.66 MB/s -- 14:08

Read dann so
SECTORS ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/ 0/ 0/ 0
Validating file 2.h2w ... 1737926/ 0/ 0/ 0

Data OK: 1.83 GB (3835078 sectors)
Data LOST: 0.00 Byte (0 sectors)
Corrupted: 0.00 Byte (0 sectors)
Slightly changed: 0.00 Byte (0 sectors)
Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 31.36 MB/s

[Juergen P. Meier]

Post by Thomas Kaiser

Post by Marc Stibane
Der Boot-USB-Stick ist nur 4GB groß. Kann es sein dass der voll ist
(logs, updates) und deswegen alles hängt?

Ja, klar könnte das sein. Hast Du mal geguckt ("df -h")? Um Platzfresser
zu identifizieren, das "übliche Vorgehen". Man wechselt als root nach /
und dann
du -shx *
/var/db und dann eben wieder "du -shx *" (Achtung, der "*" unterschlägt
natürlich alles, dessen Name mit einem Punkt beginnt, d.h. ggf. separat
per "ls -la" erstmal im jeweiligen Verzeichnis vorab prüfen, ob da sowas
drinliegt)

Oder in der Form: (oft benutzt):
du -kx . | sort -rn | less

-k = Anzeige in Kilobytes, human-readable ist leider nicht sortierbar

Verzeichnisse enthalten auch immer die Summe aller Unterverzeichnisse.