Re: XFS partition problem

[Raphael Bauduin <raphael.bauduin@xxxxxxxxxxxxxx>]

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