linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jes Sorensen <jes.sorensen@gmail.com>
To: NeilBrown <neilb@suse.com>, Shaohua Li <shli@kernel.org>
Cc: linux-raid@vger.kernel.org
Subject: Re: GET_ARRAY_INFO assumptions?
Date: Thu, 20 Apr 2017 12:05:54 -0400	[thread overview]
Message-ID: <59ca76c6-1f1f-4d9c-4eb9-d468131e0d55@gmail.com> (raw)
In-Reply-To: <87k26itx2v.fsf@notabene.neil.brown.name>

On 04/17/2017 07:48 PM, NeilBrown wrote:
> On Fri, Apr 14 2017, Jes Sorensen wrote:
>> 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?
>
> I think that it accurately mimics what the current code does.
> I'm not sure that is what we really want.
> For testing in Incremental.c if an array is "active" we really
> should be testing more than "raid_disks != 0".
> We should be testing, as Shaohua suggested, if
> array_state != 'clear' or 'inactive'.
> You cannot get that info through the ioctl interface, so I suppose
> I decided the current test was 'close enough'.
> If we are going to stop supported kernels that don't have (e.g.)
> array_state, then we should really fo the right thing and test
> array_state.

I think I got it right this time and pushed it into git. It made things 
a lot prettier too IMHO :)

In the process I also changed the behavior of 
sysfs_read(GET_ARRAY_STATE) as I really didn't like how it was copying 
in the string rather than parsing it.

I am traveling at the moment and don't yet have my new raid test box 
setup back at the office, so my testing is limited. If I broke something 
badly, feel free to throw rotten tomatoes at me.

Cheers,
Jes



  parent reply	other threads:[~2017-04-20 16:05 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
2017-04-17 23:48       ` NeilBrown
2017-04-18 16:28         ` Jes Sorensen
2017-04-20 16:05         ` Jes Sorensen [this message]
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=59ca76c6-1f1f-4d9c-4eb9-d468131e0d55@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).