Hi Junfeng - I'm going to be out for a week, starting tomorrow, and no
time to look at this today, I'm afraid... Sending on to some other xfs
folks in the interim.
I hope this isn't the result of the quick-hack 2.4.19 backport, but it
sure could be...
-Eric
Junfeng Yang wrote:
> Hi Eric,
>
> Our tool failed to mount a filesystem image using the patch you gave me
> (latest xfs for 2.4.19).
>
> the image was created by
> 1. making a new fs by mkfs.xfs. commands are as follows:
>
> dd if=/dev/zero of=/tmp/junfeng/cmc_blkdev_1_0_xfs_1006 bs=40960000 count=1
> sbin/mkfs.xfs -q -d agcount=2 /tmp/junfeng/cmc_blkdev_1_0_xfs_1006
>
> 2. mounting the image in a user-mode-linux kernel
>
> 3. creating two files
>
> 4. running kupdated
>
> 5. crash the user-mode-linux kernel at certain point. in this case, the
> kernel was crashed after block 40034 was written out and first sector of
> block 40042 was written out.
>
> Out tool then tried to remount the image to recover the journal. But the
> remount attempt failed with the following error message:
>
> <4>XFS: failed to read root inode
>
> It turns out that at line 348 of xfs_mount.c ,
> error = xfs_iget(mp, NULL, sbp->sb_rootino, XFS_ILOCK_EXCL, &rip,
> 0);
>
> failed because sbp->sb_rootino is 0. it was 128 before, but was
> overwritten during log recovery.
>
> Can you try to remount it using your xfs copy? I'm not sure if this is a
> real xfs bug, or a bug generated when i applied the user mode linux patch
> (our tool can only run in user land).
>
> Thanks,
> -Junfeng
|