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.
next 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 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).