From: NeilBrown <neilb@suse.de>
To: "Wojcik, Krzysztof" <krzysztof.wojcik@intel.com>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: Single-drive RAID0
Date: Mon, 21 Feb 2011 13:15:19 +1100 [thread overview]
Message-ID: <20110221131519.1039f37c@notabene.brown> (raw)
In-Reply-To: <BE2BFE91933D1B4089447C644860408069028F47@irsmsx503.ger.corp.intel.com>
On Wed, 16 Feb 2011 16:57:06 +0000 "Wojcik, Krzysztof"
<krzysztof.wojcik@intel.com> wrote:
> >
> > It looks like the 'bdev' passed to md_open keeps changing, which it
> > shouldn't.
> >
> > If the above doesn't help, please add:
> >
> > printk("bdev=%p, mddev=%p, disk=%p dev=%x\n", bdev, mddev, mddev-
> > >gendisk, bdev->bd_dev);
> >
> > at the top of 'md_open', and see what it produces.
>
> I tried this also but I can't see any useful information that can make me some idea.
> Could you look at logs in attachment?
>
I've made some progress.
The struct block_device is definitely getting freed and re-allocated.
This can happen if you
mknod /dev/.tmp b 9 0
open /dev/.tmp and do stuff, then close
rm /dev/.tmp
If you open something in /dev which stays there, e.g. /dev/md0, then as long
as the inode for /dev/md0 remains in the inode cache it will hold a reference
to the block_device and so the same one will get reused.
But when to 'rm /dev/.tmp', the inode gets flushed from the cache and the
reference of the block_device is dropped. If that was the only reference
then the block_device is discarded.
Each time a new block_device is created for a given block device, it will
re-do the partition scan which will mean that the partition devices get
deleted and recreated.
Maybe you are racing with this somehow and that is how the partition devices
appear to not be there - udev is removing and recreating them.
Something you could try would be to change fs/block_dev.c.
At about line 470 you should find:
static const struct super_operations bdev_sops = {
.statfs = simple_statfs,
.alloc_inode = bdev_alloc_inode,
.destroy_inode = bdev_destroy_inode,
.drop_inode = generic_delete_inode,
.evict_inode = bdev_evict_inode,
};
If you change the 'drop_inode' line to
.drop_inode = do_not_drop_inode,
and define a function:
static int do_not_drop_inode(struct inode *inode)
{
return 0;
}
That will cause the block_device to remain in a cache for a while after the
last reference is dropped.
That should make your symptoms go away.
I'm not sure that is the "right" fix, but it should confirm what I suspect
is happening.
If it does, then we can explore more...
Did you say that this works better on earlier kernels? If so, what is the
latest kernel that you have tried that you don't have this problem on?
Thanks,
NeilBrown
next prev parent reply other threads:[~2011-02-21 2:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-08 16:15 Single-drive RAID0 Wojcik, Krzysztof
2011-02-09 2:45 ` NeilBrown
2011-02-09 14:33 ` Wojcik, Krzysztof
2011-02-14 2:11 ` NeilBrown
2011-02-14 17:04 ` Wojcik, Krzysztof
2011-02-15 0:01 ` NeilBrown
2011-02-15 16:30 ` Wojcik, Krzysztof
2011-02-16 0:42 ` NeilBrown
2011-02-16 16:57 ` Wojcik, Krzysztof
2011-02-17 0:38 ` NeilBrown
2011-02-21 2:15 ` NeilBrown [this message]
2011-02-21 14:11 ` Wojcik, Krzysztof
2011-02-22 0:50 ` NeilBrown
2011-02-22 11:50 ` Wojcik, Krzysztof
2011-02-22 16:42 ` Jan Ceuleers
2011-02-23 2:20 ` NeilBrown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110221131519.1039f37c@notabene.brown \
--to=neilb@suse.de \
--cc=krzysztof.wojcik@intel.com \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).