System Info:

D3 Version: D3 lx-7.5.12-.Z
Linux Version: RedHat Enterprise Linux (RHEL) 5.2 x64 running kernel
2.6.18-92.1.22.el5PAE
Running on: Dell PowerEdge 1900 with dual Intel Xeon E5320 processors
with a PERC 5/i RAID controller in (I believe) RAID 5 configuration

Problem:

Last week we had a power outage which caused the system to reboot (for
some reason the UPS did not hold up the system).

Shortly thereafter we noticed that Unix directories contained files
that should have been written to other directories. Moreover (and
here's the really strange part) the files were not named what they
should have been stored as. Instead, they had the names of files that
they overwrote. All the directories involved are Q-Pointed Unix
directories:

These directories (4 in all) were all Q-Pointed D3 "files". Picture
this:

Pick File Q-Pointed to

UQ.ARTISTS /var/music/artists
UQ.GUNS /var/dangerous_things/guns

The artists directory (pick file UQ.ARTISTS) contains a file (pick
item) called BEATLES that looks like this (sans the numbers):

001 Paul
002 George
003 John
004 Ringo

The guns directory (pick file UQ.GUNS) contains a file (pick item)
called RUGER that looks like this (sans the numbers):

001 .357 Magnum
002 9MM
003 12 Gauge Shot Gun

Now, imagine our surprise when we went to display the record in
UQ.ARTISTS called BEATLES and instead we got the record about the
guns. All in all, there about 20 of these mis-written items.

The applications and the databases are unrelated but happen to be on
the same CPU and Virtual Machine. The oddest thing for us is that we
can't figure out how the name of the guns item was changed to BEATLES
(never mind how it got filed in the ARTISTS directory). If strange
stuff like this were to happen shouldn't it be less organized than
this... it's not random enough. Why are only the Q-Pointed dirs
affected? How did the Unix file name (pick item name) come to be named
the same name as the file it clobbered? Why is there no "garbage" or
remnants in the items like you might find with a GFE?

Has anyone else seen this?

When I started poking around looking at the issue and trying to fix
records, the var partition switched itself to read only. We did a
reboot and found the var partition to be corrupted. A fsck was
performed and files were "fixed" (well, fsck said they were fixed but
the data is gone). During the fsck all the Unix QP's were reported on
the screen ... and ONLY the Unix QP's were listed as problematic.

Never seen anything like this and I haven't a clue. Anyone? Bueller?

Thanks Much,

J. Alosa

On 2010-05-11 10:56:56 -0400, Jay <jayalosa (AT) gmail (DOT) com> said:

That's pretty much the issue right there.

I'm not sure why you're surprised that the system is corrupted, even if
it appears to be pseudo-organzied corruption. What exactly are you
trying to determine? When a multi-user, virtual memory system reboots
while in use, anything could happen.

--
Kevin Powick

On May 11, 12:07*pm, Kevin Powick <nos... (AT) spamless (DOT) com> wrote:

............and usually does!

"Kevin Powick" wrote
filesystem [that is, type is ext3 instead of ext2] then you have the narrowly-defined
assurance that your subdirectory structure will be correct later, though data files
in those folders are not protected. Am not sure if changes to spelling of
folder names are under the umbrella of journalling, but at least you won't end up
with a cross-link where an expected directory node is replaced with some data
node during crash. The e2fsck largely prunes crosslinks, won't really replace
messed up data from a crash...

The -j option of tune2fs and mke2fs adds journalling to a filesystem.

On May 11, 4:25*pm, "Frank Winans" <fwin... (AT) sbcglobal (DOT) net> wrote:
Thanks Frank I will chase that down.

On May 11, 1:07*pm, Kevin Powick <nos... (AT) spamless (DOT) com> wrote:
Yeah, I suppose you're right. I guess I'm taken back that it is the
Linux file system that is corrupted BUT it it's only the D3 QP's that
are affected. It's like a grassy knoll conspiracy thing - too much
order in that chaos.

On May 12, 7:05*am, Jay <jayal... (AT) gmail (DOT) com> wrote:
Oh, and one more thing... some of the items in those misguided
directories were put there by PERL scripts that accessed the files
from Linux, not Pick. The PERL scripts were, however EXECUTEd by D3.
I'm chocking/chalking? this up to a blip in the space/time continuum.
Thanks to all who responded, now I will try to forget this ever
happened.

On May 12, 12:05*pm, Jay <jayal... (AT) gmail (DOT) com> wrote:
So - reading between the lines - you're really trying to say it was
John Lennon that took the shot?

Perhaps it is simply that the D3 application you are running is/was
the only thing that was creating/updating files at the time .... so
there is no knoll, just a single shooter!