Steve Lord wrote:
>
> > "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
Is it safe then to say that "...mode word of the inode that mandatory
locking should be used..." does not actually get preserved in the
metadata? It could be apples and oranges comparison, that mandatory
locking should be used, versus actual storage of a bit that says locking
has occurred...therefore is it correct that the mandatory locking bit
does not actually preserve the idea that a file is currently locked or
not locked? If it does preserve anything about the currently locked
state, it should probably be cleared after a recovery (it's hard to have
a file locked during a recovery...it would be fairly safe to assume no
process is actually locking it).
D. Stimits, stimits@xxxxxxxxxx
|