[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AANLkTinNOo1_-KJ2CC_-ACBaDtmWjGX3+Vy60ND17guH@mail.gmail.com>
Date: Wed, 28 Jul 2010 12:23:11 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Jens Axboe <axboe@...nel.dk>, NeilBrown <neilb@...e.de>,
Tejun Heo <htejun@...il.com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
linux-raid <linux-raid@...r.kernel.org>,
"Neubauer, Wojciech" <Wojciech.Neubauer@...el.com>,
Ed Ciechanowski <ed.ciechanowski@...el.com>
Subject: Re: md versus partition scanning (bd_invalidated)
On Wed, Jul 21, 2010 at 12:52 PM, Dan Williams <dan.j.williams@...el.com> wrote:
> Hi,
>
> We (Intel software raid devs) are seeing a problem with the detection of
> partitions on md devices. The trace below shows that the block device
> inode is dropped in-between when the array comes up and when it is first
> opened (timestamp 655.498875). When this happens bdev->bd_invalidated
> is cleared by bdget() and we never detect partitions. (Seen on a 2.6.32
> based kernel, but I presume it is still present)
The kernel in question was missing commit f3b99be1 "Restore partition
detection of newly created md arrays" [1]. With that in place the
problem goes away. I haven't fully convinced myself that there isn't
a small race that could be triggered by changing the array size via
sysfs, to get the the gendisk size updated and then dropping all inode
references prior to the first open... but I'll put that investigation
on the back burner.
--
Dan
[1]: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f3b99be1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists