gvinum und growfs - FS defekt

rfolkerts

Well-Known Member
Hi,

ich hatte vor einigen Jahren (war IMHO ~2006) wegen gvinum angefragt. Nach euren Posts hatte das das seinerzeit angetestet, bin auf Probleme gestoßen und und habe es "etwas" delayed.

Nun habe ich, da ein FS auf meinem FreeNAS bei 95% Füllstand angelangt ist, das Thema wieder hervorgekramt. Allerdings scheine ich da ein semantisches Problemchen mit gvinum zu haben. Das Problem tritt auf meinem Laptop mit PCBSD 8.1 auf und ebenso auf dem Desktop mit FreeBSD 8.1 (Stable vom 31.07.).

Ich habe eine SATA-Platte (die mittels USB-Adapter am Rechner hängt) partitioniert und ein Label über die ganze Partition gelegt. Dann mit gvinum create eine Config erstellt mit drei Volumes, einem concat-Plex je Volume und einer Subdisk je Plex.

Danach auf /dev/gvinum/varvol ein Filesystem angelegt (mit -O2, testweise auch mit -O2 -U), dieses dann nach /mnt gemounted, den Inhalt von /var dort hineingetart. Abgemounted, fsck. Der findet keine Fehler. Dann dem Plex eine weitere Subdisk hinzugefügt, growfs. Der folgende fsck findet endlos Fehler...

Zu den fsck-Fehlern habe ich zwar einiges gefunden, gerade nach einem growfs, aber leider keine Lösung(en) :confused:

Hier mal detaillierter:

die config mit der ich das gvinum initialisiert habe
Code:
[-su]beaster:~$cat vinum.conf 
drive sysdrive device da0s1a
volume varvol
        plex org concat
                sd length 1g drive sysdrive
volume usrvol
        plex org concat
                sd length 5g drive sysdrive
volume homevol
        plex org concat
                sd length 4500m drive sysdrive

die list-Ausgabe des gvinum
Code:
gvinum -> list
1 drive:
D sysdrive              State: up       /dev/da0s1a     A: 141981/152625 MB (93%)

3 volumes:
V homevol               State: up       Plexes:       1 Size:       4500 MB
V usrvol                State: up       Plexes:       1 Size:       5120 MB
V varvol                State: up       Plexes:       1 Size:       1024 MB

3 plexes:
P homevol.p0          C State: up       Subdisks:     1 Size:       4500 MB
P usrvol.p0           C State: up       Subdisks:     1 Size:       5120 MB
P varvol.p0           C State: up       Subdisks:     1 Size:       1024 MB

3 subdisks:
S homevol.p0.s0         State: up       D: sysdrive     Size:       4500 MB
S usrvol.p0.s0          State: up       D: sysdrive     Size:       5120 MB
S varvol.p0.s0          State: up       D: sysdrive     Size:       1024 MB

die verbose list-ausgabe
Code:
gvinum -> list -v
1 drive:
Drive sysdrive: Device da0s1a
                Size:     160039105024 bytes (152625 MB)
                Used:      11161042944 bytes (10644 MB)
                Available: 148878062080 bytes (141981 MB)
                State: up
                Flags: 0

3 volumes:
Volume homevol: Size: 4718592000 bytes (4500 MB)
                State: up
Volume usrvol:  Size: 5368709120 bytes (5120 MB)
                State: up
Volume varvol:  Size: 1073741824 bytes (1024 MB)
                State: up

3 plexes:
Plex homevol.p0:        Size:   4718592000 bytes (4500 MB)
                Subdisks:        1
                State: up
                Organization: concat            Flags: 0
                Part of volume homevol
Plex usrvol.p0: Size:   5368709120 bytes (5120 MB)
                Subdisks:        1
                State: up
                Organization: concat            Flags: 0
                Part of volume usrvol
Plex varvol.p0: Size:   1073741824 bytes (1024 MB)
                Subdisks:        1
                State: up
                Organization: concat            Flags: 0
                Part of volume varvol

3 subdisks:
Subdisk homevol.p0.s0:
                Size:       4718592000 bytes (4500 MB)
                State: up
                Plex homevol.p0 at offset 0 (0  B)
                Drive sysdrive (sysdrive) at offset 6442586624 (6144 MB)
                Flags: 0
Subdisk usrvol.p0.s0:
                Size:       5368709120 bytes (5120 MB)
                State: up
                Plex usrvol.p0 at offset 0 (0  B)
                Drive sysdrive (sysdrive) at offset 1073877504 (1024 MB)
                Flags: 0
Subdisk varvol.p0.s0:
                Size:       1073741824 bytes (1024 MB)
                State: up
                Plex varvol.p0 at offset 0 (0  B)
                Drive sysdrive (sysdrive) at offset 135680 (132 kB)
                Flags: 0

abhängen FS und fsck
Code:
[-su]beaster:~$umount /mnt
[-su]beaster:~$fsck -tufs /dev/gvinum/varvol 
** /dev/gvinum/varvol
** Last Mounted on /mnt
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
12370 files, 403130 used, 103357 free (869 frags, 12811 blocks, 0.2% fragmentation)
***** FILE SYSTEM IS CLEAN *****

die Zeile die ich dem gvinum create mitgebe um eine weitere Subdisk anzulegen
Code:
sd name varvol.p0.s1 drive sysdrive len 1400m plex varvol.p0

growfs
Code:
[-su]beaster:~$growfs /dev/gvinum/varvol 
We strongly recommend you to make a backup before growing the Filesystem

 Did you backup your data (Yes/No) ? Yes
new file systemsize is: 1241088 frags
Warning: 73024 sector(s) cannot be allocated.
growfs: 2388.3MB (4891328 sectors) block size 16384, fragment size 2048
        using 13 cylinder groups of 183.72MB, 11758 blks, 23552 inodes.
        with soft updates
super-block backups (for fsck -b #) at:
 2257696, 2633952, 3010208, 3386464, 3762720, 4138976, 4515232

fsck des Grauens :zitter:
Code:
[-su]beaster:~$fsck -tufs /dev/gvinum/varvol 
** /dev/gvinum/varvol
** Last Mounted on /mnt
** Phase 1 - Check Blocks and Sizes
UNKNOWN FILE TYPE I=141312
UNEXPECTED SOFT UPDATE INCONSISTENCY

CLEAR? [yn] y

UNKNOWN FILE TYPE I=141313
UNEXPECTED SOFT UPDATE INCONSISTENCY

CLEAR? [yn] y

UNKNOWN FILE TYPE I=141314
UNEXPECTED SOFT UPDATE INCONSISTENCY

CLEAR? [yn] y

UNKNOWN FILE TYPE I=141315
UNEXPECTED SOFT UPDATE INCONSISTENCY

CLEAR? [yn] y

UNKNOWN FILE TYPE I=141316
UNEXPECTED SOFT UPDATE INCONSISTENCY

CLEAR? [yn] y

UNKNOWN FILE TYPE I=141317
UNEXPECTED SOFT UPDATE INCONSISTENCY

CLEAR? [yn] y

UNKNOWN FILE TYPE I=141318
UNEXPECTED SOFT UPDATE INCONSISTENCY

CLEAR? [yn] y

PARTIALLY ALLOCATED INODE I=141319
UNEXPECTED SOFT UPDATE INCONSISTENCY

CLEAR? [yn] y

UNKNOWN FILE TYPE I=141320
UNEXPECTED SOFT UPDATE INCONSISTENCY

CLEAR? [yn] y
.
.
.

gvinum list nach dem Hinzufügen
Code:
gvinum -> list
1 drive:
D sysdrive              State: up       /dev/da0s1a     A: 140581/152625 MB (92%)

3 volumes:
V homevol               State: up       Plexes:       1 Size:       4500 MB
V usrvol                State: up       Plexes:       1 Size:       5120 MB
V varvol                State: up       Plexes:       1 Size:       2424 MB

3 plexes:
P homevol.p0          C State: up       Subdisks:     1 Size:       4500 MB
P usrvol.p0           C State: up       Subdisks:     1 Size:       5120 MB
P varvol.p0           C State: up       Subdisks:     2 Size:       2424 MB

4 subdisks:
S varvol.p0.s1          State: up       D: sysdrive     Size:       1400 MB
S homevol.p0.s0         State: up       D: sysdrive     Size:       4500 MB
S usrvol.p0.s0          State: up       D: sysdrive     Size:       5120 MB
S varvol.p0.s0          State: up       D: sysdrive     Size:       1024 MB

und die verbose Ausgabe des list-Befehls
Code:
gvinum -> list -v
1 drive:
Drive sysdrive: Device da0s1a
                Size:     160039105024 bytes (152625 MB)
                Used:      12629049344 bytes (12044 MB)
                Available: 147410055680 bytes (140581 MB)
                State: up
                Flags: 0

3 volumes:
Volume homevol: Size: 4718592000 bytes (4500 MB)
                State: up
Volume usrvol:  Size: 5368709120 bytes (5120 MB)
                State: up
Volume varvol:  Size: 2541748224 bytes (2424 MB)
                State: up

3 plexes:
Plex homevol.p0:        Size:   4718592000 bytes (4500 MB)
                Subdisks:        1
                State: up
                Organization: concat            Flags: 0
                Part of volume homevol
Plex usrvol.p0: Size:   5368709120 bytes (5120 MB)
                Subdisks:        1
                State: up
                Organization: concat            Flags: 0
                Part of volume usrvol
Plex varvol.p0: Size:   2541748224 bytes (2424 MB)
                Subdisks:        2
                State: up
                Organization: concat            Flags: 0
                Part of volume varvol

4 subdisks:
Subdisk varvol.p0.s1:
                Size:       1468006400 bytes (1400 MB)
                State: up
                Plex varvol.p0 at offset 1073741824 (1024 MB)
                Drive sysdrive (sysdrive) at offset 11161178624 (10 GB)
                Flags: 0
Subdisk homevol.p0.s0:
                Size:       4718592000 bytes (4500 MB)
                State: up
                Plex homevol.p0 at offset 0 (0  B)
                Drive sysdrive (sysdrive) at offset 6442586624 (6144 MB)
                Flags: 0
Subdisk usrvol.p0.s0:
                Size:       5368709120 bytes (5120 MB)
                State: up
                Plex usrvol.p0 at offset 0 (0  B)
                Drive sysdrive (sysdrive) at offset 1073877504 (1024 MB)
                Flags: 0
Subdisk varvol.p0.s0:
                Size:       1073741824 bytes (1024 MB)
                State: up
                Plex varvol.p0 at offset 0 (0  B)
                Drive sysdrive (sysdrive) at offset 135680 (132 kB)
                Flags: 0

Mache ich hier was grundlegendes falsch? Ich hatte mal testweise auf varvol ein neues FS angelegt - das funktioniert dann einwandfrei. Nur nach dem growfs habe ich Datenmüll.

Bin für jeden Tipp dankbar...

Danke im voraus und Gruß,
_ralf_
 
Ist das Dateisystem denn wirklich irreparabel Schrott oder funktioniert es schlussendlich nach (mehreren) "fsck -y" Läufen wieder? Die Frage mag dumm klingen, für mich klingt es aber so, als würde in den neu angelegten Inodes einfach Müll stehen und der Dateisystemcode dadurch verwirrt werden.
 
Ist das Dateisystem denn wirklich irreparabel Schrott oder funktioniert es schlussendlich nach (mehreren) "fsck -y" Läufen wieder? Die Frage mag dumm klingen, für mich klingt es aber so, als würde in den neu angelegten Inodes einfach Müll stehen und der Dateisystemcode dadurch verwirrt werden.

Hi Yamagi,

hmm... das wäre denkbar. Ich hab's gerade alles zurückgedreht und neu angefangen. Es hat ca. 10 Durchläufe des fsck -y benötigt, bis es clean war.

Aussehen tut das ge-growte FS gut. Ich habe einige Dateien stichprobenartig gecheckt, die waren vorhanden. Ein paar ls -l|wc -l für ausgewählte Verzeichnisse haben auch identische Ergebnisse gebracht.

(etwas später)
So, habe jetzt einen find mit -type f -print für das original /var und das neue, reparierte, /mnt abgesetzt, die Ausgabe sortiert in je eine Datei und die Dateien gedifft. Der hat keine Differenz(en) gefunden.

Sieht also gut aus (naja, ich sollte jetzt zusätzlich mal die Größen der Dateien checken).

Deine Vermutung scheint also absolut zuzutreffen.Wobei ich, wäre das auf einem "echten" Rechner geschehen, z.B. auf dem besagten FreeNAS, um Jahre gealtert wäre und direkt den Bacula um einen Restore gebeten hätte ;'(

Ich sollte vll. mal die FreeBSD-Bugs duchsuchen und ggf. einen neuen aufmachen; Errata und Release Notes hatte ich schon durchforstet, da habe ich nichts gefunden.

Danke nochmal für die schnelle Antwort!

Gruß,
_ralf_

Hier noch die letzten Durchläufe des fsck
Code:
[-su]beaster:/$fsck -tufs  -y /dev/gvinum/varvol 
** /dev/gvinum/varvol
** Last Mounted on /mnt
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
DIRECTORY ?: CONTAINS EMPTY BLOCKS
UNEXPECTED SOFT UPDATE INCONSISTENCY

ADJUST LENGTH? yes

YOU MUST RERUN FSCK AFTERWARDS
DIRECTORY ?: CONTAINS EMPTY BLOCKS
UNEXPECTED SOFT UPDATE INCONSISTENCY

ADJUST LENGTH? yes

YOU MUST RERUN FSCK AFTERWARDS
DIRECTORY ?: CONTAINS EMPTY BLOCKS
UNEXPECTED SOFT UPDATE INCONSISTENCY

ADJUST LENGTH? yes

YOU MUST RERUN FSCK AFTERWARDS
DIRECTORY ?: CONTAINS EMPTY BLOCKS
UNEXPECTED SOFT UPDATE INCONSISTENCY

ADJUST LENGTH? yes

YOU MUST RERUN FSCK AFTERWARDS
DIRECTORY ?: CONTAINS EMPTY BLOCKS
UNEXPECTED SOFT UPDATE INCONSISTENCY

ADJUST LENGTH? yes

YOU MUST RERUN FSCK AFTERWARDS
DIRECTORY ?: CONTAINS EMPTY BLOCKS
UNEXPECTED SOFT UPDATE INCONSISTENCY

ADJUST LENGTH? yes

YOU MUST RERUN FSCK AFTERWARDS
DIRECTORY ?: CONTAINS EMPTY BLOCKS
UNEXPECTED SOFT UPDATE INCONSISTENCY

ADJUST LENGTH? yes

YOU MUST RERUN FSCK AFTERWARDS
MISSING '..'  I=226305  OWNER=root MODE=40074
SIZE=32768 MTIME=Jan  1 01:00 1970 
DIR=/lost+found/#226305

UNEXPECTED SOFT UPDATE INCONSISTENCY

FIX? yes

DIRECTORY ?: CONTAINS EMPTY BLOCKS
UNEXPECTED SOFT UPDATE INCONSISTENCY

ADJUST LENGTH? yes

YOU MUST RERUN FSCK AFTERWARDS
DIRECTORY ?: CONTAINS EMPTY BLOCKS
UNEXPECTED SOFT UPDATE INCONSISTENCY

ADJUST LENGTH? yes

YOU MUST RERUN FSCK AFTERWARDS
DIRECTORY ?: CONTAINS EMPTY BLOCKS
UNEXPECTED SOFT UPDATE INCONSISTENCY

ADJUST LENGTH? yes

YOU MUST RERUN FSCK AFTERWARDS
DIRECTORY ?: CONTAINS EMPTY BLOCKS
UNEXPECTED SOFT UPDATE INCONSISTENCY

ADJUST LENGTH? yes

YOU MUST RERUN FSCK AFTERWARDS
DIRECTORY ?: CONTAINS EMPTY BLOCKS
UNEXPECTED SOFT UPDATE INCONSISTENCY

ADJUST LENGTH? yes

YOU MUST RERUN FSCK AFTERWARDS
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
12371 files, 403077 used, 690130 free (1354 frags, 86097 blocks, 0.1% fragmentation)

***** FILE SYSTEM STILL DIRTY *****

***** FILE SYSTEM WAS MODIFIED *****

***** PLEASE RERUN FSCK *****
[-su]beaster:/$fsck -tufs  -y /dev/gvinum/varvol 
** /dev/gvinum/varvol
** Last Mounted on /mnt
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
LINK COUNT DIR I=94213  OWNER=root MODE=40700
SIZE=512 MTIME=Aug 20 19:10 2010  COUNT 3 SHOULD BE 2
ADJUST? yes

ZERO LENGTH DIR I=226305  OWNER=root MODE=40074
SIZE=0 MTIME=Jan  1 01:00 1970 
CLEAR? yes

** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes

SUMMARY INFORMATION BAD
SALVAGE? yes

BLK(S) MISSING IN BIT MAPS
SALVAGE? yes

12370 files, 403077 used, 690130 free (1354 frags, 86097 blocks, 0.1% fragmentation)

***** FILE SYSTEM MARKED CLEAN *****

***** FILE SYSTEM WAS MODIFIED *****
[-su]beaster:/$fsck -tufs  -y /dev/gvinum/varvol 
** /dev/gvinum/varvol
** Last Mounted on /mnt
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
12370 files, 403077 used, 690130 free (1354 frags, 86097 blocks, 0.1% fragmentation)

***** FILE SYSTEM IS CLEAN *****
 
Hi,

vielleicht sollte man an dieser Stelle darauf hinweisen das FreeBSD eine hervorragende zfs Implementierung hat. Sofern du genug Memory und einen amd64 Kernel dein eigen nennst, solltest du dir das mal anschauen.
 
Also, das von dir beobachtete Verhalten erinnert sehr stark an den Bug #115174 - http://www.freebsd.org/cgi/query-pr.cgi?pr=115174 Kurz zusammengefasst initialisierte growfs(8) durch einen Programfehler die neu erstellten Inodes nicht, dadurch waren sie mit dem Müll gefüllt, der an den entsprechenden Stellen auf der Platte war. Der Dateisystemtreiber war dadurch verwirrt und das Dateisystem schrott. Allerdings wurde das vor einiger Zeit repariert und der Patch ist Teil von 8.1 und damit auch von deinem -STABLE. Und daher wundert das ganze mich ein wenig. Ich kann dir nicht wirklich helfen, dir nur den Hinweis oder besser gesagt Rat geben, dich an die Mailingliste freebsd-stable@ zu wenden....
 
Hi,

vielleicht sollte man an dieser Stelle darauf hinweisen das FreeBSD eine hervorragende zfs Implementierung hat. Sofern du genug Memory und einen amd64 Kernel dein eigen nennst, solltest du dir das mal anschauen.

Hi,

danke für den Hinweis!

Naja... der FreeNAS-Rechner ist ein 1200er C7 mit 512MB (aber drei Platten als RAID5 mit einem nicht wirklich schnellen, da altem, 3ware Controller). Der ist quasi fast unhörbar leise und reicht für meine Anforderungen vollkommen aus ;-) Auf dem Desktop habe ich zwar amd64 - aber nur 3GB - ich mache viel Java mit Eclipse/NetBeans, Squirrel und dem Oxygen/XML und dabei geht dann eine ganze Menge des Speichers drauf...

Aufer Sparc (mit 2G) habe ich ZFS am Laufen... Die Features gefallen mir sehr wohl, aber ich habe das Gefühl, dass die Performance bei einer Platte mit UFS zumindest nicht schlechter ist als ZFS.

Auch nach den Berichten die ich hier so gelesen habe soll ZFS wohl vor allem gut sein, wenn man mehrere Platten einsetzt. Ich müsste das vll. einfach mal antesten, also System auf eine Platte mit ZFS clonen und dann schauen, wie es performed...

Wobei das dann halt nur eine Lösung für den Desktop wäre - für den FreeNAS wäre gvinum sicherlich besser.

Gruß,
_ralf_
 
Also, das von dir beobachtete Verhalten erinnert sehr stark an den Bug #115174 - http://www.freebsd.org/cgi/query-pr.cgi?pr=115174 [...]

Hi Yamagi,

vielen Dank für den Link! Habe gerade das Ticket angeschaut, dann meinen growfs gecheckt. Er ist frisch mit dem Rest von Welt und Kernel compiliert (also nicht irgend eine alte Leiche) und der Source vom growfs sieht auch gut aus, ist Revision 1.26.2.4 vom 17.03.2010.

Ich habe gestern mal die Platte aus /dev/zero vollgeschrieben und dann meine Experimente wiederholt: Alles sauberst. Kein fsck-Fehler nach dem growfs. Das passt zum Ticket (und zum vermuteten Problem).

Ich wollte dann heute (das "Nullen" der *ganzen* Platte war nicht wirklich schlau, es hat recht lange gedauert) mal eine kleinere Partition auf dem LW anlegen, die aus /dev/urandom füllen und dann nochmal durchtesten.

Wenn ich es reproduzieren kann sollte ich das Problem vermutlich wirklich in stable posten.

Danke nochmal!

Gruß,
_ralf_
 
Hi,

so, ich habe jetzt nochmal ein wenig rumprobiert:

- auf der Platte eine 5G Partition angelegt
- auf diese ein Label mit einer a-Slice die analog zur c-Slice über die ganze Partition geht
- newfs -O2 -U auf dieses Slice /dev/da0s1a
- das neue FS gemounted
- oggs meiner gerippten CDs reinkopiert bis das FS voll war
- abgehängt
- mit gvinum vier Volumes definiert
- in eines (wie gehabt das varvol) ein newfs -O2 -U
- fsck auf varvol - keine Fehler
- varvol gemounted
- den Inhalt von /var hineingetart
- varvol abgemounted
- fsck - keine Fehler
- mit gvinum dem Plex vom varvol eine Subdisk hinzugefügt
- growfs
- fsck -- zig Fehler

Dann nochmal alles resettet und das /dev/da0s1a Daten aus /dev/urandom überschrieben. Probleme sind dann beim fsck analog.

Schließlich noch da0s1a aus /dev/zero gefüllt - alles sauber.

Ich denke, ich werde ein Ticket aufmachen und einen Hinweis auf das von Yamagi genannte reinsetzen.

Danke nochmal für die Unterstützung! Wenn sich in der Sache etwas tun sollte werde ich das hier (wenn ich es nicht vergesse) posten.

Gruß,
_ralf_
 
Diese Änderung von vorhin müsste es reparieren:
Code:
  Author: brian                                                                 
  Date: Sun Sep 19 08:18:56 2010                                                
  New Revision: 212839                                                          
  URL: http://svn.freebsd.org/changeset/base/212839                             
                                                                                
  Log:                                                                          
    Revise r197763 which fixes filesystem corruption when extending             
    into un-zeroed storage.                                                     
                                                                                
    The original patch was questioned by Kirk as it forces the filesystem       
    to do excessive work initialising inodes on first use, and was never        
    MFC'd.  This change mimics the newfs(8) approach of zeroing two             
    blocks of inodes for each new cylinder group.                               
                                                                                
    Reviewed by:        mckusick                                                
    MFC after:  3 weeks
 
Verstehe ich das richtig, dass es ohne den Patch reicht den neuen Speicher vorher einmal komplett zu nullen? Dauert zwar lange sollte jedoch niemanden der mit growfs "spielt" überfordern.
 
Zuletzt bearbeitet:
Das ganze ist vorhin in 8-STABLE aufgeschlagen, zusammen mit einer ganzen Reihe Regressionstest. Wird also Teil von 8.2 sein. Es war SVN r214956. :)
 
Hi, Yamagi,

vielen Dank für die Info! Ich hatte am Samstag mal meinen Tree upgedated - da war's noch nicht drin ;-)

Gruß,
_ralf_
 
Hi,

hab's jetzt endlich getestet ("musste" vorher noch den Doubler meines TRS-80 reparieren). Funktioniert jetzt 1a.

Gruß,
_ralf_
 
Hallo Leute.

Sorry, dass ich mit meinem ersten Post direkt mal einen solch alten Thread hoch hole. Aber es interessiert mich sehr, ob der beschriebene Fehler in FreeBSD 8.2 weg ist. Kann das noch jemand bestätigen?
Ich habe mir in der Vergangenheit mehrmals größere gvinum UFS Filesysteme (mit FreeBSD 8.0 und 8.1) geschreddert.
Im Moment habe ich ein i386 8.1-RELEASE System, wo eine Vergrößerung von zwei vollen UFS Filesystemen mit jeweils 70G Größe ansteht.
Ich will nicht schon wieder nach dem growfs ein Backup in dieser Größenordnung zurückspielen.
Bei den Daten und Dateimengen ist das wiederholte fsck'en keine wirkliche Alternative gewesen, da es unendlich lange gelaufen ist und ich den Zustand clean nicht erreichen konnte.
Lohn also der Update auf 8.2 um dann ohne Probleme das growfs über die Bühne zu bringen?

Grüße
Mario
 
70G? Das ist sogar übers Netzwerk in 20 Minuten restauriert. Es steht doch ganz klar bei growfs dabei, dass ein Backup stets dazu gehört. Wozu muss man da überhaupt überlegen?

Solche Tools sind im allgemeinen sowieso sehr komplex und deswegen laut Voraussetzung schon für die Katz.
 
Hi Mario,

sorry - ich hatte die Sache seinerzeit nicht (mehr) weiterverfolgt.

Im Zweifel -und wenn du eine "Spielplatte" hast- kannst du meine Experimente (der/die erste(n) Post(s) dieses Threads) einfach mal durchziehen und schauen, wie er sich verhält.

Gruß,
_ralf_
 
Es steht doch ganz klar bei growfs dabei, dass ein Backup stets dazu gehört. Wozu muss man da überhaupt überlegen?

Ich finde, eine Vergrößerung ist deutlich schicker als plätten und neu aufziehen.
Gvinum und growfs gehören zum Standardumfang. Im Grunde erwarte ich, dass es dann auch funktioniert.
Und growfs funktioniert ja auch gut. Nur halt in Kombination mit gvinum Volumes nicht.

Grüße
Mario
 
Bei Dateisystem-Kaspereien wie growfs gehört Backup einfach dazu. Ich wollte nur damit sagen, dass "ich will nicht schon wieder Backup einspielen" eine komische Aussage ist, weil zum Glück gab es ein Backup!

growfs hat laut man-Page schon einige Einschränkungen. Ich habe es auch erfolgreich hingekriegt, ja.

Das einzige was richtig gut funktioniert mit dynamischen Datenträgern ist ZFS, aber hat auch seine Schranken. Ich mache natürlich auch von ZFS Backups. Je aufwändiger die Strukturänderung, desto sicherer sollte man sein, dass man ein aktuelles Backup hat.
 
Ich habe ein i386 System mit "nur" 2G RAM. Da ist mit ZFS wohl nicht viel zu machen.
Backup ist nicht zufällig da sondern immer. Aber es soll ja andere geben... ;)

Wie bekomme ich das mit dem Nullen denn hin?
Um mal etwas konkreter zu werden poste ich meine Konfig:
Code:
Filesystem                         Size    Used   Avail Capacity  Mounted on
/dev/ad0s1a                        1.4G    322M    1.0G    24%    /
devfs                              1.0K    1.0K      0B   100%    /dev
/dev/gvinum/var_vol                739M    294M    386M    43%    /var
/dev/gvinum/usr_vol                2.8G    1.9G    712M    73%    /usr
/dev/gvinum/usr_local_vol          2.8G    1.6G    1.0G    60%    /usr/local
/dev/gvinum/usr_ports_vol          2.9G    2.4G    316M    88%    /usr/ports
/dev/gvinum/data_vol                70G     41G     23G    65%    /data
/dev/gvinum/data_home_vol           29G     19G    7.7G    71%    /data/home
/dev/gvinum/data_musik_vol          68G     60G    2.8G    96%    /data/musik
/dev/gvinum/data_bilder_vol         58G     49G    4.4G    92%    /data/bilder
/dev/gvinum/data_pxe_vol           5.8G    3.4G    1.9G    64%    /data/pxe
/dev/gvinum/data_jail_vol          5.7G    2.3G    2.9G    45%    /data/jail
/dev/gvinum/data_jail_karpo_vol    1.4G    439M    927M    32%    /data/jail/karpo
/dev/gvinum/data_jail_zeus_vol     1.4G    1.0G    317M    77%    /data/jail/zeus
/dev/gvinum/data_jail_pluto_vol    2.9G    1.1G    1.6G    39%    /data/jail/pluto
/dev/md0                           248M    490K    227M     0%    /tmp
devfs                              1.0K    1.0K      0B   100%    /data/jail/karpo/dev
devfs                              1.0K    1.0K      0B   100%    /data/jail/pluto/dev
devfs                              1.0K    1.0K      0B   100%    /data/jail/zeus/dev
devfs                              1.0K    1.0K      0B   100%    /var/named/dev

Nehmen wir uns mal /dev/gvinum/data_musik_vol raus.
Im Volumemanager sieht das so aus
Drei interne Platten und alle Filesysteme sind über alle Platten verteilt:
Code:
3 drives:
D vinum0                State: up       /dev/ad0s2      A: 140955/236475 MB (59%)
D vinum2                State: up       /dev/ad2s1      A: 153195/238475 MB (64%)
D vinum1                State: up       /dev/ad1s1      A: 153195/238475 MB (64%)

14 volumes:
[...]
V data_musik_vol        State: up       Plexes:       1 Size:         70 GB
[...]

14 plexes:
[...]
P data_musik_vol.p0   S State: up       Subdisks:     7 Size:         70 GB
[...]

55 subdisks:
[...]
S data_musik_vol.p0.s6  State: up       D: vinum0       Size:         10 GB
S data_musik_vol.p0.s5  State: up       D: vinum2       Size:         10 GB
S data_musik_vol.p0.s4  State: up       D: vinum1       Size:         10 GB
S data_musik_vol.p0.s3  State: up       D: vinum0       Size:         10 GB
S data_musik_vol.p0.s2  State: up       D: vinum2       Size:         10 GB
S data_musik_vol.p0.s1  State: up       D: vinum1       Size:         10 GB
S data_musik_vol.p0.s0  State: up       D: vinum0       Size:         10 GB
[...]

Ich würde jetzt von Hand gvinum auf basis von einem printconfig erweitern [1]
Code:
#sd name data_musik_vol.p0.s6 drive vinum0 len 20971520s driveoffset 52183305s plex data_musik_vol.p0 plexoffset 6144s
#sd name data_musik_vol.p0.s5 drive vinum2 len 20971520s driveoffset 52429065s plex data_musik_vol.p0 plexoffset 5120s
#sd name data_musik_vol.p0.s4 drive vinum1 len 20971520s driveoffset 52429065s plex data_musik_vol.p0 plexoffset 4096s
sd name data_musik_vol.p0.s9 drive vinum0 len 10G plex data_musik_vol.p0 
sd name data_musik_vol.p0.s8 drive vinum2 len 10G plex data_musik_vol.p0 
sd name data_musik_vol.p0.s7 drive vinum1 len 10G plex data_musik_vol.p0

Danach habe ich dann mein 70G Volume mit 30G Freespace hinten dran.
Wie kann ich das dd zum Nullen an der richtigen Stelle von /dev/gvinum/data_musik_vol einspringen lassen, damit das bestehende Filesystem nicht berührt wird?

tia
Mario

[1] Ja, ich weiß das Greg das so nicht empfiehlt. Aber mit den Standardaufrufen verteilt sich das Filesystem nicht über meine drei Platten. Ich will kein RAID, sondern aus Performancegründen die Verteilung der Daten auf alle Platten. Das Backup sichert vor Plattenausfällen.
 
Ja, der Patch ist in 8.2 drin und ich habe auch schon erfolgreich Dateisysteme mit growfs(1) auf nicht-ausgenullten Speicherplatz wachsen lassen. Das Update lohnt sich also, alternativ kannst du dir auch einfach SVN-Revision 214956 [1] in dein 8.1 reinpatchen. Ein Backup solltest du aber in jedem Fall dennoch machen, lieber eines zu viel haben, als am Ende Datenverlust. :)

EDIT: Rechne aber damit, dass growfs(8) ein wenig auf die Performance schlägt. Zumindest in der ersten Zeit. UFS versucht die Daten möglichst gleichmäßig über das Dateisystem zu verteilen, nachdem du hinten freien Speicher anhängst, ist das natürlich nicht mehr gegeben. Die Allokationsalgrithmen laufen daher nicht mehr optimal. Es "wächst" sich aber recht schnell aus, wenn man ganz normal arbeitet, die Daten verteilen sich ganz von allein wieder gleichmäßig.

1: http://svnweb.freebsd.org/base?view=revision&revision=214956
 
Ich wollte eigentlich mit FreeBSD 8.1 einmal das Thema Nullen vor dem growfs durchspielen. Aus Neugier und "für die Akten".
Crest: An dieser Stelle ein Danke für den dd-Support.
Leider hat mir gvinum bei den Aktionen mit dem Testvolume das usr-Volume geschreddert und so meinen Testrechner etwas unbedienbar gemacht. Ich werde das daher nicht weiter verfolgen, sondern das 8.2 Update ins Auge fassen.

Grüße
Mario
 
Ein Update von mir zum Thema growfs auf gvinum Systemen.
Ich habe in der letzten Woche verschiedene Tests mit einem neu installierten und gepatchtem FreeBSD 8.2 gemacht.
In Verbindung mit gvinum und growfs ist es aber zu 8.0/8.1 nicht besser geworden.
Einige meiner Probleme
- Growfs dumped beim Vergrößern cores raus. Das Filesystem ist danach Schrott.
- Fsck sieht manchmal keine richtigen Filesysteme mehr, wenn erfolgreich vergrößert wurde.
- Fsck Läufe dauern ewig und das Filesystem ist nach mehreren Läufen immer noch nicht clean.
Alles zusammen ist das leider sehr ernüchternd.
Um ein Neuanlegen von größeren Filesystemen (und Verschieben der Daten) kommt man wohl bei gvinum Systemen nicht herum.
Solche Tools sind im allgemeinen sowieso sehr komplex und deswegen laut Voraussetzung schon für die Katz.
Auch für 8.2 scheint die Aussage von nakal zu gelten.

Grüße
Mario
 
Zuletzt bearbeitet:
Zurück
Oben