From: jes.sorensen@gmail.com
To: Shaohua Li <shli@kernel.org>
Cc: Tomasz Majchrzak <tomasz.majchrzak@intel.com>,
linux-raid@vger.kernel.org
Subject: Re: [PATCH 1/2] md: add bad block flag to disk state
Date: Mon, 06 Mar 2017 15:23:08 -0500 [thread overview]
Message-ID: <wrfjlgsim9xv.fsf@gmail.com> (raw)
In-Reply-To: <20170201181215.4d5nfyxmpsmgenks@kernel.org> (Shaohua Li's message of "Wed, 1 Feb 2017 10:12:15 -0800")
Shaohua Li <shli@kernel.org> writes:
> On Wed, Feb 01, 2017 at 10:53:52AM +0100, Tomasz Majchrzak wrote:
>> On Mon, Jan 30, 2017 at 03:33:41PM -0800, Shaohua Li wrote:
>> > On Tue, Jan 24, 2017 at 01:03:38PM +0100, Tomasz Majchrzak wrote:
>> > > Add a new flag to report that bad blocks are present on a disk. It will
>> > > allow userspace to notify the user of the problem.
>> > >
>> > > Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
>> > > ---
>> > > drivers/md/md.c | 2 ++
>> > > include/uapi/linux/raid/md_p.h | 1 +
>> > > 2 files changed, 3 insertions(+)
>> > >
>> > > diff --git a/drivers/md/md.c b/drivers/md/md.c
>> > > index 0abb147..1a807ec 100644
>> > > --- a/drivers/md/md.c
>> > > +++ b/drivers/md/md.c
>> > > @@ -6034,6 +6034,8 @@ static int get_disk_info(struct mddev *mddev, void __user * arg)
>> > > info.state |= (1<<MD_DISK_WRITEMOSTLY);
>> > > if (test_bit(FailFast, &rdev->flags))
>> > > info.state |= (1<<MD_DISK_FAILFAST);
>> > > + if (rdev->badblocks.count)
>> > > + info.state |= (1<<MD_DISK_BB_PRESENT);
>> >
>> > Userspace can find if a disk has badblocks by reading the bad_blocks sysfs
>> > file. Why adds another interface?
>> >
>> > Thanks,
>> > Shaohua
>>
>> Yes, indeed, it can. I have chosen to do it this way to keep it consistent
>> with mdadm which uses GET_DISK_INFO ioctl to get disk information. All data
>> provided in this ioctl is also available in sysfs file (rdev state), however
>> ioctl is still used (legacy). The same applies for details subcommand of
>> mdadm. To answer your question - yes, I could avoid new flag but it would
>> make mdadm side of my improvement much more complicated.
>
> I intended to avoid adding new user interface if possible. Not sure about this
> case though. How complicated in the mdadm side if we use the bad_block sysfs
> file?
>
> Jes, how do you think from the mdadm side?
Hi,
Sorry for being so late getting back on this, I am just getting back to
this now.
I am really split on this - if we have spare flags available, I guess
it's not the end of the World. On the other hand there is something to
be said for not adding any more using the old interface.
Right now mdadm relies heavily on the ioctl interfaces. In order to
migrate away from that, we need to spend a fair amount of time to
rewriting the general interface first. Something I think we should
invest some time into doing, but having to handle both in parallel seems
a bad idea to me.
Cheers,
Jes
next prev parent reply other threads:[~2017-03-06 20:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-24 12:03 [PATCH 0/2] Bad block notification Tomasz Majchrzak
2017-01-24 12:03 ` [PATCH 1/2] md: add bad block flag to disk state Tomasz Majchrzak
2017-01-30 23:33 ` Shaohua Li
2017-02-01 9:53 ` Tomasz Majchrzak
2017-02-01 18:12 ` Shaohua Li
2017-03-06 20:23 ` jes.sorensen [this message]
2017-03-07 6:54 ` Hannes Reinecke
2017-01-24 12:03 ` [PATCH 2/2] Monitor: add new event BadBlocks Tomasz Majchrzak
2017-01-29 17:44 ` [PATCH 0/2] Bad block notification 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=wrfjlgsim9xv.fsf@gmail.com \
--to=jes.sorensen@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=shli@kernel.org \
--cc=tomasz.majchrzak@intel.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).