linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jes Sorensen <jes.sorensen@gmail.com>
To: Shaohua Li <shli@kernel.org>
Cc: NeilBrown <neilb@suse.com>, linux-raid@vger.kernel.org
Subject: Re: GET_ARRAY_INFO assumptions?
Date: Fri, 14 Apr 2017 11:48:57 -0400	[thread overview]
Message-ID: <c0a29266-fdf4-2f07-aabd-6aa1f55d7d46@gmail.com> (raw)
In-Reply-To: <0c3633e4-df8c-c59a-17d4-917495931ba1@gmail.com>

On 04/13/2017 05:06 PM, Jes Sorensen wrote:
> On 04/13/2017 04:37 PM, Shaohua Li wrote:
>> On Thu, Apr 13, 2017 at 01:50:06PM -0400, Jes Sorensen wrote:
>>> Hi Neil,
>>>
>>> Looking at trying to phase out the ioctl usage, I am trying to
>>> introduce a
>>> helper for the 'is the array valid' situation.
>>>
>>> Now looking at places like Incremental.c (around like 557 in my current
>>> tree):
>>>     /* 7b/ if yes, */
>>>     /* - if number of OK devices match expected, or -R and there */
>>>     /*             are enough, */
>>>     /*   + add any bitmap file  */
>>>     /*   + start the array (auto-readonly). */
>>>
>>>     if (md_get_array_info(mdfd, &ainf) == 0) {
>>>         if (c->export) {
>>>             printf("MD_STARTED=already\n");
>>>         } else if (c->verbose >= 0)
>>>             pr_err("%s attached to %s which is already active.\n",
>>>                    devname, chosen_name);
>>>         rv = 0;
>>>         goto out_unlock;
>>>     }
>>>
>>> I am wondering if there are any side effects/assumptions about
>>> GET_ARRAY_INFO that I am not considering? Basically I am making the
>>> assumption that if /sys/block/md<X>/md exists, the array is valid.
>>
>> what does 'valid' really mean? md<x>/md exists after a md device is
>> allocated,
>> the md device might not have any under layer disks bound yet.
>>
>>> The code in Incremental.c already deals with sysfs higher up in the
>>> code, so
>>> I guess the question is if the above test is even relevant anymore?
>>>
>>> Alternative, do we need export a new state in sysfs 'running'?
>>
>> I'd assume 'running' means the md device has a personality attached. See
>> array_state_show(), !running == 'clear' or 'inactive'.
>
> Good point, I guess what I am trying to figure out is what is assumed
> when ioctl(GET_ARRAY_INFO) returns 0 and how do we map it to sysfs?

Looking some more at this, it may be simpler than I thought. How about 
this approach (only compile tested):

int md_array_active(int fd)
{
	struct mdinfo *sra;
	struct mdu_array_info_s array;
	int ret;

	sra = sysfs_read(fd, NULL, GET_VERSION | GET_DISKS);
	if (sra) {
		if (!sra->array.raid_disks &&
		    !(sra->array.major_version == -1 &&
		      sra->array.minor_version == -2))
			ret = -ENODEV;
		else
			ret = 0;

		free(sra);
	} else {
		ret = ioctl(fd, GET_ARRAY_INFO, &array);
	}

	return !ret;
}

Note 'major = -1 && minor = -2' is sysfs_read's way of saying 'external'.

This pretty much mimics what the kernel does in the ioctl handler for 
GET_ARRAY_INFO:

	case GET_ARRAY_INFO:
		if (!mddev->raid_disks && !mddev->external)
			err = -ENODEV;
		else
			err = get_array_info(mddev, argp);
		goto out;

What do you think?

Cheers,
Jes


  reply	other threads:[~2017-04-14 15:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-13 17:50 GET_ARRAY_INFO assumptions? Jes Sorensen
2017-04-13 20:37 ` Shaohua Li
2017-04-13 21:06   ` Jes Sorensen
2017-04-14 15:48     ` Jes Sorensen [this message]
2017-04-17 23:48       ` NeilBrown
2017-04-18 16:28         ` Jes Sorensen
2017-04-20 16:05         ` Jes Sorensen
2017-04-20 21:49           ` NeilBrown
2017-04-21 16:13             ` Jes Sorensen
2017-04-21 14:06           ` Tomasz Majchrzak
2017-04-21 16:08             ` Jes Sorensen

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=c0a29266-fdf4-2f07-aabd-6aa1f55d7d46@gmail.com \
    --to=jes.sorensen@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.com \
    --cc=shli@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).