Cache, NVS and NVDIMM: keeping writes safe

You’ll read the cache and NVS sizes of the lab DS8A50, check them against the 1/16 rule and look at the cache counters of a busy volume, and then model a write burst you couldn’t safely create in a shell.

Practice shell note: the practice shell is our teaching tool, not IBM software, and real DS CLI output is similar but not identical. The counters showfbvol -metrics prints in the shell come from a simple formula after simctl io, whereas on a real DS8000 they count real host I/O. Lines starting with SIM are practice shell messages.

1Reset and create two volumes

The setup is the same as in Lesson 4. Start the shell, run simctl reset and then quit, save the lines below as setup-05.txt and run it.

setup-05.txt:

mkarray -raidtype 6 -arsite S1
mkarray -raidtype 6 -arsite S2
mkrank -array A0 -stgtype fb -extsize 16MiB -keygrp 1
mkrank -array A1 -stgtype fb -extsize 16MiB -keygrp 1
mkextpool -rankgrp 0 -stgtype fb -keygrp 1 pool_even
mkextpool -rankgrp 1 -stgtype fb -keygrp 1 pool_odd
chrank -extpool P0 R0
chrank -extpool P1 R1
mkfbvol -extpool P0 -cap 100 -sam ese -name db_even 2000
mkfbvol -extpool P1 -cap 100 -sam ese -name db_odd 2100

Run this (PowerShell):

python ds8sim.py -hmc1 10.0.0.1 -user admin -passwd YOURPASSWORD -script setup-05.txt

You should see the last two lines:

CMUC00025I mkfbvol: FB volume 2000 successfully created.
CMUC00025I mkfbvol: FB volume 2100 successfully created.

✅ Checkpoint: Volumes 2000 and 2100 exist.

2Read the cache and NVS sizes

Start the shell again and run:

Run this:

showsi IBM.2107-78SV001

You should see this (output shortened):

Date/Time: 24 October 2026 11:04:23 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
Name             ds8k-g10-lab
ID               IBM.2107-78SV001
Model            A05
...
NVS Memory       64.0 GB
Cache Memory     832.0 GB
Processor Memory 1015.6 GB
MTS              IBM.5341-78SV000
...

Check the rule: Lesson 4 showed 2 × 512 GB = 1,024 GB of system memory, and 1,024 ÷ 16 = 64 GB, which matches NVS Memory. The cache figure is what’s left for cache after the system takes its own share, and each CPC holds half the NVS, 32 GB.

✅ Checkpoint: You confirmed 64 GB NVS = 1/16 of 1,024 GB, so 32 GB per CPC.

3Make a volume busy and read its cache counters

Run this:

showfbvol -metrics 2000
simctl io 2000 3
showfbvol -metrics 2000

You should see this (counters shortened):

dscli> showfbvol -metrics 2000
Date/Time: 24 October 2026 11:04:23 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
ID            2000
Date          10/24/2026 11:04:23
normrdrqts    0
normrdhits    0
normwritereq  0
normwritehits 0
...
dscli> simctl io 2000 3
SIM0101I simctl: host I/O recorded on volume 2000 (in use for the next 5 minutes).
dscli> showfbvol -metrics 2000
Date/Time: 24 October 2026 11:04:23 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
ID            2000
Date          10/24/2026 11:04:23
normrdrqts    21037
normrdhits    15187
normwritereq  75713
normwritehits 75198
...
NVSspadel     0
...

normrdrqts counts normal (random) read requests and normrdhits counts how many were served from cache, so the read hit ratio is 15,187 ÷ 21,037 ≈ 72%. For writes it’s 75,198 ÷ 75,713 ≈ 99%, nearly every write a cache hit, because writes always land in cache first.

On a real DS8000 these counters keep adding up from the last reset, so you compare two readings taken a few minutes apart. The Redbook’s DS CLI chapter has a full real example, and the DS CLI help on a real system describes each counter.

✅ Checkpoint: You calculated a read hit ratio of about 72 % for volume 2000.

Type quit to leave the shell.

4Model a write burst

You can’t create a real write burst on a laptop, so you’ll use a small model. It’s simple on purpose: it assumes the back end destages a fixed number of MB per second, split evenly between the two CPCs, and that each NVS half fills only when writes beat destage. A real DS8000 behaves more cleverly, but the shape is right.

Save this as nvs_burst.py on your laptop, in the lab folder next to ds8sim.py. It’s a planning model that runs there and not on the DS8000, and step 5 uses its --check part, which reads the real NVS size through the DS CLI.

# nvs_burst.py - SaatVedha NVS write-burst model (a simplified teaching model, not an IBM tool)
# A planning tool: it runs on your laptop or jump server, not on the DS8000.
# With --check it reads the NVS size (lssi, showsi) and server state (lsserver) through the DS CLI
# (auto.profile: banner off, header on, format delim) instead of taking the NVS GB from you.
# NVS holds new writes until they are destaged to flash. Each CPC holds half of the system NVS:
# CPC 1 keeps the copies of even-LSS writes, CPC 0 the copies of odd-LSS writes.
# Usage: python nvs_burst.py <NVS GB> <write MB/s> <destage MB/s> <burst seconds> [% writes to even LSS]
#        python nvs_burst.py --check <write MB/s> <destage MB/s> <burst seconds> [% writes to even LSS]
import csv, subprocess, sys
DSCLI = ["python", "ds8sim.py", "-cfg", "auto.profile"]   # at work: ["dscli", "-cfg", "auto.profile"]

def dscli(*args):
    """Run one DS CLI command and return its rows as dictionaries."""
    out = subprocess.run(DSCLI + list(args), capture_output=True, text=True).stdout
    lines = [l for l in out.splitlines() if l and not l.startswith("SaatVedha") and not l.startswith("CMUC")]
    return list(csv.DictReader(lines))

args = sys.argv[1:]
if args and args[0] == "--check":
    if len(args) < 4:
        print("Usage: python nvs_burst.py --check <write MB/s> <destage MB/s> <burst seconds> [% writes to even LSS]")
        sys.exit(1)
    dev = dscli("lssi")[0]["ID"]
    si = dscli("showsi", dev)[0]
    nvs = float(si["NVS Memory"].split()[0])
    down = [s["ID"] for s in dscli("lsserver") if s["SFI State"] != "Online"]
    print(f"From the DS CLI  : NVS Memory {nvs:.0f} GB (showsi), " +
          (f"{', '.join(down)} offline (lsserver)" if down else "both servers Online (lsserver)"))
    if down:
        # Failover: the surviving CPC has only its own half of the NVS, split between even and odd.
        nvs = nvs / 2
        print(f"Failover         : one CPC holds all write copies, so the model uses {nvs:.0f} GB")
    args = [str(nvs)] + args[1:]

if len(args) < 4:
    print("Usage: python nvs_burst.py <NVS GB> <write MB/s> <destage MB/s> <burst seconds> [% writes to even LSS]")
    sys.exit(1)

nvs, write, destage, secs = (float(x) for x in args[0:4])
even = float(args[4]) if len(args) > 4 else 50.0
side_mb = nvs / 2 * 1024

print(f"NVS per CPC side : {nvs / 2:.0f} GB")
for name, share in (("even LSS (copies in CPC 1)", even), ("odd LSS  (copies in CPC 0)", 100 - even)):
    w = write * share / 100
    d = destage / 2
    if w <= d:
        print(f"{name}: {w:.0f} MB/s in, {d:.0f} MB/s out -> keeps up")
        continue
    fill = side_mb / (w - d)
    verdict = "fits" if fill >= secs else "NVS FULL, writes wait"
    print(f"{name}: {w:.0f} MB/s in, {d:.0f} MB/s out -> full after {fill:.0f} s; {secs:.0f} s burst {verdict}")

Start with a calm day: 3,000 MB/s of writes against a back end that destages 4,000 MB/s, for 60 seconds.

Run this (PowerShell):

python nvs_burst.py 64 3000 4000 60

You should see this:

NVS per CPC side : 32 GB
even LSS (copies in CPC 1): 1500 MB/s in, 2000 MB/s out -> keeps up
odd LSS  (copies in CPC 0): 1500 MB/s in, 2000 MB/s out -> keeps up

Destage is faster than the writes, so NVS never fills. Now try a short, heavy burst of 6,000 MB/s for 20 seconds.

Run this:

python nvs_burst.py 64 6000 4000 20

You should see this:

NVS per CPC side : 32 GB
even LSS (copies in CPC 1): 3000 MB/s in, 2000 MB/s out -> full after 33 s; 20 s burst fits
odd LSS  (copies in CPC 0): 3000 MB/s in, 2000 MB/s out -> full after 33 s; 20 s burst fits

Each side now gets 1,000 MB/s more than it can destage, so its 32 GB would fill in about 33 seconds, and a 20-second burst fits. Soaking up short peaks like this is what NVS is for.

✅ Checkpoint: You can explain why a 20-second burst fits but the NVS would fill after 33 seconds.

5Feed the model from the box

Up to now you typed 64 GB yourself, and --check reads it instead: showsi gives NVS Memory and lsserver tells it whether both servers are up. You only give the write rate, the destage rate and the burst length.

A script can’t answer password prompts, so save your password in a password file first. If security.dat is already in your lab folder from an earlier lesson, skip this command (the shell would tell you the record already exists).

Run this (PowerShell):

python ds8sim.py -hmc1 10.0.0.1 -user admin -passwd YOURPASSWORD managepwfile -action add -name admin -pw YOURPASSWORD -pwfile security.dat

You should see this:

CMUC00206I managepwfile: Record 10.0.0.1/admin successfully added to password file security.dat.

Then save these eight lines as auto.profile in the same folder. banner: off, header: on and format: delim make every list come back as one header row plus comma-separated rows, which Python reads easily. Implementation Lesson 2 explains profiles in full.

auto.profile:

hmc1: 10.0.0.1
username: admin
pwfile: security.dat
devid: IBM.2107-78SV001
banner: off
header: on
format: delim
delim: ,

Run this (PowerShell):

python nvs_burst.py --check 6000 4000 20

You should see this:

From the DS CLI  : NVS Memory 64 GB (showsi), both servers Online (lsserver)
NVS per CPC side : 32 GB
even LSS (copies in CPC 1): 3000 MB/s in, 2000 MB/s out -> full after 33 s; 20 s burst fits
odd LSS  (copies in CPC 0): 3000 MB/s in, 2000 MB/s out -> full after 33 s; 20 s burst fits

It’s the same answer as before, except the 64 GB now came from the box. In the break lab you’ll see what the check does when a server is down.

At work you feed it the peak write and destage rates from your performance reports, and you run it again before every big batch change.

✅ Checkpoint: --check read 64 GB of NVS from showsi and the 20-second burst still fits.