Files appear to be cross linked
- From: ken.lindner@xxxxxxxxxxx
- Date: Fri, 14 Mar 2008 05:30:12 -0700 (PDT)
Please forgive the terminology I use in this post and read to the end
to try to follow the problem. I apologies for the length of the
description but I can think of no easier way to describe the issue. I
am not a Solaris admin so have only a basic understanding of the OS
and the admin facts are what I understand the sys admin to be saying,
so if some it seems implausible I also apologies.
The background:
The system is a Sunfire 880 running Solaris 10. It has 6 bays
available for disks of which 3 make up the primary mirror pack and 3
are intended to be the secondary mirror. The system has been running
fine with the 3 disks in an un-mirrored configuration and the sys
admin has started to make the changes to mirror the disks.
The sys admin shut down the system and initiated a mirror of the boot
disk, this appeared to work fine so they started to submirror the
remaining disks. During this submirror process something appears to
have gone hay wire.
We now have the situation of at least 2 files being cross linked
somehow at the inode level.
What should happen:
We have an executable file which checks the system kernel parameters
for configuration suitability to run our application this program does
all of the data formatting and stdout screen display, some of these
kernel parameters can not be interrogated from within the executable
so it calls a shell script to get these values, this first shell
script requires a number of standard environment variables to be set
so it calls a second shell script to set these at the session level,
control should return to the first shell script, which in turn gets
the required value and returns control to the executable.
The first shell script returns one numeric value as its only stdout
data. The second shell script returns no data at all to stdout.
Seems long winded but it normally works and was working up until the
mirror process was started. The 2 shell scripts can be called from
the command line as standalone scripts.
The problem:
What is now happening was identified by running the executable,
instead of running once and reporting one set of kernel values, it now
loops endlessly when it gets to the point of calling the shell
scripts. To isolate the point of failure, we have run the first shell
script from the command line and instead of the single numeric value,
it displays the formatted data from the executable as if we had run
the executable from the command line and loops.
As the first thing the first script does is call the second script,
this too has been run from the command line and it too displays data
as formatted by the executable and loops.
Using set -x as the first line of the second script it can be seem
that the script executes to the last line prior to the displaying of
the executable data, the executable then runs to the point of calling
the scripts and further tracing occurs.
We have tried
- deleting the offending files and copying them from our working
server
- restoring the entire directory from backup prior to the mirror
operation
- formatting the disk and restoring the filesystem
All with no result.
Assumption of cause:
It appears that some how the inode table has the disk blocks defined
for the second script file overlapped, cross linked or what ever you
want to call it with the blocks of the executable file, and the
overlap just happens to be at an entry point that allows the
executable to run and call the scripts.
This is the second time we have seen this kind of a problem on Solaris
10, the first time was a little simpler but was also after the same
kind of mirroring operation, we had 2 text files, when we did "cat
file1" we got two thirds the contents of the file we expected and the
entire contents of the second text file, if we did "cat file2" we only
got the contents of file 2. That time we were able to delete file 1,
and recreate it with no impact on file 2 and the problem went away.
As I have said deleting and recreating does not help this time.
Any suggestions appreciated but please keep it constructive, as I said
before I am not a sys admin so don't necessarily have the right
terminology.
.
- Prev by Date: Re: Vi as command line editor in Solaris 10.
- Next by Date: Re: MANPATH
- Previous by thread: Vi as command line editor in Solaris 10.
- Next by thread: Available Excellent Solaris System Administrator
- Index(es):
Relevant Pages
|