"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.
D. Stimits, stimits@xxxxxxxxxx
|