xfs_repair never finishes on lvm partition

xfs_repair never finishes on lvm partition

[Knowledge Seeker]

[-- Attachment #1.1: Type: text/plain, Size: 1973 bytes --]

Hi,

I've sent the below message to the Debian Users list and they told me to
send it here.

I'm using Debian Lenny box with 2 hds.

The first one is used by the OS and the second one is another system witch
runs in virtual machine (Virtual Box).
This virtual machine also runs Debian Lenny.

The vm's hd has 2 fdisk partitions, one being LVM.

On the last week, due a power failure, there was a corruption in the file
system of my home xfs partition inside the LVM.
When  I tried to access it, my OS answered that it's not a file or a
directory.
Umounting and mounting again, the error persists.
I tried an xfs_check and it said to mount and umount the filesystem and if
it does not work to run xfs_repair with -L.
I tried it a couple of times and it didn't work, so I ran xfs_repair -L
/dev/mapper/storage-home

On Phase 6, it just freezes in:

bad hash table for directory inode 2147483859 (no data entry): rebuilding
rebuilding directory inode 2147483859

And never finish.
I let running for 2 days long.

When I use ps to see the state:

 2359 pts/0    Sl+    0:11 xfs_repair -L /dev/mapper/storage-home

Interruptible sleep (waiting for an event to complete), multi threaded, in
foreground.

It just stoped when I sent an interrupt signal Ctrl+C.

I tried to do the same from the host machine (real machine), since the HD
could be accessed from it.
The funniest thing is that the xfs_repair did not hang, but when I try to
mount the partition it does not mount the  full partition.
An ls in the /mnt mounting /dev/storage/home (from host machine), doesn't
show the /home, it shows a subdirectory from /home.
And if I start again the Virtual Machine, it prints the same error: /home is
not file or directory.

Weird..


Extra information:
The versions:
# xfs_repair -V
xfs_repair version 2.9.8

#fstab entry
/dev/mapper/storage-home /home           xfs     defaults        0       2

Some one have any idea, how to solve it?

Thanks in advance

Regards

-- 
Knoseeker

[-- Attachment #1.2: Type: text/html, Size: 2252 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs_repair never finishes on lvm partition

[Dave Chinner]

On Mon, Oct 04, 2010 at 02:57:42AM +0000, Knowledge Seeker wrote:
> Extra information:
> The versions:
> # xfs_repair -V
> xfs_repair version 2.9.8

upgrade to a more recent version - that is positively ancient ;)

Then if it still freezes in pahse 6, run with the -P option to turn
off prefetching (slower, but should prevent the hang).

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs_repair never finishes on lvm partition

[Eric Sandeen]

Dave Chinner wrote:
> On Mon, Oct 04, 2010 at 02:57:42AM +0000, Knowledge Seeker wrote:
>> Extra information:
>> The versions:
>> # xfs_repair -V
>> xfs_repair version 2.9.8
> 
> upgrade to a more recent version - that is positively ancient ;)
> 
> Then if it still freezes in pahse 6, run with the -P option to turn
> off prefetching (slower, but should prevent the hang).

And before that, if you'd like to preserve something for us to
look at, run 

# xfs_metadump /dev/blah imagefile

to capture the state of the fs which was causing problems.

-Eric

> Cheers,
> 
> Dave.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs_repair never finishes on lvm partition

[Knowledge Seeker]

[-- Attachment #1.1: Type: text/plain, Size: 1127 bytes --]

Thanks for the help.

The good news is running -P option works and the FS is ok.
The Bad news is that names of files were lost, all the files were moved to
lost+find.
Is there any easy way to recover it, or the solution is the hard way?

Sorry about the xfs_metadump, I ran the xfs_repair, before read all
messages.
If it happens again (I hope it doesnt), the first thing I'll do is send it.

Thank you again.






On Mon, Oct 4, 2010 at 1:50 PM, Eric Sandeen <sandeen@sandeen.net> wrote:

> Dave Chinner wrote:
> > On Mon, Oct 04, 2010 at 02:57:42AM +0000, Knowledge Seeker wrote:
> >> Extra information:
> >> The versions:
> >> # xfs_repair -V
> >> xfs_repair version 2.9.8
> >
> > upgrade to a more recent version - that is positively ancient ;)
> >
> > Then if it still freezes in pahse 6, run with the -P option to turn
> > off prefetching (slower, but should prevent the hang).
>
> And before that, if you'd like to preserve something for us to
> look at, run
>
> # xfs_metadump /dev/blah imagefile
>
> to capture the state of the fs which was causing problems.
>
> -Eric
>
> > Cheers,
> >
> > Dave.
>
>


-- 
Knoseeker

[-- Attachment #1.2: Type: text/html, Size: 1616 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs_repair never finishes on lvm partition

[Ion Badulescu]

Hello,

Sorry for highjacking this old thread from last year. I actually ran into 
the same situation as the original poster, using xfsprogs-3.1.5 on kernel 
2.6.38.7. Using xfs_repair -P fixed the issue, and I also managed to get a 
metadump before repairing it so you guys can take a look and maybe fix the 
prefetch mode.

The strace of the xfs_repair, for what it's worth, seems to show a 
complete deadlock with all threads waiting on futexes:

# strace -f -F -p 8315
Process 8374 attached with 6 threads - interrupt to quit
[pid  8374] futex(0x7f2336d20a84, FUTEX_WAIT, 4, NULL <unfinished ...>
[pid  8373] futex(0x7f2336d20a84, FUTEX_WAIT, 3, NULL) = -1 EAGAIN (Resource temporarily unavailable)
[pid  8372] futex(0x7f2336d20a84, FUTEX_WAIT, 2, NULL <unfinished ...>
[pid  8373] futex(0x7f2336d20a84, FUTEX_WAIT, 4, NULL <unfinished ...>
[pid  8372] <... futex resumed> )       = -1 EAGAIN (Resource temporarily unavailable)
[pid  8372] futex(0x7f2336d20a84, FUTEX_WAIT, 4, NULL <unfinished ...>
[pid  8371] futex(0x7f2336d20a84, FUTEX_WAIT, 1, NULL) = -1 EAGAIN (Resource temporarily unavailable)
[pid  8370] futex(0x7f2336d20b08, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid  8371] futex(0x7f2336d20a84, FUTEX_WAIT, 4, NULL <unfinished ...>
[pid  8315] futex(0x7f2336d1f958, FUTEX_WAIT, 2, NULL^C <unfinished ...>
Process 8315 detached
Process 8370 detached
Process 8371 detached
Process 8372 detached
Process 8373 detached
Process 8374 detached

The metadump is 4.2GB, off of a 2.2TB filesystem. If there are interested 
parties, I can arrange to put online somewhere for an http download.

Thanks,
-Ion

-- 
   It is better to keep your mouth shut and be thought a fool,
             than to open it and remove all doubt.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs