Help!

We have experienced this "Disk Failure!" error message during the
nightly backup (full system save). Having some strange behaviour with
a couple of files going missing after the error. Has anyone come
across this before??
Running D3 Linux 7.1.0 on RedHat 5.2.
I suspect a hardware error but will listen to any council at the
moment.

David

OK, the disk failure during the save is occuring at files that
show the following error when trying to access them from TCL:
Inconsistent FCB in frame xxxxxx

Hardware problem or are the files in massive overflow??

On Tue, 10 May 2005 19:26:13 +1000, David wrote:

On Tue, 10 May 2005 19:38:48 +1000, David
<alfbar (AT) optusnet (DOT) com.au> decreased the available storage
space of our news server by typing the following:


If your D3 virtual disks are ontop of ext2, then I would
recommend a shutdown and e2fsck under single user. If you're
using unknown partition space(D3 blob), then there's not
much you can do but save what you can and reboot into disk
hardware diags. I wouldn't test the h/w from Linux. Some
more info on your hardware may be helpful.

I would recommend an upgrade to 7.4 on RH9 so you can get
ext3 with recover journaling. It is a life saver, especially
if you are running odbcsrv. I've shot my box point blank in
the head, twice, with supposedly valid queries. No warning
or anything.. just <click> <click> ... dead terminals.


Glen

Inconsistent FCB

means you've got a corrupted file control block.

In the old days of R83 and a lot of clones, you could create a file by
simply creating a file item in your master dicitonary or in the dictionary
of a file. In D3, there's a special binary FCB that controls everything
about the file, including indexing and transaction logging.

Included in the binary of this file control block are the base, modulo and
separation of the file. If any of those become corrupted, the system will
attempt to read the appropriate disk location based on a bad FID calculation
and give you a Disk Error.

This error has nothing to do with overflow. Could be hardware with a bad
sector, or simply a glitch in the exactly right spot to corrupt your FID
calc.

Are these files important? If not, just delete the MD pointer and the
system should ignore them. If they are important, then I'd get someone from
RD involved to help resolve the error.

Mark Brown


"David" <alfbar (AT) optusnet (DOT) com.au> wrote

Well, I deleted some unnecessary files, lost some q-pointers but
managed to save all accounts and the vast majority of data.

I first tried to do a f-resize but during the :files phase it
said no data! Luckily I had individually saved the accounts to
pseudo-floppy before the full system save.

I tried loading the pick data files but was informed that the ABS
was corrupt, so basically I ended up reloading everything (ABS,
pick data files then all the accounts). Certainly appears to be
in much better shape now although we seem to be finding a few
lost files along the way.

We are definitely upgrading the server asap. Will get the latest
version of D3 Linux (7.4.2??). Any comment on whether we should
use RedHat 9, RedHat Enterprise or possibly even Fedora Core??

Thanx for response,
David

On Tue, 10 May 2005 19:38:48 +1000, David wrote:

David wrote:
That's not "Luck," David... that's planning.
Or, as some folks say, you make your own
luck. Good on ya, Mate! Gets saddening
to hear those "didn't back up" stories, over
and over and...

--
frosty

get another disk on there quick!
It's not an IBM disk is it?
they fail