From: sagi@grimberg.me (Sagi Grimberg)
Subject: [PATCH] admin-cmd: Added smart-log command support.
Date: Sun, 4 Sep 2016 11:41:09 +0300 [thread overview]
Message-ID: <ac203b28-39ed-4f2a-b0fc-f586e43c9346@grimberg.me> (raw)
In-Reply-To: <1472759103-16538-1-git-send-email-ckulkarnilinux@gmail.com>
> diff --git a/drivers/nvme/target/admin-cmd.c b/drivers/nvme/target/admin-cmd.c
> index 47c564b..7ab9c93 100644
> --- a/drivers/nvme/target/admin-cmd.c
> +++ b/drivers/nvme/target/admin-cmd.c
> @@ -14,6 +14,7 @@
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> #include <linux/module.h>
> #include <generated/utsrelease.h>
> +#include <asm/unaligned.h>
> #include "nvmet.h"
>
> u32 nvmet_get_log_page_len(struct nvme_command *cmd)
> @@ -29,8 +30,84 @@ u32 nvmet_get_log_page_len(struct nvme_command *cmd)
> return len;
> }
>
> +static u16 nvmet_get_smart_log_nsid(struct nvmet_req *req,
> + struct nvme_smart_log *slog)
> +{
> + u16 status;
> + struct nvmet_ns *ns;
> + u64 host_reads, host_writes, data_units_read, data_units_written;
> +
> + status = NVME_SC_SUCCESS;
> + ns = nvmet_find_namespace(req->sq->ctrl, req->cmd->get_log_page.nsid);
> + if (!ns) {
> + status = NVME_SC_INVALID_NS;
> + pr_err("nvmet : Counld not find namespace id : %d\n",
> + le32_to_cpu(req->cmd->get_log_page.nsid));
> + goto out;
> + }
> +
> + host_reads = part_stat_read(ns->bdev->bd_part, ios[READ]);
> + data_units_read = part_stat_read(ns->bdev->bd_part, sectors[READ]);
> + host_writes = part_stat_read(ns->bdev->bd_part, ios[WRITE]);
> + data_units_written = part_stat_read(ns->bdev->bd_part, sectors[WRITE]);
> +
> + put_unaligned_le64(host_reads, &slog->host_reads[0]);
> + put_unaligned_le64(data_units_read, &slog->data_units_read[0]);
> + put_unaligned_le64(host_writes, &slog->host_writes[0]);
> + put_unaligned_le64(data_units_written, &slog->data_units_written[0]);
> + nvmet_put_namespace(ns);
> +out:
> + return status;
> +}
Given that we don't own the namespaces, I'm wandering if this is the
correct way to do this... I'm not at all convinced that having something
else reading/writing to the blkdevs other than nvmf is a valid/useful
use-case but in this situation we won't get correct log information
(or at least the semantics is wrong).
Should we maintain these statistics in the target stack instead?
next prev parent reply other threads:[~2016-09-04 8:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-01 19:45 [PATCH] admin-cmd: Added smart-log command support Chaitanya Kulkarni
2016-09-04 8:41 ` Sagi Grimberg [this message]
2016-09-05 13:11 ` Christoph Hellwig
2016-09-05 14:09 ` Sagi Grimberg
2016-09-20 19:00 ` Sagi Grimberg
2016-09-20 20:03 ` Christoph Hellwig
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=ac203b28-39ed-4f2a-b0fc-f586e43c9346@grimberg.me \
--to=sagi@grimberg.me \
/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.