xfs
[Top] [All Lists]

Not enough memory for xfs_repair

To: linux-xfs@xxxxxxxxxxx
Subject: Not enough memory for xfs_repair
From: Torsten Wolf <t.wolf@xxxxxxxx>
Date: Mon, 26 Apr 2004 15:43:29 +0200
Organization: TU Braunschweig
Reply-to: Torsten Wolf <t.wolf@xxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.5.1+cvs20040105i
Hi,

recently, I purchased a 200GB HDD and created a single xfs partition
(hdb1) on it for storage of lots of small data files. The machine runs
under Debian/GNULinux (slightly outdated unstable) with kernel 2.4.25
and xfsprogs 2.6.5. The machine seems to suffer from flaky hardware (VIA
chipset and 1.5GB RAM) which shows up when copying large amounts of data
(several files differ afterwards). Also bzip2 complains about hardware
problems. So far so bad.

A few days ago, I wrote thousands of small files to hdb1 until the
system froze various times. Finally, the nightly updatedb produced tons
of the following messages:

Apr 25 01:31:01 sycorax kernel: 0x0: 00 80 00 5e 00 80 0d 1b 90 79 29 ff 00 97 
4c ba 
Apr 25 01:31:01 sycorax kernel: Filesystem "ide0(3,65)": XFS internal error 
xfs_da_do_buf(2) at line 2273 of file xfs_da_btree.c.  Caller 0xc01bd117
Apr 25 01:31:01 sycorax kernel: d94ddcb8 c01bcb25 c0329231 00000001 f6a85800 
c0329173 000008e1 c01bd117 
Apr 25 01:31:01 sycorax kernel: c01bd117 d94ddd20 00000000 c0204498 f6a41c80 
f6a50434 0000a201 00002000 
Apr 25 01:31:01 sycorax kernel: 00000018 00800d1d 00000000 00000001 00000000 
f6a85800 d94ddd3c 00000001 
Apr 25 01:31:01 sycorax kernel: Call Trace:    [<c01bcb25>] [<c01bd117>] 
[<c01bd117>] [<c0204498>] [<c01bd117>]
Apr 25 01:31:01 sycorax kernel: [<c01baff0>] [<c01baff0>] [<c01c7a4f>] 
[<c01bf5ba>] [<c01efd3c>] [<c01f5490>]
Apr 25 01:31:01 sycorax kernel: [<c0128713>] [<c01ffc37>] [<c0148223>] 
[<c01488cc>] [<c0148bb7>] [<c0148e49>]
Apr 25 01:31:01 sycorax kernel: [<c01456af>] [<c0108d4f>]
Apr 25 01:31:01 sycorax kernel: 3df49>] [<c0108d4f>]

So I started xfs_repair and got the following result:

sycorax:~# xfs_repair /dev/hdb1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
bad directory leaf magic # 0xd2dc for directory inode 190 block 8388642
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - clear lost+found (if it exists) ...
        - clearing existing "lost+found" inode
        - deleting existing "lost+found" entry
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - ensuring existence of lost+found directory
        - traversing filesystem starting at / ... 
empty data block 5065 in directory inode 190: junking block
unknown magic number 0xd2dc for block 8388642 in directory inode 190
rebuilding directory inode 190
xfs_repair: buf calloc failed (8228 bytes): Nicht genügend Hauptspeicher 
verfügbar

Actually, xfs_repair eats up all of my memory (1.5GB RAM + 2GB swap).
Searching google gave no useful result. So any hint how to recover this
partition is greatly appreciated.

Regards,
Torsten


<Prev in Thread] Current Thread [Next in Thread>