Eric Sandeen wrote:
On Fri, 25 Jun 2004, Raphael Bauduin wrote:
I've looked at older logs and those messages appeared at a boot of 3 december,
also followed by this:
Dec 3 10:18:19 dotnet kernel: Starting XFS recovery on filesystem: sd(8,38)
(dev: 8/38)
Dec 3 10:18:19 dotnet kernel: Ending XFS recovery on filesystem: sd(8,38)
(dev: 8/38)
What's the exact meaning of these messages? Does it mean the partition was not
cleanly unmounted?
that does mean that it was not cleanly unmounted, and it is using
the journal/log for recovery. This is normal xfs operation.
If the partition is not cleanly unmounted at each boot, could it result in a
partition error like I had?
It should not; xfs is designed to replay the log to get a consistent
filesystem after an unclean shutdown.
Note that if you point xfs_check or xfs_repair at a filesystem with a
dirty log, you will see inconsistencies - both of these tools require
a clean log to operate. mount/umount to be sure your log is clean.
-Eric
Hi,
just to give a little update. An xfs_repair worked fine and the partition is
working fine.
The problem came of this:
on this partition, we have several chrooted environments running, and when the server is shut down,
all processes in the chrooted env is stopped. That's where the problem was: some processes were not
stopped.
When running xfs_repair, it outputted messages about unavailable files (ssh.pid
and apache.pid), which corresponds
to the peocesses that were not stopped cleanly in the chrooted environments.....
Everything seems to be running fine now.
Raph
|