NVME-SNDK-VS-INTE(1)

πŸ’… NVME-SNDK-VS-INTE(1) β€” the sndk internal firmware log page, explained by your favorite unix bestie

okay so real quick β€” this is a page from the NVMe Manual, and it's literally about scraping the internal firmware log off a SanDisk drive and yeeting it into a file. let's get into it πŸŽ€


✨ NAME ✨

nvme-sndk-vs-internal-log β€” grab your sndk device's internal firmware log and save it to a file. that's the whole vibe. πŸ¦‹


🌸 SYNOPSIS 🌸

nvme [<global-options>] sndk vs-internal-log <device>
                        [--output-file=<FILE>, -O <FILE>]
                        [--transfer-size=<SIZE>, -s <SIZE>]
                        [--data-area=<DATA AREA>, -d <DATA AREA>]
                        [--file-size=<FILE SIZE>, -f <FILE SIZE>]
                        [--offset=<OFFSET>, -e <OFFSET>]
                        [--type=<TYPE>, -t <type>]

πŸ’– DESCRIPTION πŸ’–

so for the NVMe device you hand it, this thing sends the sndk Vendor Specific Internal Log request and saves whatever comes back into a file. no cap, that's it.

the <device> parameter is mandatory and it has to be an NVMe character device (like, ex: /dev/nvme0). don't skip it, bestie. πŸ™ˆ

⚠️ this will only work on Sandisk devices that actually support this feature. results for any other device are undefined β€” so like, don't come crying to me if you point it at a random drive, okay? πŸ’€

🫢 OPTIONS 🫢

  • -O <FILE>, --output-file=<FILE> β€” the output file ✨ defaults to the device serial number followed by an "internal_fw_log<date>_<time>.bin" suffix.
  • -s <SIZE>, --transfer-size=<SIZE> β€” the transfer size πŸŽ€ defaults to 0x10000 (65536 decimal) bytes.
  • -d <DATA AREA>, --data-area=<DATA AREA> β€” which data area to retrieve. okay this one's got two modes, pay attention πŸ‘‘:
    • if you're capturing with a --type value that includes telemetry (CONTROLLER, HOST, or BOTH), this specifies the NVMe telemetry data area to capture, containing data from areas 1 to <DATA AREA>.
    • if you're capturing without such a --type value, this specifies the amount of vendor defined debug data to capture β€” and that's only supported on the SN340, SN350, SN530, SN570, SN730, SN740, SN840, SN850X, SN5000, SN5100S, SN7000S, SN7100, and SN7150 devices. iykyk πŸ’…
  • -t <TYPE>, --type=<TYPE> β€” specifies the telemetry type: NONE, HOST, CONTROLLER, or BOTH. this parameter is used to get either the host-initiated or controller-initiated telemetry log page. if BOTH is specified, both host and controller telemetry are captured and packaged into a tar archive 🌈. if you don't specify it, or if <TYPE> is NONE, the command returns vendor defined debug data instead.
  • -f <FILE SIZE>, --file-size=<FILE SIZE> β€” ⚠️ deprecated. specifies the desired size of the data file starting at the passed in offset. this lets you retrieve the data in several smaller files of the passed in size. this parameter is only supported on the devices mentioned in the documentation of the --data-area parameter, and only for capture with --type=NONE or --type not specified.
  • -e <OFFSET>, --offset=<OFFSET> β€” ⚠️ deprecated too, bestie. specifies the data offset at which to start retrieving the data. it's used in combination with the file size parameter to retrieve the data in several smaller files. same deal as above: only supported on the devices mentioned in the documentation of the --data-area parameter, and only for capture with --type=NONE or --type not specified.

πŸ‘‘ GLOBAL OPTIONS πŸ‘‘

these are defined up at the top-level nvme command and they're available to this subcommand, so like, they're the main character options πŸŽ€

  • --dry-run β€” print the command that would be executed, but do not actually execute it. vibes only, no consequences ✨
  • --no-ioctl-probing β€” disable probing for 64-bit IOCTL support.
  • --no-retries β€” disable retry logic on transient errors.
  • -o <fmt>, --output-format=<fmt> β€” set the reporting format to normal, tabular, 'json, or binary. only one output format may be used at a time. (yes, that stray quote is in the original, i'm not fixing it, it's iconic πŸ’…)
  • --output-format-version=<version> β€” select the output format version. version 1 uses the original field naming, while version 2 (default) provides more consistent and script-friendly field names. other versions are rejected 🚫
  • --quiet β€” suppress informational messages. errors are still reported, and --quiet cancels any --verbose for the library log level.
  • --set-options=<key=value>[,<key=value>...] β€” set libnvme library options for this invocation. supported keys are force-4k, mi-probe-enabled, test-base-dir and test-sysfs-dir.
  • --timeout=<ms> β€” set the timeout for the command in milliseconds. infinite or -1 waits without a time limit (0xffffffff). the way that's just an infinite hold 😭
  • -v, --verbose β€” increase the level of detail in the output. may be specified multiple times to further increase verbosity. stack 'em up πŸ”₯

and these options can also be set as machine-wide defaults in nvme-cli.conf(5). a command-line flag always overrides the file β€” CLI stays winning πŸ‘‘


πŸ’œ EXAMPLES πŸ’œ

  • gets the internal firmware log from the device and saves to the default file in the current directory (e.g. STM00019F3F9_internal_fw_log_20171127_095704.bin):
# nvme sndk vs-internal-log /dev/nvme0
  • gets the internal firmware log from the device and saves to a defined file in the current directory (e.g. test.bin):
# nvme sndk vs-internal-log /dev/nvme0 -O test.bin
  • gets the internal firmware log from the device and saves to a defined file with a pathname (e.g. /tmp/test):
# nvme sndk vs-internal-log /dev/nvme0 -O /tmp/test
  • gets the internal firmware log from the device, transferring the data in 64k chunks, and saves to the default file in the current directory (e.g. STM00019F3F9_internal_fw_log_20171127_100754.bin):
# nvme sndk vs-internal-log /dev/nvme0 -s 0x10000
  • gets the internal firmware log from the device, transferring the data in 16k chunks, and saves to the default file in the current directory (e.g. STM00019F3F9_internal_fw_log_20171127_100950.bin):
# nvme sndk vs-internal-log /dev/nvme0 -s 16384
  • gets the internal firmware log up to data area 3 from the device, in 3 files of 0x1000000 bytes:
# nvme sndk vs-internal-log /dev/nvme0 -d 3 -f 0x1000000 -t 0x0000000 -O /tmp/sn340_dui_data_1.bin
# nvme sndk vs-internal-log /dev/nvme0 -d 3 -f 0x1000000 -t 0x1000000 -O /tmp/sn340_dui_data_2.bin
# nvme sndk vs-internal-log /dev/nvme0 -d 3 -f 0x1000000 -t 0x2000000 -O /tmp/sn340_dui_data_3.bin
  • gets the host telemetry log page to data area 3 from the device and stores it in file host-telem-log-da3.bin:
# nvme sndk vs-internal-log /dev/nvme1 -t host -O host-telem-log-da3.bin -d 3
  • gets the controller telemetry log page to data area 3 from the device and stores it in file ctlr-telem-log-da3.bin:
# nvme sndk vs-internal-log /dev/nvme1 -t controller -O ctlr-telem-log-da3.bin -d 3
  • gets both host and controller telemetry log pages to data area 3 from the device and packages them in a tar file:
# nvme sndk vs-internal-log /dev/nvme1 -t both -O both-telem-log-da3.tar -d 3

🌟 NVME 🌟

part of the nvme-user suite 🫢


and that's the whole page, bestie! this one's from the NVMe crew, dated 10/30/2026, filed under NVME-SNDK-VS-INTE(1) β€” go get that firmware log, you absolute icon πŸ’…βœ¨πŸ‘‘

πŸ“¦ where this page comes from