Message-ID: <40E408D4.5070305@be.easynet.net>
Date: Thu, 01 Jul 2004 14:51:32 +0200
From: Raphael Bauduin <raphael.bauduin@be.easynet.net>
User-Agent: Mozilla Thunderbird 0.5 (X11/20040208)
MIME-Version: 1.0
To: Eric Sandeen <sandeen@sgi.com>
CC: evilninja <evilninja@gmx.net>, linux-xfs@oss.sgi.com
Subject: Re: XFS partition problem
References: <Pine.LNX.4.44.0406250939500.14663-100000@penguin.americas.sgi.com>
In-Reply-To: <Pine.LNX.4.44.0406250939500.14663-100000@penguin.americas.sgi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-xfs-bounce@oss.sgi.com
Errors-to: linux-xfs-bounce@oss.sgi.com
Precedence: bulk

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