XFS mounting fails on MIPS

[Ajeet Yadav]

I think mips folks agree with the change. I really wish to have there
comment.

I also wish to know do we really need fix in XFS for virtual indexed
architecture, I think its generic issue as many architecture now use VIVT or
VIPT caches. Do we want to say XFS is relatively unstable with virtual
indexed architecture ?


On Thu, Nov 11, 2010 at 10:27 AM, Ajeet Yadav <ajeet.yadav.77 at gmail.com>wrote:

> Coming back to problem, I wish to know about this problem
> Linux XFS version : 2.6.34
> Architecure: MIPS
> I am getting the following error during mount.
>
> XFS mounting filesystem sda2
> Starting XFS recovery on filesystem: sda2 (logdev: internal)
> XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1518 of file
> fs/xfs/xfs_alloc.c.  Caller 0x801174a0
> Call Trace:
> [<800050bc>] dump_stack+0x8/0x34
> [<80115254>] xfs_free_ag_extent+0x128/0x7a8
> [<801174a0>] xfs_free_extent+0xa0/0xcc
> [<80155278>] xlog_recover_process_efi+0x15c/0x210
> [<801553cc>] xlog_recover_process_efis+0xa0/0x12c
> [<8015590c>] xlog_recover_finish+0x28/0xcc
> [<8015d4fc>] xfs_mountfs+0x4f0/0x5d0
> [<801758d8>] xfs_fs_fill_super+0x158/0x360
> [<8008b67c>] get_sb_bdev+0x11c/0x1c4
> [<801734e0>] xfs_fs_get_sb+0x20/0x2c
> [<80089cd0>] vfs_kern_mount+0x68/0xd0
> [<80089d9c>] do_kern_mount+0x54/0x118
> [<800a4e98>] do_mount+0x7f0/0x86c
> [<800a4fb0>] sys_mount+0x9c/0xf8
> [<80002124>] stack_done+0x20/0x3c
>
> Filesystem "sda2": XFS internal error xfs_trans_cancel at line 1161 of file
> fs/xfs/xfs_trans.c.  Caller 0x801552f8
>
> Call Trace:
> [<800050bc>] dump_stack+0x8/0x34
> [<801601f0>] xfs_trans_cancel+0x88/0x118
> [<801552f8>] xlog_recover_process_efi+0x1dc/0x210
> [<801553cc>] xlog_recover_process_efis+0xa0/0x12c
> [<8015590c>] xlog_recover_finish+0x28/0xcc
> [<8015d4fc>] xfs_mountfs+0x4f0/0x5d0
> [<801758d8>] xfs_fs_fill_super+0x158/0x360
> [<8008b67c>] get_sb_bdev+0x11c/0x1c4
> [<801734e0>] xfs_fs_get_sb+0x20/0x2c
> [<80089cd0>] vfs_kern_mount+0x68/0xd0
> [<80089d9c>] do_kern_mount+0x54/0x118
> [<800a4e98>] do_mount+0x7f0/0x86c
> [<800a4fb0>] sys_mount+0x9c/0xf8
> [<80002124>] stack_done+0x20/0x3c
>
> xfs_force_shutdown(sda2,0x8) called from line 1162 of file
> fs/xfs/xfs_trans.c.  Return address = 0x80160204
> Filesystem "sda2": Corruption of in-memory data detected.  Shutting down
> filesystem: sda2
> Please umount the filesystem, and rectify the problem(s)
> Failed to recover EFIs on filesystem: sda2
> XFS: log mount finish failed
>
> With Regards
> Ajeet Yadav
>
> On Tue, Nov 9, 2010 at 7:35 PM, Christoph Hellwig <hch at infradead.org>wrote:
>
>> Hi Ajeet,
>>
>> On Tue, Nov 09, 2010 at 04:43:04PM +0530, Ajeet Yadav wrote:
>> > True, its the same system and you were right it was cache VIPT cache
>> problem
>> > the cache hold the stale value even after xlog_bread() update the
>> buffer.
>> > I do not know whether its correct ways to resolve the problem, but the
>> > problem no longer occur.
>>
>> It seems like you more less re-implemented the vmap coherency hooks
>> inside XFS, hardcoded to the mips implementation.
>>
>> The actual helpers would looks something like:
>>
>> static inline void flush_kernel_vmap_range(void *addr, int size)
>> {
>>        dma_cache_inv(addr, size);
>> }
>>
>> static inline void invalidate_kernel_vmap_range(void *addr, int size)
>> {
>>        dma_cache_inv(addr, size);
>> }
>>
>> For some reason the kernel also expects flush_dcache_page to be
>> implemented by an architecture if we want to implement these two
>> (it's keyed off ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE).
>>
>> Can someone of the mips folks helps with this?
>>
>> The testcase is easy, mounting an xfs filesystem after an unclean
>> shutdown on a machine with virtually indexed caches.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20101111/123904b3/attachment.htm>