Date: Fri, 15 Mar 2002 09:58:49 +1100
From: Nathan Scott <nathans@sgi.com>
To: Benito Venegas <venevene@securities.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: xfs_repair problem
Message-ID: <20020315095849.O24252@wobbly.melbourne.sgi.com>
References: <3C90D5F2.9030607@securities.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3C90D5F2.9030607@securities.com>; from venevene@securities.com on Thu, Mar 14, 2002 at 11:55:14AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, Mar 14, 2002 at 11:55:14AM -0500, Benito Venegas wrote:
> Hi boys and girls:
> 

hi there Benito,

> I have a problem in one my servers in India.
> Local sysadmin lost access to /dev/sdb1 partition
> after blackout :/

Does that mean it failed to mount after the blackout?  Was there
a syslog message, if so?

> Device Boot    Start       End    Blocks   Id  System
> /dev/sdb1             1     13215 106149456   83  Linux
> 
> The problem came to us, when local sysadmin in India had an old kernel 
> version. (2.4.2)
> 
> He traid to run xfs_reapir but after 10 minutes running, it gave this error
> 
> xfs_repair:buf calloc failed cannot allocate memrory
> 
> After that, I upgreaded kernel version and tools.
> We ran xfs_repair in single mode and now we got this message:
> 
> xfs_repair running in single mode. waiting for any message.....
> error message:
> fatal error -- can't read block 0 for directory 210516126

[is "single mode" the same as "single-user mode"?]

Both of these error messages suggest that xfs_repair is running
out of memory.

> We don't want to run xfs_repair with -L switch option, to avoid loose 
> important information (we do backups but runs once a day, and this 
> happend before backup process :/ )

>From your description above, it sounds like -L will not be useful
to you (xfs_repair will tell you when the -L option could be useful).

> Doctors, any idea about if I can save this patient?
> :/
> 

Can you send the full xfs_repair output, and see whether there's
anything else chewing up memory while xfs_repair is running, or
whether xfs_repair itself is the cause (run "top" while xfs_repair
is running, and keep an eye on memory use).  If you can cut and
paste all the output/save to a file and then send it to us, that
will be a help.

cheers.

-- 
Nathan