---- "Koustubha Kale" <koustubha_k...@yahoo.com> wrote:
| This is what I get on every run one one of the LV's i.e. Stu LV. On
| the other LV i.e. Fac, this new fsck_gfs2 did a bunch of stuff and
| exited normally.
|
(snip)
| Starting pass4
| Found unlinked inode at 380614 (0x5cec6)
| Unlinked inode has zero size
| Block 380614 (0x5cec6) seems to be free space, but is marked as inode
| in the bitmap.
| The bitmap was fixed.
| Segmentation fault
>Hi,
>
>The fsck.gfs2 should not segfault like that; that's a bug.
>But now I'm confused. Does the new fsck.gfs2 segfault as well?
>You said it did a bunch of stuff and exited normally.
>If the new fsck.gfs2 segfaults, I definitely want to get
>more info, possibly your metadata so I can recreate, find and fix
>the bug.
It was the new fsck.gfs2 which segfaulted. After that I could not mount the Stu
LV. I had to do fsck with original fsck.gfs2 to get it to mount. The original
fsck.gfs2 has never segfaulted on me so far.
As I said the new fsck.gfs2 completed the Fac LV properly but segfaulted on the
Stu LV each time I tried it. I tried it on both nodes with segfault each time
for the Stu LV.
(Not surprisingly it's the Stu LV on which is the problem most of the time as I
have mentioned in my earlier post.)
The Stu LV's metadata file is huge about 846Mb. Not sure how to give it to
you. Any other info I might supply?
Regards
Koustubha Kale
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage.
http://in.yahoo.com/
--
Linux-cluster mailing list
Linux-cluster@redhat.com
https://www.redhat.com/mailman/listinfo/linux-cluster
