Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 31 Jul 2006 01:51:25 -0700 (PDT)
From:      "R. B. Riddick" <arne_woerner@yahoo.com>
To:        Brent Hostetler <brenthostetler@gmail.com>
Cc:        freebsd-geom@freebsd.org
Subject:   Re: gmirror/gconcat: mkdir causes system reboot
Message-ID:  <20060731085125.49554.qmail@web30312.mail.mud.yahoo.com>
In-Reply-To: <aadbc3580607310119m245c0954l472fdc7e7df16964@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--- Brent Hostetler <brenthostetler@gmail.com> wrote:
> On 7/30/06, R. B. Riddick <arne_woerner@yahoo.com> wrote:
> > I say, did u try a fsck on that file system?
> > It looks more like an file system related problem.
> >
> 
> Well, I detached the spares from the mirrors that made up the gcocat
>
good idea...

> data mount. Then I ran fsck -y /dev/concat/DATA.. I had to continually
> run this command about four-five times over about 4 hours before
> marked clean.
>
interesting... :-)

> -36191552698910622 BAD I=122259928
> UNEXPECTED SOFT UPDATE INCONSISTENCY
>
uhuhuhuh :-) such big numbers...

> These errors repeated for about  3meg log file of errors.
>
Hmm... Maybe u mounted ur file system unclean somewhen (e. g. by pressing
CTRL+C during the boot process) and then the errors escalated cataclysmically?
:-)

Or maybe ur gmirror's where out of sync due to some strange administrative
trick or due to a system crash during synchronization (so that just one half of
the mirror had the new data, while it stayed unmentioned, that the other half
had still the old data (this is something fsck could miss, when it just reads
the new/good half of the mirror (e. g. because those discs r faster or because
of a coincidence))).

> After this, mount clean but lost 220 Gigs of data!!! So I created new
> concat from the spares and mounted and all the data is there and is
> readable! So Im in the process of copying from the spare drives to the
> main...
>
Hmm... And the copy on the other parts of the mirror had no errors? I mean: Did
u run fsck on the concat of the spares, too?

> What would have caused this madness and why no errors showing up in
> logs, or when the system boots and fsck is run in background??
>
I just have the catacylsm theory (see above)...
I do not think, that the ufs code can produce such errors in case of normal
operation, because: I never saw that (but I do fsck's every few weeks, whenever
I crashed my box with a self-written kernel module or so).

> How can I prevent this in the future?
>
I do not know. Maybe regular fsck's? Once a month? Boot to single user and do a
fsck on every fs (especially the clean ones).

> This is a home server, and because of the large size of the data
> (700GIGs + and growing) I cannot backup a large percent of the data.
> My only failsafe is the mirroring which has saved me a few times... (I
> know its not a backup, but its better then nothing!)
>
If u like u may want to _test_ my brand-new graid5
(http://home.tiscali.de/cmdr_faako/geom_raid5.tbz), which could save some hard
discs (but it is less secure, since it will tolerate in no case the loss of two
discs at the same time, and since it is almost untested).

U r right: Mirroring does not help, when u accidentially delete something, but
it helps against disc damage related data loss...

I have another idea: U could try to rsync (ports/net/rsync) "old" changes
(maybe changes that happened at least one hour before) from one concat'ed disc
set to another (instead of the mirror), which could help against accidential
deletion (but then u could lose at least 1 hour of fresh data (or u use my
graid5 or the older and slower(?) graid3 to protect against the damage on a
single disc)).

-Arne


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060731085125.49554.qmail>