All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jes Sorensen <jes.sorensen@gmail.com>
To: NeilBrown <neilb@suse.com>
Cc: linux-raid@vger.kernel.org
Subject: GET_ARRAY_INFO assumptions?
Date: Thu, 13 Apr 2017 13:50:06 -0400	[thread overview]
Message-ID: <ab07d303-85fb-e912-e4fa-9ee66a1277cc@gmail.com> (raw)

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.

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'?

Thoughts?

Jes

diff --git a/util.c b/util.c
index a695c45..99ed015 100644
--- a/util.c
+++ b/util.c
@@ -200,6 +200,22 @@ out:
         return ret;
  }

+int md_valid_array(int fd)
+{
+       struct mdinfo *sra;
+       struct mdu_array_info_s array;
+       int ret;
+
+       sra = xcalloc(1, sizeof(*sra));
+       ret = sysfs_init(sra, fd, NULL);
+       free(sra);
+
+       if (ret)
+               ret = ioctl(fd, GET_ARRAY_INFO, &array);
+
+       return !ret;
+}
+
  /*
   * Get array info from the kernel. Longer term we want to deprecate the
   * ioctl and get it from sysfs.

             reply	other threads:[~2017-04-13 17:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-13 17:50 Jes Sorensen [this message]
2017-04-13 20:37 ` GET_ARRAY_INFO assumptions? 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
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=ab07d303-85fb-e912-e4fa-9ee66a1277cc@gmail.com \
    --to=jes.sorensen@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.