Giter Site home page Giter Site logo

linux-nvme / nvme-cli Goto Github PK

View Code? Open in Web Editor NEW
1.4K 113.0 644.0 12.31 MB

NVMe management command line interface.

Home Page: https://nvmexpress.org

License: GNU General Public License v2.0

C 92.87% Shell 2.20% Makefile 0.05% Python 3.20% Meson 0.67% Roff 1.01%

nvme-cli's Introduction

nvme-cli

Coverity Scan Build Status MesonBuild GitHub

NVM-Express user space tooling for Linux.

Build from source

nvme-cli uses meson as build system. There is more than one way to configure and build the project in order to mitigate meson dependency on the build environment.

If you build on a relative modern system, either use meson directly or the Makefile wrapper.

Older distros might ship a too old version of meson, in this case it's possible to build the project using samurai and muon. Both build tools have only a minimal dependency on the build environment. Too easy this step there is a build script which helps to setup a build environment.

nvme-cli dependencies:

Library Dependency Notes
libnvme, libnvme-mi yes be either installed or included into the build via meson fallback feature
json-c optional recommended, without all plugins are disabled and json-c output format is disabled

Build with meson

Configuring

In case libnvme is not installed on the system, it possible to use meson's fallback feature to resolve the dependency.

$ meson setup --force-fallback-for=libnvme .build

If the libnvme is already installed on the system meson is using pkg-config to find the dependency. In this case a plain setup call is enough:

$ meson setup .build

With meson's --wrap-mode argument it's possible to control if the additional dependencies should also resolved or not. The options are

--wrap-mode {default,nofallback,nodownload,forcefallback,nopromote}

Note for nvme-cli the 'default' is set to nofallback.

Building

$ meson compile -C .build

Installing

# meson install -C .build

Build with build.sh wrapper

The scripts/build.sh is used for the CI build but can also be used for configuring and building the project.

Running scripts/build.sh without any argument builds the project in the default configuration (meson, gcc and defaults)

It's possible to change the compiler to clang

scripts/builds.sh -c clang

or enabling all the fallbacks

scripts/build.sh fallback

Minimal static build with muon

scripts/build.sh -m muon will download and build samurai and muon instead using meson to build the project. This reduces the dependency on the build environment to:

  • gcc
  • make
  • git

Furthermore, this configuration will produce a static binary.

Build with Makefile wrapper

There is a Makefile wrapper for meson for backwards compatibility

$ make
# make install

Note in this case libnvme needs to be installed by hand first.

RPM build support via Makefile that uses meson

$ make rpm

Static binary(no dependency) build support via Makefile that uses meson

$ make static

If not sure how to use, find the top-level documentation with:

$ man nvme

Or find a short summary with:

$ nvme help

Distro Support

Many popular distributions (Alpine, Arch, Debian, Fedora, FreeBSD, Gentoo, Ubuntu, Nix(OS), openSUSE, ...) and the usual package name is nvme-cli.

OpenEmbedded/Yocto

An nvme-cli recipe is available as part of the meta-openembeded layer collection.

Buildroot

nvme-cli is available as buildroot package. The package is named nvme.

Developers

You may wish to add a new command or possibly an entirely new plug-in for some special extension outside the spec.

This project provides macros that help generate the code for you. If you're interested in how that works, it is very similar to how trace events are created by Linux kernel's 'ftrace' component.

Add command to existing built-in

The first thing to do is define a new command entry in the command list. This is declared in nvme-builtin.h. Simply append a new "ENTRY" into the list. The ENTRY normally takes three arguments: the "name" of the subcommand (this is what the user will type at the command line to invoke your command), a short help description of what your command does, and the name of the function callback that you're going to write. Additionally, You can declare an alias name of subcommand with fourth argument, if needed.

After the ENTRY is defined, you need to implement the callback. It takes four arguments: argc, argv, the command structure associated with the callback, and the plug-in structure that contains that command. The prototype looks like this:

int f(int argc, char **argv, struct command *cmd, struct plugin *plugin);

The argc and argv are adjusted from the command line arguments to start after the sub-command. So if the command line is "nvme foo --option=bar", the argc is 1 and argv starts at "--option".

You can then define argument parsing for your sub-command's specific options then do some command specific action in your callback.

Add a new plugin

The nvme-cli provides macros to make define a new plug-in simpler. You can certainly do all this by hand if you want, but it should be easier to get going using the macros. To start, first create a header file to define your plugin. This is where you will give your plugin a name, description, and define all the sub-commands your plugin implements.

There is a very important order on how to define the plugin. The following is a basic example on how to start this:

File: foo-plugin.h

#undef CMD_INC_FILE
#define CMD_INC_FILE plugins/foo/foo-plugin

#if !defined(FOO) || defined(CMD_HEADER_MULTI_READ)
#define FOO

#include "cmd.h"

PLUGIN(NAME("foo", "Foo plugin"),
	COMMAND_LIST(
		ENTRY("bar", "foo bar", bar)
		ENTRY("baz", "foo baz", baz)
		ENTRY("qux", "foo quz", qux)
	)
);

#endif

#include "define_cmd.h"

In order to have the compiler generate the plugin through the xmacro expansion, you need to include this header in your source file, with pre-defining macro directive to create the commands.

To get started from the above example, we just need to define "CREATE_CMD" and include the header:

File: foo-plugin.c

#include "nvme.h"

#define CREATE_CMD
#include "foo-plugin.h"

After that, you just need to implement the functions you defined in each ENTRY, then append the object file name to the meson.build "sources".

meson tips

In case meson doesn't find libnvme header files (via pkg-config) it will fallback using subprojects. meson checks out libnvme in subprojects directory as git tree once to the commit level specified in the libnvme.wrap file revision parm. After this initial checkout, the libnvme code level will not change unless explicitly told. That means if the current branch is updated via git, the subprojects/libnvme branch will not updated accordingly. To update it, either use the normal git operations or the command:

$ meson subprojects update

Dependency

libnvme depends on the /sys/class/nvme-subsystem interface which was introduced in the Linux kernel release v4.15. Hence nvme-cli 2.x is only working on kernels >= v4.15. For older kernels nvme-cli 1.x is recommended to be used.

How to contribute

There are two ways to send code changes to the project. The first one is by sending the changes to [email protected]. The second one is by posting a pull request on github. In both cases please follow the Linux contributions guidelines as documented in

https://docs.kernel.org/process/submitting-patches.html#

That means the changes should be a clean series (no merges should be present in a github PR for example) and every commit should build.

See also https://opensource.com/article/19/7/create-pull-request-github

How to cleanup your series before creating PR

This example here assumes, the changes are in a branch called fix-something, which branched away from master in the past. In the meantime the upstream project has changed, hence the fix-something branch is not based on the current HEAD. Before posting the PR, the branch should be rebased on the current HEAD and retest everything.

For example rebasing can be done by following steps

# Update master branch
#   upstream == https://github.com/linux-nvme/nvme-cli.git
$ git switch master
$ git fetch --all
$ git reset --hard upstream/master

# Make sure all dependencies are up to date and make a sanity build
$ meson subprojects update
$ ninja -C .build

# Go back to the fix-something branch
$ git switch fix-something

# Rebase it to the current HEAD
$ git rebase master
[fixup all merge conflicts]
[retest]

# Push your changes to github and trigger a PR
$ git push -u origin fix-something

Persistent, volatile configuration

Persistent configurations can be stored in two different locations: either in the file /etc/nvme/discovery.conf using the old style, or in the file /etc/nvme/config.json using the new style.

On the other hand, volatile configurations, such as those obtained from third-party tools like nvme-stats or blktests' can be stored in the /run/nvme directory. When using the nvme-cli tool, all these configurations are combined into a single configuration that is used as input.

The volatile configuration is particularly useful for coordinating access to the global resources among various components. For example, when executing blktests for the FC transport, the nvme-cli udev rules can be triggered. To prevent interference with a test, blktests can create a JSON configuration file in /run/nvme to inform nvme-cli that it should not perform any actions triggered from the udev context. This behavior can be controlled using the --context argument.

For example a blktests volatile configuration could look like:

[
  {
    "hostnqn": "nqn.2014-08.org.nvmexpress:uuid:242d4a24-2484-4a80-8234-d0169409c5e8",
    "hostid": "242d4a24-2484-4a80-8234-d0169409c5e8",
    "subsystems": [
      {
	"application": "blktests",
        "nqn": "blktests-subsystem-1",
        "ports": [
          {
            "transport": "fc",
	    "traddr": "nn-0x10001100aa000001:pn-0x20001100aa000001",
	    "host_traddr": "nn-0x10001100aa000002:pn-0x20001100aa000002"
          }
        ]
      }
    ]
  }
]

Note when updating the volatile configuration during runtime, it should done in a an atomic way. For example create a temporary file without the .json file extension in /run/nvme and write the contents to this file. When finished use rename to add the '.json' file name extension. This ensures nvme-cli only sees the complete file.

Testing

For testing purposes a x86_64 AppImage is build from the current HEAD and is available here:

https://monom.org/linux-nvme/upload/AppImage/nvme-cli-latest-x86_64.AppImage

nvme-cli's People

Contributors

birkelund avatar bpaupore-wdc avatar bsdimp avatar bvanassche avatar calebsander avatar chaitanayakulkarni avatar dependabot[bot] avatar hanumanthuh avatar hreinecke avatar igaw avatar ikegami-t avatar jeff-lien-wdc avatar jk-ozlabs avatar jsmart-gh avatar jupitercannon avatar keithbusch avatar leitao avatar lgdacunh avatar martin-gpy avatar matiasbjorling avatar minwooim avatar mwilck avatar rbates0119 avatar revanthrajashekar avatar sagigrimberg avatar samiwaheed avatar sbates130272 avatar sc108-lee avatar tbzatek avatar xahmad avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

nvme-cli's Issues

make fails with 'error: format not a string literal and no format arguments [-Werror=format-security]'

I am trying to build nvme-cli on latest Ubuntu 14.04 trusty, but it fails with:
nvme-cli$ make
cc -c -I -m64 -std=gnu99 -O2 -g -pthread -D_GNU_SOURCE -D_REENTRANT -Wall -Werror ./src/argconfig.c
./src/argconfig.c: In function ‘argconfig_print_help’:
./src/argconfig.c:161:5: error: format not a string literal and no format arguments [-Werror=format-security]
printf(buf);
^
cc1: all warnings being treated as errors
make: *** [argconfig.o] Error 1

I replaced the printf with
*fputs(buf, stderr);
and the make runs through. Maybe you can take a look at that!

All the best, Georg

Command line processing

Hi

In order to reduce code volume we propose migrating command line processing to argconfig. This also allows for scientific suffix support in command line arguments (e.g. 4k, 1M etc).

Stephen

Facing problem in using the command mentioned in the list

Hi Guys
i am facing problem in uses of the command mentioned in list:
id_ns
i am able to use the first command but others i can not.i had done all the setup which required for using NVMe-Cli like compiling kernel version 3.19 and others done.just need the syntax to execute these command.can anyone help me.
Thanks
Rajnikant

Add support for fibre-channel

Hi Guys,
I would like to add this patch to nvme-cli
add-fc-support.txt
tool to add support for a fibre-channel host address as well as a port address. If you are Ok with this change then I'll submit a pull request.:
nvme-cli: Add support for Fibre-channel host address

   Example:
    nvme connect-all --transport=fc --traddr=pn-0x200100110d9f4100:nn-0x200100110d9f4100 \
    --host_traddr=nn-0x20000024ff5ba062:pn-0x21000024ff5ba062

    nvme connect --transport=fc --nqn=nqn.2014-08.org.nvmexpress:nvm-subsystem \
    --traddr=pn-0x200100110d9f4100:nn-0x200100110d9f4100 --host_traddr=nn-0x20000024ff5ba062:pn-0x21000024ff5ba062

Thanks,
Duane

Feature Request: NVMe drive locate function

The ledctl/ledmon package doesn't seem to have support for NVMe drives yet. Any chance nvme-cli will be getting that since that project doesn't seem to be moving very quickly?

(I gave the patch here by @keithbusch a try, but it didn't seem to work on my system. (Could be because I have a PLX PCIe switch in between the motherboard and drives?)

Build errors on i686

We're not using 32-bit right now, but here is the output from a build attempt:

cc -I -m64 -std=gnu99 -O2 -g -pthread -D_GNU_SOURCE -D_REENTRANT -Wall -Werror -DLIBUDEV_EXISTS nvme.c -lm -ludev -o nvme argconfig.o suffix.o
cc1: warnings being treated as errors
nvme.c: In function 'nvme_attach_ns':
nvme.c:1535: error: cast from pointer to integer of different size
nvme.c: In function 'nvme_feature':
nvme.c:2114: error: cast from pointer to integer of different size
nvme.c: In function 'fw_download':
nvme.c:2317: error: cast from pointer to integer of different size
nvme.c: In function 'sec_send':
nvme.c:2707: error: cast from pointer to integer of different size
nvme.c: In function 'resv_acquire':
nvme.c:2849: error: cast from pointer to integer of different size
nvme.c: In function 'resv_register':
nvme.c:2943: error: cast from pointer to integer of different size
nvme.c: In function 'resv_release':
nvme.c:3038: error: cast from pointer to integer of different size
nvme.c: In function 'resv_report':
nvme.c:3120: error: cast from pointer to integer of different size
nvme.c: In function 'submit_io':
nvme.c:3270: error: cast from pointer to integer of different size
nvme.c:3272: error: cast from pointer to integer of different size
nvme.c:3279: error: cast to pointer from integer of different size
nvme.c:3280: error: cast to pointer from integer of different size
nvme.c:3281: error: cast to pointer from integer of different size
nvme.c: In function 'sec_recv':
nvme.c:3401: error: cast from pointer to integer of different size
nvme.c: In function 'nvme_passthru':
nvme.c:3569: error: cast from pointer to integer of different size
nvme.c:3571: error: cast from pointer to integer of different size
nvme.c:3581: error: cast to pointer from integer of different size
nvme.c:3596: error: cast to pointer from integer of different size
nvme.c:3597: error: cast to pointer from integer of different size
nvme.c:3614: error: cast to pointer from integer of different size
nvme.c:3616: error: cast to pointer from integer of different size

Makefile CFLAGS and LDFLAGS handling is problematic

For Fedora packages, the rules say that we have to set Fedora's preferred CFLAGS and LDFLAGS. This breaks the Makefile: udev detection blows up.

An easy fix would be to do:

    override LDFLAGS += -ludev
    override CFLAGS  += -DLIBUDEV_EXISTS
    override LIB_DEPENDS += udev

The "override" makes "make CFLAGS=whatever" not skip these assignments.

A nicer approach might be to use a different variable for the udev stuff or to support EXTRA_CFLAGS and EXTRA_LDFLAGS as alternatives to CFLAGS and LDFLAGS.

(It might also be nice to drop build-time udev detection entirely and just require udev.)

nvme list improvements

Hi

Right now (as of 0x5dd4059...) the nvme list output is crude. Here is an example from one of my test machines:

/dev/nvme0n1 : NVM Express - 0x144d - SAMSUNG MZWEI800HAGM-00003 IPM0AB3Q8% - 0
/dev/nvme0n1p1 : NVM Express - 0x144d - SAMSUNG MZWEI800HAGM-00003 IPM0AB3Q8% - 0
/dev/nvme1n1 : NVM Express - 0x11f8 - MTR_SLC_8GB - 0
/dev/nvme2n1 : NVM Express - 0x111d - 89KTF1604G3MS1TL - 0

I propose we clean up the output. Add correct version handling and add a capacity/usage field. Other suggests welcome.

Stephen

nvme fails when local nvme.h mismatches actual kernel version

Hi

Right now the CLI compiles against a local copy of the uapi nvme.h file. This copy, of course, may differ, from the one the kernel (and nvme module if applicable) were compiled against. This can lead to all sorts of fun and games when we pass a structure we populated with the local header into the kernel IOCTL.

We need to find a better way of handling this. Usually the actually header the kernel was compiled with will be located at /lib/modules/$(uname -r)/build/include/uapi so maybe our Makefile should test for the existence of this file and use it when available and use the local file as a last resort. Or maybe we use a call to uname -r to bork if needed in the make process if we suspect the local header and kernel differ too much?

Stephen

NVME List Output JSON Segmentation Fault

environment

  1. nvme-cli version 1.0
  2. ubuntu 14.04.5 kernel 4.1.10

steps to reproduce

  1. make && make install
  2. nvme list --output-format=json
  3. returns "Segmentation fault"

dmesg
[ 2947.885599] nvme[26026]: segfault at 0 ip 00007f74d1274ebc sp 00007ffd8ffd6820 error 4 in libc-2.19.so[7f74d1206000+1ba000]
[ 2974.819305] nvme[27464]: segfault at 0 ip 00007f31ac4b9ebc sp 00007ffd5c36a410 error 4 in libc-2.19.so[7f31ac44b000+1ba000]
[ 3054.771953] nvme[29480]: segfault at 0 ip 00007f1df528debc sp 00007fff24d03850 error 4 in libc-2.19.so[7f1df521f000+1ba000]

Note other commands formatted w/ json output work w/o issue (only nvme list has the fault)

  1. nvme id-ctrl /dev/nvme0 --output-format=json
  2. nvme fw-log /dev/nvme0n1 -o json

Send IO transaction for 2 sectors.

Hi, I have been able to do IO transaction for single sector i.e., 512B, but when I try to for 1024Bytes with Protection Information enabled, it does not seem to work and I couldn't find much information in the document. can you please send me the exact command to send data of 1024Bytes with End to End protection enabled ?, thanks.

-Ram.

Little-Big Endian

I know it's crazy, but I hear some people don't use x86. I don't want those folks to feel dejected, so I'll post the issue so they know the little people are looking out for the big people (pun intended).

add controller and subsystem reset

Just adding this to the issues tracker so I don't forget it. There is a driver dependency on being able to do these as the IOCTLs and sysfs entries are fairly recent additions.

Test script for the end to end data protection feature of NVMe

Hi all maintainers and contributors,

My name is Yongseok Oh, working on developing firmware S/W for NVMe SSDs at SK telelecom in South Korea. I believe the end to end data protection feature is very important in enterprise class storage systems. However, it is hard to find a test methodology and script for this issue. As a result, I decided to develop a test script using the NVMe CLI tool. This is very helpful and useful to evaluate and test this feature when developing NVMe SSDs.

Please, review and have it included in your project.
(https://github.com/DrYSOH/nvme-cli)

Yongseok Oh

Cut and paste error disables passthru command

The the file nvme.c in the function static int nvme_passthru(int argc, char **argv, int ioctl_cmd) at line 2248 there is a typo assigning the cdw13 value to multiple fields. This makes many vendor specific commands unusable.

cmd.cdw2         = cfg.cdw13;
cmd.cdw3         = cfg.cdw13;
cmd.cdw10        = cfg.cdw13;
cmd.cdw11        = cfg.cdw13;
cmd.cdw12        = cfg.cdw13;
cmd.cdw13        = cfg.cdw13;
cmd.cdw14        = cfg.cdw14;
cmd.cdw15        = cfg.cdw15;
cmd.opcode       = cfg.opcode;
cmd.flags        = cfg.flags;
cmd.rsvd1        = cfg.rsvd;
cmd.nsid         = cfg.namespace_id;

Merge lsnvme into nvme-cli

I think these packages would complement each other: lsnvme provides a user friendly display of the attached disks/controllers with libudev/hwdb, nvme covers the ioctl interfaces.

lsnvme can share "nvme-print.*" and the autotools build system.

nvme0 failed to map

root@kirby /h/sonny# nvme list
nvme0 failed to map

Linux 4.5.0
nvme-cli 0.6
Samsung SM951-NVMe 256GB

getopt_long_only needs 'int' for integer value.

It seems CFG_NONE and no_argument type argument may corrupt other parameters by get_opt_long().
nvme.c uses '__u8' for CFG_NONE&no_argument type, however getopt_long_only() in argconfig_parse() assume it as 'int'.
__u8 argument may be overwritten with 32bit value, and corrupts other parameter value.
These __u8 member should be modified with __u32. Checked on Ubuntu 15.04 x86_64.

For example, "--raw-binary" and "--read" are CFG_NONE&no_argument type arguments.
$ nvme io-passthru /dev/nvme0 --opcode=2 --namespace-id=1 --data-len=4096 --cdw10=0 --cdw11=0 --raw-binary --read
Pass: OK
$ nvme io-passthru /dev/nvme0 --opcode=2 --namespace-id=1 --data-len=4096 --cdw10=0 --cdw11=0 --read --raw-binary
Fail: "data direction not given" error

Could you please check changes in e14b613926e91e0105c97b8734f23bbc7169c1c3 ?

NVME Admin command error: INVALID_OPCODE(2001)

I purchased Parted Magic to erase the drive in a new X1 Carbon 20FB-004QUS, however, although I can run Erase Disk - NVMe Secure Erase option and see the drive (Samsung MZVKV512HAJH-000L1), the erase process ends with "/dev/nvme0n1: Error! Disk is not erased". I then attempted a command line "nvme format /dev/nvme0n1 --ses=1", as well as "nvme format /dev/nvme0n1" (which a Parted Magic support forum admin confirmed is the command they use), but in both cases I get "Admin command error:INVALID_OPCODE(2001)" as the result. The Parted Magic forum admin requested that I contact you directly for assistance. Any feedback on how to correctly secure erase this drive is appreciated.

Thank you.

Add nvme cmb command

Guys

As CMBs become more popular we want a nvme cmb command to give a more verbose indication of the CMB functionality of a drive. Also, eventually we may have the ability to alter things about the CMB and this function will be a placeholder for doing that through the nvme-cli tool.

I'll work on a PR that (initially) just displays the CMBLOC and CMBSZ values in human consumable form. This is an improvement on nvme show-regs. Comments?

Stephen

Provide a trap for the CONFIG_IO_STRICT_DEVMEM issue

Hi

In linux kernel upstream commit 90a545e98 a new CONFIG was added to the kernel that prevents userspace programs (even root) from accesses MMIO regions that are already claimed by a driver. This breaks certain things in NVMe and was found and discussed in another issue.

The issue tracks an effort to document the issue and provide a better user experience when it happens. I plan to try and add a trap for this and a section to the README.md to educate users.

In time we might fix all the broken commands and then this issue becomes moot.

Cheers

Stephen

Latest nvme-cli does not compile (undefined reference to udev...)

Latest nvme-cli fails with make errors (Ubuntu 14.04 Kernel 3.19)

make output
NVME_VERSION = 0.8.35.g8aa3
cc -D_GNU_SOURCE -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.8.35.g8aa3"' -c argconfig.c
cc -D_GNU_SOURCE -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.8.35.g8aa3"' -c suffix.c
cc -D_GNU_SOURCE -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.8.35.g8aa3"' -c parser.c
cc -D_GNU_SOURCE -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.8.35.g8aa3"' -c nvme-print.c
cc -D_GNU_SOURCE -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.8.35.g8aa3"' -c nvme-ioctl.c
cc -D_GNU_SOURCE -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.8.35.g8aa3"' -c nvme-lightnvm.c
cc -D_GNU_SOURCE -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.8.35.g8aa3"' -c fabrics.c
cc -D_GNU_SOURCE -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.8.35.g8aa3"' -c json.c
cc -D_GNU_SOURCE -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.8.35.g8aa3"' -c plugin.c
cc -D_GNU_SOURCE -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.8.35.g8aa3"' -c intel-nvme.c
cc -D_GNU_SOURCE -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.8.35.g8aa3"' -c lnvm-nvme.c
cc -D_GNU_SOURCE -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.8.35.g8aa3"' -c memblaze-nvme.c
cc -D_GNU_SOURCE -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.8.35.g8aa3"' nvme.c -ludev -o nvme argconfig.o suffix.o parser.o nvme-print.o nvme-ioctl.o nvme-lightnvm.o fabrics.o json.o plugin.o intel-nvme.o lnvm-nvme.o memblaze-nvme.o
fabrics.o: In function disconnect_by_nqn': /tmp/nvme-cli/fabrics.c:779: undefined reference toudev_new'
/tmp/nvme-cli/fabrics.c:786: undefined reference to udev_enumerate_new' /tmp/nvme-cli/fabrics.c:792: undefined reference toudev_enumerate_add_match_subsystem'
/tmp/nvme-cli/fabrics.c:793: undefined reference to udev_enumerate_scan_devices' fabrics.o: In functiondisconnect_subsys':
/tmp/nvme-cli/fabrics.c:742: undefined reference to udev_enumerate_get_list_entry' /tmp/nvme-cli/fabrics.c:745: undefined reference toudev_list_entry_get_name'
/tmp/nvme-cli/fabrics.c:745: undefined reference to udev_enumerate_get_udev' /tmp/nvme-cli/fabrics.c:745: undefined reference toudev_device_new_from_syspath'
/tmp/nvme-cli/fabrics.c:748: undefined reference to udev_device_get_sysattr_value' /tmp/nvme-cli/fabrics.c:761: undefined reference toudev_device_unref'
/tmp/nvme-cli/fabrics.c:742: undefined reference to udev_list_entry_get_next' fabrics.o: In functiondisconnect_by_nqn':
/tmp/nvme-cli/fabrics.c:795: undefined reference to udev_enumerate_unref' /tmp/nvme-cli/fabrics.c:798: undefined reference toudev_unref'
/tmp/nvme-cli/fabrics.c:798: undefined reference to udev_unref' /tmp/nvme-cli/fabrics.c:750: undefined reference toudev_device_get_syspath'
/tmp/nvme-cli/fabrics.c:756: undefined reference to udev_device_unref' /tmp/nvme-cli/fabrics.c:795: undefined reference toudev_enumerate_unref'
/tmp/nvme-cli/fabrics.c:798: undefined reference to udev_unref' /tmp/nvme-cli/fabrics.c:753: undefined reference toudev_device_unref'
collect2: error: ld returned 1 exit status
make: *** [nvme] Error 1

display Idle (Active) Power on Power State Descriptor Data Structure

Hi, All

Maybe, there was a mistake to display Idle Power and Active Power.
In the NVMe Spec 1.2, Idle Power Scale is displayed with bit 151:150.
But in the source code, idle power scale argument is parsed with bitwise & 0x0.
I think idle power scale value is extracted with 0xC0.

Feature Request: Decoding of Error Log Entry Hex Codes

Not sure if this is in the planned list already, but decoding of the hex codes (at least the non-vendor-specific ones) would be very helpful. As is, for those not familiar with the spec (myself included), decoding them manually is very difficult.

(When testing NVMe drives in an assembled system, it is desirable to understand why the error counter is incrementing, not just that it is.)

Compilation errors on 32-bit architecture

When running make on 32-bit ARM, the following compile errors are caused by casts from void* to __u64. This did not happen in v0.3, but does from v0.4 onwards, I assume due to the removal of the unsigned long casts that used to be present.

NVME_VERSION = 0.4.31.ge999
cc -I ./src -D_GNU_SOURCE -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.4.31.ge999"' -c ./src/argconfig.c
cc -I ./src -D_GNU_SOURCE -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.4.31.ge999"' -c ./src/suffix.c
cc -I ./src -D_GNU_SOURCE -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.4.31.ge999"' -c nvme-print.c
cc -I ./src -D_GNU_SOURCE -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.4.31.ge999"' -c nvme-ioctl.c
nvme-ioctl.c: In functionnvme_passthru’:
nvme-ioctl.c:68:15: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   .metadata = (__u64) metadata,
               ^
nvme-ioctl.c:69:12: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   .addr  = (__u64) data,
            ^
nvme-ioctl.c: In functionnvme_io’:
nvme-ioctl.c:99:15: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   .metadata = (__u64) metadata,
               ^
nvme-ioctl.c:100:12: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   .addr  = (__u64) data,
            ^
nvme-ioctl.c: In functionnvme_dsm’:
nvme-ioctl.c:191:12: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   .addr  = (__u64) dsm,
            ^
nvme-ioctl.c: In functionnvme_resv_acquire’:
nvme-ioctl.c:225:12: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   .addr  = (__u64) (payload),
            ^


nvme-ioctl.c: In functionnvme_resv_register’:
nvme-ioctl.c:242:12: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   .addr  = (__u64) (payload),
            ^
nvme-ioctl.c: In functionnvme_resv_release’:
nvme-ioctl.c:259:12: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   .addr  = (__u64) (payload),
            ^
nvme-ioctl.c: In functionnvme_resv_report’:
nvme-ioctl.c:271:12: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   .addr  = (__u64) data,
            ^
nvme-ioctl.c: In functionnvme_identify’:
nvme-ioctl.c:295:12: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   .addr  = (__u64) data,
            ^
nvme-ioctl.c: In functionnvme_get_log’:
nvme-ioctl.c:328:12: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   .addr  = (__u64) data,
            ^
nvme-ioctl.c: In functionnvme_feature’:
nvme-ioctl.c:373:12: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   .addr  = (__u64) data,
            ^
nvme-ioctl.c: In functionnvme_ns_create’:
nvme-ioctl.c:428:12: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   .addr  = (__u64) ((void *)&ns),
            ^
nvme-ioctl.c: In functionnvme_ns_attachment’:
nvme-ioctl.c:460:12: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   .addr  = (__u64) cntlist,
            ^
nvme-ioctl.c: In functionnvme_fw_download’:
nvme-ioctl.c:487:12: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   .addr  = (__u64) data,
            ^
nvme-ioctl.c: In functionnvme_sec_send’:
nvme-ioctl.c:511:12: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   .addr  = (__u64) data,
            ^
nvme-ioctl.c: In functionnvme_sec_recv’:
nvme-ioctl.c:532:12: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
   .addr  = (__u64) data,
            ^
cc1: all warnings being treated as errors
Makefile:37: recipe for target 'nvme-ioctl.o' failed
make: *** [nvme-ioctl.o] Error 1

no visible documentation of format of /etc/nvme/discovery.conf

There does not appear to be any documentation of the format of file /etc/nvme/discovery.conf, which a new user is apparently required to create.

Details: I installed nvme-cli v0.9 from a ZIP file on a CentOS 7.2 initiator/host machine. I ran "nvme discover" and got back "No discover params given and no /etc/nvme/discovery.conf conf". Doing "fgrep -r discovery.conf nvme-cli-0.9" yielded one '#define' line in fabrics.c and notice that binary files fabrics.o and nvme match. It would be helpful for a new user to have some documentation about the file format. Reverse engineering the file format from the source code is rather inefficient.

(I'm a new would-be user of the tool. If somebody could drop me a quick message with a hint or two about the file format, it would be appreciated.)

Release package is being generated without version file

The packages being release, as 0.3, 0.4 do NOT contain the version file, and it is not also part of a git archive, which means that the version shows up as 0.1

This is one of the problem we have at Ubuntu and Debian at the moment.

I suggest that we generate a version file and update it before each release commit, and make the git tag on top of this commit.

log entries default value for nvme-error-log command

nvme error-log command has a default of 64 entries (--log-entries). This default value is causing errors on some devices that do not support 64 entries.

I would like the default value for log entries set to the maximum supported by the device. This is reported in "Error Log Page Entries (ELPE)" field in the ID controller data structure.

Smart-log output units/descriptions

Hi,

I am using the nvme-cli utility to read the smart-log off an NVME device. I was searching for descriptions of some of the parameters being reported. Here is my nvme smart-log output (below).

For example, I wanted to understand what data_units corresponds to (probably multiple kB from how much I wrote, but not sure what it is).

The context is that I am trying to write a monitoring script for NVMe cards that will invoke the smart-log command and report it for SSD wear/thresholds etc.

Apologies if this is not the right forum.

Thank you

-Sachin

user@node09:~$ sudo nvme smart-log /dev/nvme1n1
Smart Log for NVME device:/dev/nvme1n1 namespace-id:ffffffff
critical_warning : 0
temperature : 34 C
available_spare : 100%
available_spare_threshold : 10%
percentage_used : 0%
data_units_read : 203,913,228
data_units_written : 64,663,716
host_read_commands : 7,207,810,975
host_write_commands : 2,931,291,530
controller_busy_time : 399
power_cycles : 9
power_on_hours : 742
unsafe_shutdowns : 5
media_errors : 0
num_err_log_entries : 0
Critical Composite Temperature Time : 0
Temperature Sensor 1 : 0 C
Temperature Sensor 2 : 0 C
Temperature Sensor 3 : 0 C
Temperature Sensor 4 : 0 C
Temperature Sensor 5 : 0 C
Temperature Sensor 6 : 0 C
Temperature Sensor 7 : 0 C
Temperature Sensor 8 : 0 C

nvme fw-log not working in version 0.8 - INVALID_FIELD(4002)

Using version 0.7 I can issue nvme fw-log command. but version 0.8 fails for same command.

[root@tom400 nvme-cli-0.7]# nvme fw-log /dev/nvme4
Firmware Log for device:nvme4
afi : 0x44
frs1 : 0x4b4d495050313037 (KMIPP107)
frs2 : 0x4b4d495050313037 (KMIPP107)
frs3 : 0x4b4d495050313037 (KMIPP107)
frs4 : 0x4b51495050313131 (KQIPP111)

[root@tom400 nvme-cli-master.8]# nvme fw-log /dev/nvme4
NVMe Status:INVALID_FIELD(4002)
[root@tom400 nvme-cli-master.8]#

System is IBM Power 8
Linux tom400 3.10.0-327.22.2.el7.ppc64 #1 SMP Thu Jun 9 10:31:21 EDT 2016 ppc64 ppc64 ppc64 GNU/Linux
[root@tom400 nvme-cli-master.8]# cat /etc/*release
NAME="Red Hat Enterprise Linux Server"
VERSION="7.2 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="7.2"
PRETTY_NAME="Red Hat Enterprise Linux"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.2:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.2
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.2"
Red Hat Enterprise Linux Server release 7.2 (Maipo)
Red Hat Enterprise Linux Server release 7.2 (Maipo)

add autoconf/autotools ?

We all loathe autotools for good reasons, but it is does provide some nice features that nvme-cli will want or already implements itself:

  1. easy cross compilation
  2. configurable locations for everything (prefix, destdir, sysconfdir)
  3. detection of libraries (libudev), headers (nvme.h or nvme-ioctl.h), and struct members
  4. handles version substitution in source files

Out of all these I think number three can provide us some real benefits: we can generate defines for certain fields in struct nvme_id_ctrl, and what ioctls are available (eg use for #57).

Is this something people are interested in? I can issue a PR if so.

src/argconfig.c: 3 * poor error checking ?

src/argconfig.c:243]: (style) Checking if unsigned variable 'tmp' is less than zero.

Source code is

        uint8_t tmp = strtol(optarg, &endptr, 0);
        if (errno || tmp < 0 || optarg == endptr) {

Was strtoul intended ?

src/argconfig.c:252]: (style) Checking if unsigned variable 'tmp' is less than zero.
src/argconfig.c:261]: (style) Checking if unsigned variable 'tmp' is less than zero.

Duplicates.

mismatch argconfig_type in submit_io()

regress issues read/write command with --data_size=4k,
however argconfig_type in submit_io()'s data_size is "CFG_POSITIVE".
I guess either

  • replace CFG_POSITIVE as CFG_LONG_SUFFIX in nvme.c line 2608
    or
  • replace RAND_SIZE=4k as RAND_SIZE=4096 in regress line 29
    may be applied.

c8aab96

Only keep one set of documentation in the git repo

There are currently three copies of each command documentation under Documentation: man page, html, and text.

The packages only need the man pages, do we need to keep the other formats in the tree? Can we just generate those as needed? What are the consumers of the .txt and html formats?

nvme cli commands inconsistent after subsystem reset

Is this behaviour expected ?

# nvme list
Node             SN                   Model                                    Namespace Usage                      Format           FW Rev  
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1     STM0001A8A15         PCIe3 1.6TB NVMe Adapter                 1           1.60  TB /   1.60  TB      4 KiB +  0 B   KMIPP107

# nvme subsystem-reset /dev/nvme0; echo $?
0

# time nvme list; echo $?
Node             SN                   Model                                    Namespace Usage                      Format           FW Rev  
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1                          �@                                       1           1.60  TB /   1.60  TB      4 KiB +  0 B   p;��

real    1m2.110s
user    0m0.001s
sys 0m0.003s
0

# time nvme list; echo $?
Node             SN                   Model                                    Namespace Usage                      Format           FW Rev  
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1     STM0001A8A15         PCIe3 1.6TB NVMe Adapter                 1           1.60  TB /   1.60  TB      4 KiB +  0 B   KMIPP107

real    0m0.003s
user    0m0.000s
sys 0m0.002s
0

debian changelog should be auto-magically generated

Hi

Commit 15878d3 added a debian/changelog file. This breaks the Ubuntu PPA make flow since we auto-magically generate that file. I would rather not have this file in the repo. If you want you can have a changelog.debian file in the repo and copy it over when you build your package but a better option is to add echo commands to the Makefile like we did for deb-ppa.

Discuss ;-)

Stephen

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.