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