> "D. Stimits" wrote:
> >
> > I have an SMP system set to boot to X11/runlevel 5 that is RH 7.1 based
> > (root is XFS). I had a crash at the moment I attempted to start login as
> > a regular user (home is also XFS). It seems that ~/.ICEauthority is
> > written each session when gdm/gnome is used for the login session, and
> > that a check is done for whether or not .ICEauthority can be locked.
> > After a crash, the file is empty (this is ok, it's the metadata versus
> > full journal thing, it isn't an issue), since the crash occurs during
> > that file write. However, after coming back up, X11 will fail due to an
> > inability to lock the file. A question occurs here, whether lock data or
> > whatever information is used to determine if a file can be locked, is
> > part of the filesystem journaling? Or is this a separate issue that
> > can't be dealth with by journaling filesystems? Is there any way XFS,
> > coming back after a crash, can remove stale locks or bogus locks? I have
> > no idea if this is entirely just coincidence it occurs, or if XFS itself
> > can help recover under such circumstances.
> >
> > D. Stimits, stimits@xxxxxxxxxx
>
> Since nobody has said anything, let me rephrase the question. There are
> custom lock file schemes, which I am not interested in. There *is* fcntl
> to perform locking. Ignoring lock files, is there any metadata or
> filesystem data that is altered when using fcntl to lock? If so, it is a
> "bad thing" to preserve locked status upon recovery...it should be
> cleared, else the file can't be reopened and locked. During recovery, it
> can be assumed that the original application no longer should have a
> lock...it's long dead.
I did respond - twice, but I am operating on a temporary workstation here
due to a head crash and my mail setup appears not to be all it could be.
In my first message I said:
>> Usually part of the start up process of a system should be to clean up
>> the junk left behind by the last shutdown/crash/power outage. I
>> suspect this is really a case of the cleanup not being there, or of
>> the logic in X being a little flakey, the file exists, ergo....
>>
>> The only part a filesystem plays in file locking in linux is to store
>> the bit in the mode word of the inode that mandatory locking should be
>> used, all the rest of the code is above the filesystem level.
In my second response, I looked more closely at the code and wrote this:
>> There appears to be no filesystem involvement in file locks via fcntl,
>> there is no call into filesystem code from the file locking fcntl, so
>> I do not see an XFS issue here.
Steve
>
> D. Stimits, stimits@xxxxxxxxxx
|