linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Greaves <david@dgreaves.com>
To: Neil Brown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org, Doug Ledford <dledford@redhat.com>
Subject: Re: Partitioned arrays initially missing from /proc/partitions
Date: Mon, 07 May 2007 09:28:11 +0100	[thread overview]
Message-ID: <463EE31B.7000601@dgreaves.com> (raw)
In-Reply-To: <462DF8F1.3000306@dgreaves.com>

Hi Neil

Just wondering what the status is here - do you need any more from me or is it
on your stack?

The patch helped but didn't cure.
After a clean boot it mounted correctly first try.
Then I unmounted, stopped and re-assembled the array.
The next mount failed.
The subsequent mount succeeded.

How do other block devices initialise their partitions on 'discovery'?

David

David Greaves wrote:
> Neil Brown wrote:
>> On Tuesday April 24, david@dgreaves.com wrote:
>>> Neil, isn't it easy to just do this after an assemble?
>> Yes, but it should not be needed, and I'd like to understand why it
>> is.
>> One of the last things do_md_run does is
>>    mddev->changed = 1;
>>
>> When you next open /dev/md_d0, md_open is called which calls
>> check_disk_change().
>> This will call into md_fops->md_media_changed which will return the
>> value of mddev->changed, which will be '1'.
>> So check_disk_change will then call md_fops->revalidate_disk which
>> will set mddev->changed to 0, and will then set bd_invalidated to 1
>> (as bd_disk->minors > 1 (being 64)).
>>
>> md_open will then return into do_open (in fs/block_dev.c) and because
>> bd_invalidated is true, it will call rescan_partitions and the
>> partitions will appear.
>>
>> Hmmm... there is room for a race there.  If some other process opens
>> /dev/md_d0 before mdadm gets to close it, it will call
>> rescan_partitions before first calling  bd_set_size to update the size
>> of the bdev.  So when we try to read the partition table, it will
>> appear to be reading past the EOF, and will not actually read
>> anything..
>>
>> I guess udev must be opening the block device at exactly the wrong
>> time. 
>>
>> I can simulate this by holding /dev/md_d0 open while assembling the
>> array.  If I do that, the partitions don't get created.
>> Yuck.
>>
>> Maybe I could call bd_set_size in md_open before calling
>> check_disk_change..
>>
>> Yep, this patch seems to fix it.  Could you confirm?
> almost...
> 
> teak:~# mdadm --assemble /dev/md_d0 --auto=parts /dev/sd[bcdef]1
> mdadm: /dev/md_d0 has been started with 5 drives.
> teak:~# mount /media
> teak:~# umount /media
> teak:~# mdadm --stop /dev/md_d0
> mdadm: stopped /dev/md_d0
> teak:~# mdadm --assemble /dev/md_d0 --auto=parts /dev/sd[bcdef]1
> mdadm: /dev/md_d0 has been started with 5 drives.
> teak:~# mount /media
> mount: No such file or directory
> teak:~# mount /media
> teak:~#
> (second mount succeeds second time around)
> 
> 
> 
> md: md_d0 stopped.
> md: bind<sdc1>
> md: bind<sdd1>
> md: bind<sdb1>
> md: bind<sdf1>
> md: bind<sde1>
> raid5: device sde1 operational as raid disk 0
> raid5: device sdf1 operational as raid disk 4
> raid5: device sdb1 operational as raid disk 3
> raid5: device sdd1 operational as raid disk 2
> raid5: device sdc1 operational as raid disk 1
> raid5: allocated 5236kB for md_d0
> raid5: raid level 5 set md_d0 active with 5 out of 5 devices, algorithm 2
> RAID5 conf printout:
>  --- rd:5 wd:5
>  disk 0, o:1, dev:sde1
>  disk 1, o:1, dev:sdc1
>  disk 2, o:1, dev:sdd1
>  disk 3, o:1, dev:sdb1
>  disk 4, o:1, dev:sdf1
> md_d0: bitmap initialized from disk: read 1/1 pages, set 0 bits, status: 0
> created bitmap (10 pages) for device md_d0
>  md_d0: p1 p2
> Filesystem "md_d0p1": Disabling barriers, not supported with external log device
> XFS mounting filesystem md_d0p1
> Ending clean XFS mount for filesystem: md_d0p1
> md: md_d0 stopped.
> md: unbind<sde1>
> md: export_rdev(sde1)
> md: unbind<sdf1>
> md: export_rdev(sdf1)
> md: unbind<sdb1>
> md: export_rdev(sdb1)
> md: unbind<sdd1>
> md: export_rdev(sdd1)
> md: unbind<sdc1>
> md: export_rdev(sdc1)
> md: md_d0 stopped.
> md: bind<sdc1>
> md: bind<sdd1>
> md: bind<sdb1>
> md: bind<sdf1>
> md: bind<sde1>
> raid5: device sde1 operational as raid disk 0
> raid5: device sdf1 operational as raid disk 4
> raid5: device sdb1 operational as raid disk 3
> raid5: device sdd1 operational as raid disk 2
> raid5: device sdc1 operational as raid disk 1
> raid5: allocated 5236kB for md_d0
> raid5: raid level 5 set md_d0 active with 5 out of 5 devices, algorithm 2
> RAID5 conf printout:
>  --- rd:5 wd:5
>  disk 0, o:1, dev:sde1
>  disk 1, o:1, dev:sdc1
>  disk 2, o:1, dev:sdd1
>  disk 3, o:1, dev:sdb1
>  disk 4, o:1, dev:sdf1
> md_d0: bitmap initialized from disk: read 1/1 pages, set 0 bits, status: 0
> created bitmap (10 pages) for device md_d0
>  md_d0: p1 p2
> XFS: Invalid device [/dev/md_d0p2], error=-2
> Filesystem "md_d0p1": Disabling barriers, not supported with external log device
> XFS mounting filesystem md_d0p1
> Ending clean XFS mount for filesystem: md_d0p1
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


  reply	other threads:[~2007-05-07  8:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-01 20:53 Partitioned arrays initially missing from /proc/partitions Mike Accetta
2007-04-23 14:56 ` David Greaves
2007-04-23 19:31   ` Mike Accetta
2007-04-23 23:52     ` Neil Brown
2007-04-24  9:22       ` David Greaves
2007-04-24 10:57         ` Neil Brown
2007-04-24 12:00           ` David Greaves
2007-04-24 10:49       ` David Greaves
2007-04-24 11:38         ` Neil Brown
2007-04-24 12:32           ` David Greaves
2007-05-07  8:28             ` David Greaves [this message]
2007-05-07  9:01               ` Neil Brown
2007-04-24 15:39           ` Doug Ledford
2007-04-24  9:37     ` David Greaves
2007-04-24  9:46       ` David Greaves

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=463EE31B.7000601@dgreaves.com \
    --to=david@dgreaves.com \
    --cc=dledford@redhat.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /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).