[Top] [All Lists]

Re: xfs: xfs_io oops on _raw_spin_lock

To: Kamal Dasu <kdasu.kdev@xxxxxxxxx>
Subject: Re: xfs: xfs_io oops on _raw_spin_lock
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 23 Jan 2013 12:35:09 +1100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <CAC=U0a3XqDC7+14ox1bQ2iLLhuQYgsTMkq0YVos+u6_eaiRxnQ@xxxxxxxxxxxxxx>
References: <CAC=U0a3XqDC7+14ox1bQ2iLLhuQYgsTMkq0YVos+u6_eaiRxnQ@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Jan 22, 2013 at 08:24:02PM -0500, Kamal Dasu wrote:
> I am running a simple test with xfs_io on Kernel 3.3 writing in
> O_DIRECT mode and I get
> # /rt.sh
> ++ DEV=/dev/sda2
> ++ RTDEV=/dev/sda3
> ++ MNT=/mnt/xfsmnt
> ++ mkdir /mnt/xfsmnt
> ++ mkfs.xfs -f /dev/sda2 -r extsize=2m,rtdev=/dev/sda3
> meta-data=/dev/sda2              isize=256    agcount=4, agsize=983479 blks
>          =                       sectsz=512   attr=2, projid32bit=0
> data     =                       bsize=4096   blocks=3933916, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096   ascii-ci=0
> log      =internal log           bsize=4096   blocks=2560, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =/dev/sda3              extsz=2097152 blocks=240089416,
> rtextents=468924

Patches are pending in 3.8 to fix the oops, but it won't fix your

> Call Trace:
> [<8050b82c>] _raw_spin_lock+0x4/0x30
> [<8021e71c>] _xfs_buf_find+0xa4/0x364
> [<8021ec4c>] xfs_buf_get+0x44/0x1ac
> [<8021f078>] xfs_buf_read+0x28/0xf0
> [<8028c2bc>] xfs_trans_read_buf+0x204/0x304
> [<8028cb40>] xfs_rtbuf_get+0x140/0x160
> [<8028cebc>] xfs_rtfind_forw+0x8c/0x554
> [<8028e19c>] xfs_rtallocate_range+0xec/0x328
> [<8028f030>] xfs_rtallocate_extent_block+0x34c/0x3f4
> [<8028f1e0>] xfs_rtallocate_extent_size+0x108/0x3d4
> [<802901b4>] xfs_rtallocate_extent+0x190/0x1fc
> [<80249f0c>] xfs_bmap_rtalloc+0x1bc/0x3f8
> [<8024d430>] xfs_bmapi_allocate+0xec/0x354

You are using the RT device, and it's asking for a realtime bitmap
metadata block that is beyond the end of the data partition (the
realtime allocator metadata is in the main data partition). That's
the bug you need to find, because the oops is just the visible symptom
of a deeper problem. i.e. find out why the realtime allocator is
asking for a metadata block that doesn't exist....


Dave Chinner

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