Expand, delete and reclaim volumes safely
DS8000 volume expansion is one of the most common tickets a storage admin gets: “the database disk is 90% full, please add 50 GB”. On a DS8000 you can grow a LUN while the host carries on reading and writing, and you can delete volumes and reclaim space you don’t need any more, but used carelessly the same commands can wipe a disk that a live server still depends on.
Here you’ll learn the safe way to handle all three jobs. You’ll grow a volume with chfbvol, see for yourself that it can never shrink, hand thin space back with initfbvol and delete volumes with rmfbvol -safe. Along the way you’ll see the checks the DS8000 runs before it lets you delete anything, and how to get past them when you truly mean it.
You need the practice shell from Lesson 2 and the host mapping ideas from Lesson 14. We ran every command below in the shell, and the output boxes show what it printed.
| Time | You need | By the end you can |
|---|---|---|
| 60 to 75 minutes | The SaatVedha practice shell (Python 3.8 or newer) and the setup script below | Grow FB volumes online, explain why they can’t shrink, release ESE space, and delete volumes without hurting a live host |
What it is, in one line
Expanding adds extents to a live volume, deleting hands its extents back to the pool, and reclaiming frees the space a thin volume no longer needs, and before the risky ones the DS8000 checks “is anyone using this?”
In Simple Words
A school bag, a locker and a lost-and-found shelf
Your school bag is full. Your mother sews on an extra zip pocket, and now it holds more books. You didn’t have to empty the bag first.
That is expanding.
Can she make the bag smaller while it is full of books? No. Something would fall out and get lost.
That is why a volume can grow but never shrink.
At the end of the year you empty your locker so the next child can use it, and before the teacher gives it away she checks the name tag and looks inside; if your books are still there, she waits. The DS8000 makes that same check before it deletes a volume. And when you take old notebooks out of the bag but keep the bag, the shelf space they used goes back to the class, which is what reclaiming means.
Engineer's View
What really happens to the extents
Dynamic Volume Expansion. The DS8A00 grows FB and CKD volumes online by adding extents, with no data loss and without taking the volume offline, and IBM i variable-size volumes (types 050 and 099) can grow as well.
The host operating system has to support a larger disk, which is why chfbvol -cap shows CMUC00332W and asks before it does anything.
If the volume was created with -eam rotateexts (the DS8A00 default), the new extents get striped across the pool’s ranks as well, while a volume made with rotatevols takes its new extents from the same rank if there’s room.
No shrinking. IBM doesn’t support making a volume smaller, because most operating systems can’t move data off the end of a disk and you’d lose it. Neither the DS CLI nor the GUI will do it.
The new size must be larger than the old one.
Limits. The largest LUN is 16 TiB, and Copy Services only work up to 4 TiB per LUN.
Before you expand a volume, you have to remove every Copy Services relationship on it (FlashCopy, Metro Mirror, Global Copy).
CKD. chckdvol -cap grows CKD volumes in cylinders. A 3390-9 that grows past 65,520 cylinders turns into a 3390-A automatically, and you can’t pass -cap and -datatype in the same command.
“In use” rules. An FB volume counts as in use if it’s in a Copy Services relationship or has had I/O in the last 5 minutes. A CKD volume counts as in use if it’s in a Copy Services relationship or the IBM Z path mask shows it grouped or online to a host. With no flag, rmfbvol deletes only volumes that aren’t in use, and -safe also refuses when a volume is still in a user-defined volume group (CMUC00253E). -force skips the in-use check, and you can’t combine -safe with -force.
Safeguarded Copy. You can’t delete a volume that’s in an active Safeguarded Copy relationship (managed by CSM or GDPS), even with -force.
Reclaiming. initfbvol -action releasespace frees every extent of an ESE (thin) volume and loses all the data on it, and it needs -force if the volume is in use. Hosts can also hand space back themselves with SCSI UNMAP, which the DS8000 supports only on ESE volumes in pools with small 16 MiB extents.
For CKD, z/OS releases space with the DFSMSdss SPACERel option.
GUI. Volumes → Volumes by Pool → Actions → Expand or Delete. Before a delete or a reinitialize the GUI makes you type a confirmation code, and it has a force checkbox for volumes that are in use.
How it works, step by step
Every change in this lesson works on extents. As you saw in Lesson 13, a volume is a list of extents taken from an extent pool, and in our lab pools each one is 16 MiB.
Growing a volume adds extents to that list and deleting it hands them all back. Reclaiming a thin volume returns the extents it was using but keeps the volume and its size.
1Expand: the request
The application team asks for more space on a LUN. Check the host first: can its operating system see a bigger disk without a reboot? Linux, Windows, VMware and AIX all can, as long as you follow the right rescan steps.
Then look at the volume on the DS8000. If it’s in FlashCopy or Metro Mirror, those relationships have to go first, and you plan to rebuild them afterwards.
2Expand: the DS8000 adds extents
You run chfbvol -cap 30 2204, and the size you give is always the total you want, not the amount to add.
The DS8000 takes new extents from the pool and adds them to the end of the volume. With rotateexts they’re spread across all the ranks again, which keeps performance even, and the host keeps working throughout.
3Expand: the host side
That’s the DS8000 side finished, but the host still sees the old size. On Linux you rescan the SCSI devices and resize the multipath map, then grow the partition, the LVM physical volume and the file system.
On Windows you rescan in Disk Management and extend the volume, and on VMware you rescan the HBAs and grow the datastore. Plenty of tickets stay open because someone forgot this half.
4Delete: the checks
Before rmfbvol deletes anything, it asks whether the volume is in a Copy Services relationship and whether it had any host I/O in the last 5 minutes. If the answer to either is yes, the volume is “in use” and stays.
With -safe it adds a third question: is the volume still in a volume group, meaning a host can see it? If so, nothing gets deleted at all.
5Delete: the clean order
The safe order is always host first and storage last. The host team stops the application, unmounts the file system and removes the disk from the OS and multipath, and then you unmap the volume from the host on the DS8000. Wait until no I/O has come in for at least 5 minutes, and only then run rmfbvol -safe, which returns its extents to the pool as free space.
After every change, run lsextpool and check that available moved by the amount you expected. It goes down when you grow a standard volume and up when you delete or reclaim.
Hands-on lab: grow, reclaim and delete volumes
Before you run any command, double-check it
Read every command twice before you press Enter. Check the target: the system or account, the IDs, the names and the sizes. These commands are for learning and were tested in our lab, not on your system. At work, run the read-only list commands first, follow your change process, make sure a backup exists, and ask a second person to check anything that changes or deletes data. You run them at your own risk.
In this lab you’re looking after a small Linux host called saat-host1, which has two thin app volumes (2000, 2001) and one standard database volume (2204). You’ll grow two of them, then reclaim one and delete it cleanly.
Practice shell note: the practice shell is our own teaching tool, not IBM software. Real DS CLI output looks very close to this but isn’t identical. Lines starting with SIM, and the IDs CMUN02039E and CMUN02948E, come from the practice shell, and we’ve cut some unchanged showfbvol fields from the boxes (output shortened).
1Start clean and load the setup script
Save the script below as setup-17.txt in your lab folder (C:\ds8k-lab or ~/ds8k-lab). It builds four RAID 6 arrays, three pools, four volumes and the host, and then logs the host’s two ports in.
setup-17.txt:
# setup-17.txt: pools, volumes and one Linux host for Lesson 17
mkarray -raidtype 6 -arsite S1
mkarray -raidtype 6 -arsite S2
mkarray -raidtype 6 -arsite S7
mkarray -raidtype 6 -arsite S8
mkrank -array A0 -keygrp 1 -stgtype fb
mkrank -array A1 -keygrp 1 -stgtype fb
mkrank -array A2 -keygrp 1 -stgtype fb
mkrank -array A3 -keygrp 1 -stgtype fb
mkextpool -rankgrp 0 -keygrp 1 -stgtype fb FB_0
mkextpool -rankgrp 1 -keygrp 1 -stgtype fb FB_1
mkextpool -rankgrp 0 -keygrp 1 -stgtype fb T2_0
chrank -extpool P0 R0
chrank -extpool P1 R1
chrank -extpool P2 R2
chrank -extpool P2 R3
mkfbvol -extpool p0 -cap 10 -sam ese -name app_#h 2000-2001
mkfbvol -extpool p1 -cap 10 -sam ese -name app_#h 2100
mkfbvol -extpool p2 -cap 15 -name db_#h 2204
mkhost -type "Linux Server" -hostport 10000090FA13B914,10000090FA13B915 saat-host1
chhost -action map -volume 2000,2001,2204 saat-host1
simctl login 10000090FA13B914 I0032
simctl login 10000090FA13B915 I0042Run this (start the shell, reset, leave, then run the script):
python ds8sim.py (then: simctl reset, quit)
python ds8sim.py -hmc1 10.0.0.1 -user admin -script setup-17.txtYou should see this (output shortened):
SIM0100I simctl: factory state restored (users and passwords kept; use simctl reset -all to reset them too).
Enter your password:
CMUC00004I mkarray: Array A0 successfully created.
...
SIM0103I simctl: host port 10000090FA13B914 logged in to I0032.
SIM0103I simctl: host port 10000090FA13B915 logged in to I0042.On macOS and Linux, type python3 instead of python. After that, start the shell again with python ds8sim.py for the next steps.
✅ Checkpoint: the script ends with two SIM0103I lines and no error.
2Look before you change anything
Note down the size of every volume and the free space in every pool, because you’ll compare against these numbers after each change.
Run these:
lsfbvol
lsextpoolYou should see this:
dscli> lsfbvol
Date/Time: 24 October 2026 10:44:17 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
Name ID accstate datastate configstate deviceMTM datatype extpool cap (2^30B) cap (10^9B) cap (blocks)
============================================================================================================
app_2000 2000 Online Normal Normal 2107-900 FB 512 P0 10.0 - 20971520
app_2001 2001 Online Normal Normal 2107-900 FB 512 P0 10.0 - 20971520
app_2100 2100 Online Normal Normal 2107-900 FB 512 P1 10.0 - 20971520
db_2204 2204 Online Normal Normal 2107-900 FB 512 P2 15.0 - 31457280
dscli> lsextpool
Date/Time: 24 October 2026 10:44:17 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
Name ID stgtype rankgrp status availstor (2^30B) %allocated available reserved numvols
======================================================================================
FB_0 P0 fb 0 below 99576 0 6372864 64 2
FB_1 P1 fb 1 below 99576 0 6372864 64 1
T2_0 P2 fb 0 below 35388 0 2264842 128 1Volume 2204 is 15 GiB in pool P2 (T2_0), and P2 has 2264842 available extents of 16 MiB.
✅ Checkpoint: you know the current size of 2204 and the free extents in P2.
3See where the database volume lives
Run this:
showfbvol -rank 2204You should see this:
dscli> showfbvol -rank 2204
Date/Time: 24 October 2026 10:44:17 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
Name db_2204
ID 2204
extpool P2
exts 960
cap (2^30B) 15.0
volgrp V0
sam Standard
eam rotateexts
realextents 960
==============Rank extents==============
rank extents capacity (MiB/cyl) metadata
========================================
R2 480 7680 yes
R3 480 7680 no
(output shortened)Look at the last few lines. The 960 extents of 2204 are split evenly, 480 on rank R2 and 480 on R3, because eam is rotateexts, and since the volume is in volume group V0, saat-host1 can see it.
✅ Checkpoint: 2204 shows exts 960, sam Standard, eam rotateexts.
4Grow the database volume from 15 to 30 GiB
The DS8000 asks you to confirm because some operating systems can’t cope with a disk that changes size. Answer y.
Run this:
chfbvol -cap 30 2204You should see this:
dscli> chfbvol -cap 30 2204
CMUC00332W chfbvol: Some host operating systems do not support changing the volume size. Are you sure that you want to resize the volume? [y/n]: y
CMUC00026I chfbvol: FB volume 2204 successfully modified.Now check the result:
showfbvol -rank 2204You should see this:
dscli> showfbvol -rank 2204
Date/Time: 24 October 2026 10:44:17 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
Name db_2204
ID 2204
exts 1920
cap (2^30B) 30.0
cap (blocks) 62914560
realextents 1920
==============Rank extents==============
rank extents capacity (MiB/cyl) metadata
========================================
R2 960 15360 yes
R3 960 15360 no
(output shortened)The volume now has 1,920 extents. The extra 960 were striped again, so R2 and R3 hold 960 each, and the host stayed mapped the whole time.
✅ Checkpoint: cap (2^30B) shows 30.0 and both ranks show 960 extents.
5See the pool pay for it
Run this:
lsextpoolYou should see this:
dscli> lsextpool
Date/Time: 24 October 2026 10:44:17 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
Name ID stgtype rankgrp status availstor (2^30B) %allocated available reserved numvols
======================================================================================
FB_0 P0 fb 0 below 99576 0 6372864 64 2
FB_1 P1 fb 1 below 99576 0 6372864 64 1
T2_0 P2 fb 0 below 35373 0 2263882 128 1P2 went from 2,264,842 to 2,263,882 available extents, a drop of 960, which is 15 GiB. A standard volume takes all its new extents in one go.
✅ Checkpoint: P2 lost 960 extents and P0 and P1 are unchanged.
6Grow a thin volume without the prompt
-quiet skips the y/n question, so only use it in scripts, and only after you’ve checked the host.
Run these:
chfbvol -quiet -cap 20 2000
lsfbvol 2000You should see this:
dscli> chfbvol -quiet -cap 20 2000
CMUC00026I chfbvol: FB volume 2000 successfully modified.
dscli> lsfbvol 2000
Date/Time: 24 October 2026 10:44:17 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
Name ID accstate datastate configstate deviceMTM datatype extpool cap (2^30B) cap (10^9B) cap (blocks)
============================================================================================================
app_2000 2000 Online Normal Normal 2107-900 FB 512 P0 20.0 - 41943040Volume 2000 is an ESE volume, so it grew to 20 GiB without taking a single extent from P0. Thin volumes only take extents when the host writes data.
✅ Checkpoint: 2000 shows 20.0 GiB.
7Tell the host about the new size
The host keeps seeing the old size until it rescans. On saat-host1 (Ubuntu with multipath, Lesson 15) the steps look roughly like this:
sudo rescan-scsi-bus.sh -s
sudo multipathd resize map mpatha
sudo pvresize /dev/mapper/mpatha
sudo lvextend -r -L +15G /dev/vgdata/lvdbRescan every path under the multipath device, not only one, or multipath won’t resize. The -r flag tells lvextend to grow the file system as well.
✅ Checkpoint: you can name the four host steps: rescan, multipath resize, PV resize, LV and file system resize.
8Fill a thin volume, then reclaim it
The app team tells you volume 2001 was a test disk and they’ve finished with it. First, pretend the host wrote 6 GiB to it.
Run these:
simctl write 2001 6
showfbvol 2001You should see this:
dscli> simctl write 2001 6
SIM0102I simctl: volume 2001 now has 384 allocated extents (6 GiB written).
dscli> showfbvol 2001
Date/Time: 24 October 2026 10:44:17 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
Name app_2001
exts 640
cap (2^30B) 10.0
volgrp V0
sam ESE
realextents 384
realcap (MiB) 6144
(output shortened)The volume is 10 GiB (640 extents), but only realextents 384 are in use. Now unmap it and release the space, and note that initfbvol warns you all the data will be lost.
Run these:
chhost -action unmap -volume 2001 saat-host1
initfbvol -action releasespace 2001You should see this:
dscli> chhost -action unmap -volume 2001 saat-host1
CMUC00531I chhost: The host saat-host1 is successfully modified.
dscli> initfbvol -action releasespace 2001
CMUC00337W initfbvol: Are you sure that you want to free all extents and lose the data associated with the FB volume 2001? [Y/N]: y
CMUC00340I initfbvol: 2001: The command releasespace has completed successfully.Check it:
showfbvol 2001You should see this:
dscli> showfbvol 2001
Date/Time: 24 October 2026 10:44:17 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
Name app_2001
exts 640
cap (2^30B) 10.0
volgrp -
sam ESE
realextents 0
realcap (MiB) 0
(output shortened)realextents is back at 0 and volgrp shows -. The empty 10 GiB volume is still there, so you could map it again if you wanted.
✅ Checkpoint: 2001 shows realextents 0 and volgrp -.
9Delete the volume the safe way
Run these:
rmfbvol -safe 2001
lsfbvolYou should see this:
dscli> rmfbvol -safe 2001
CMUC00027W rmfbvol: Are you sure you want to delete FB volume 2001? [Y/N]: y
CMUC00028I rmfbvol: FB volume 2001 successfully deleted.
dscli> lsfbvol
Date/Time: 24 October 2026 10:44:17 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
Name ID accstate datastate configstate deviceMTM datatype extpool cap (2^30B) cap (10^9B) cap (blocks)
============================================================================================================
app_2000 2000 Online Normal Normal 2107-900 FB 512 P0 20.0 - 41943040
app_2100 2100 Online Normal Normal 2107-900 FB 512 P1 10.0 - 20971520
db_2204 2204 Online Normal Normal 2107-900 FB 512 P2 30.0 - 62914560Since 2001 was in no volume group and had no recent I/O, -safe let it go after the usual CMUC00027W question.
✅ Checkpoint: lsfbvol lists three volumes and 2204 is 30.0 GiB.
Break It, Then Fix It
Keep the same shell session from the lab. Next you’ll make the two mistakes that do the most damage in real volume work, trying to shrink a disk and deleting one a host is still using.
1Break it: try to shrink the database volume
Someone gave 2204 too much space and wants 10 GiB back, so try setting it to 20 GiB.
Run this:
chfbvol -quiet -cap 20 2204You’ll get this error:
dscli> chfbvol -quiet -cap 20 2204
CMUN02039E chfbvol: 2204: The new capacity must be larger than the current capacity. A volume cannot be reduced in size.Why: a DS8000 volume can only grow. The host’s file system might have data anywhere on the disk, even in the last gigabyte, and the storage has no way of knowing, so IBM blocks shrinking in both the DS CLI and the GUI.
(The message text here is a practice shell message; a real DS8000 refuses too, with its own wording.)
Fix: there’s no shrink. If the space has to come back, the host team moves the data to a new, smaller volume (LVM pvmove, Storage vMotion, a database copy), and you delete the old one using the steps in the next break. Size LUNs from real growth figures so you don’t end up here.
✅ Checkpoint: you can explain why the DS8000 refuses to shrink 2204 and how data really gets onto a smaller LUN.
2Break it: delete a disk the host is using
Volume 2000 is still mapped to saat-host1. Get the host to send it some I/O, then try to delete it, first with -safe and then without any flag.
Run these:
simctl io 2000
rmfbvol -safe 2000
rmfbvol -quiet 2000You’ll get these errors:
dscli> simctl io 2000
SIM0101I simctl: host I/O recorded on volume 2000 (in use for the next 5 minutes).
dscli> rmfbvol -safe 2000
CMUC00253E rmfbvol: Volume IBM.2107-78SV001/2000 is assigned to a user-defined volume group. No volumes were deleted.
dscli> rmfbvol -quiet 2000
CMUN02948E rmfbvol: 2000: The Delete logical volume task cannot be initiated because the Allow Host Pre-check Control Switch is set to true and the volume that you have specified is in use (host I/O in the last 5 minutes or a Copy Services relationship).Why: the DS8000 protected you twice. -safe stopped because 2000 is still in the host’s volume group V0 (CMUC00253E, a real IBM message), and without -safe the in-use check stopped it because the volume had host I/O in the last 5 minutes. CMUN02948E is a practice shell message modelled on IBM’s CKD text.
The dangerous move here would be rmfbvol -force 2000. It skips the in-use check and deletes the volume, and the host starts getting I/O errors on a disk that’s suddenly gone. Don’t do it to “save time”.
Fix: go in the right order. The host team stops the application and removes the disk from the OS, then you unmap it, wait for the 5-minute I/O window to pass (in the shell, simctl tick 6 moves the clock forward), check, and delete.
Run these:
chhost -action unmap -volume 2000 saat-host1
simctl tick 6
showfbvol 2000
rmfbvol -safe 2000
lsfbvolYou should see this:
dscli> chhost -action unmap -volume 2000 saat-host1
CMUC00531I chhost: The host saat-host1 is successfully modified.
dscli> simctl tick 6
SIM0112I simctl: clock advanced 6 minutes.
dscli> showfbvol 2000
Date/Time: 24 October 2026 10:50:17 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
Name app_2000
exts 1280
volgrp -
sam ESE
realextents 0
(output shortened)
dscli> rmfbvol -safe 2000
CMUC00027W rmfbvol: Are you sure you want to delete FB volume 2000? [Y/N]: y
CMUC00028I rmfbvol: FB volume 2000 successfully deleted.
dscli> lsfbvol
Date/Time: 24 October 2026 10:50:17 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
Name ID accstate datastate configstate deviceMTM datatype extpool cap (2^30B) cap (10^9B) cap (blocks)
============================================================================================================
app_2100 2100 Online Normal Normal 2107-900 FB 512 P1 10.0 - 20971520
db_2204 2204 Online Normal Normal 2107-900 FB 512 P2 30.0 - 62914560volgrp - shows no host can see 2000 now, and the I/O window has passed, so rmfbvol -safe deleted it. On a real system you’d also get the host owner’s confirmation in writing before you answer y.
✅ Checkpoint: lsfbvol shows only 2100 and 2204.
This happened at work
The cleanup script that used -force
A SaaS company ran its customer platform on VMware, with the datastores on a DS8000, and every quarter a storage engineer cleaned up old LUNs from a decommissioning list. To speed things up he wrote a script that ran rmfbvol -quiet -force on every volume ID in the list. One quarter the list had a typo: volume 4A12 had been written as 4A21, and 4A21 was a live datastore holding 38 customer VMs. The script deleted it in under a second, because -force skipped the in-use check that would have stopped it and -quiet skipped the question that might have made him look twice.
The VMs froze and then crashed with “all paths down” on that datastore. The platform was partly down for nine hours while the team restored the VMs from the nightly backups, and customers lost a day of data.
Root cause: a manual list that nobody cross-checked, run by a script that removed both safety nets. Fix: the new cleanup script runs lsfbvol and showfbvol first and stops if a volume is in any volume group or shows recent I/O. It uses rmfbvol -safe and never -force, and a second person checks every list against the host owner’s ticket.
The lesson: the DS8000’s in-use check isn’t something you bypass to save time. When a volume won’t delete, the system is telling you something you need to hear.
Common mistakes and troubleshooting
| Symptom | Likely cause | What to check / fix |
|---|---|---|
| Volume grew on the DS8000 but the host still shows the old size | Host not rescanned, or only one path rescanned | Rescan every path and resize the multipath map, then the PV, LV and file system. |
| chfbvol -cap refuses to grow a volume | The volume is in FlashCopy, Metro Mirror or Global Copy | Remove the relationships, expand, and rebuild them (target first, then source). |
| You typed a smaller size by mistake | A volume can never shrink | Nothing was changed. Give the total size you want, which has to be larger than today’s. |
| chfbvol fails: not enough extents | The pool is too full for a standard volume | Check lsextpool, then add capacity or use another pool. ESE volumes grow without taking extents. |
| rmfbvol deletes nothing | Volume is in use (I/O in the last 5 minutes or Copy Services) or, with -safe, still in a volume group | Unmap it, let the host stop I/O, remove Copy Services, and try the delete again. |
| Thin pool still full after the host deleted files | Host didn’t send UNMAP, or the pool uses 1 GiB extents | Turn on UNMAP on the host (fstrim, VMFS space reclamation), or use initfbvol on a LUN you’re able to empty. |
Two habits keep you out of trouble: before any delete, run showfbvol and read volgrp, and after any change, run lsextpool and check the free extents moved by the amount you expected.
Interview questions
Click a question to open it. Each one is worded the way an interviewer would ask it, and underneath you’ll find why they ask it and one way you could answer in your own words.
Fresher level
1. An app team asks you to add 20 GB to a 100 GB LUN on a DS8000. What do you actually type, and what else has to happen?
Why they ask this: They want to hear that the size in the command is the new total, and that the host has its own work to do as well.
How you might answer: I’d look at the volume first with showfbvol and then run chfbvol -cap 120 with the volume ID, because the value is the new total and not the amount to add. Once I’d confirmed the OS supports online resizing, I’d answer y to the CMUC00332W warning, and then the host team rescans all the paths and grows the partition or LVM and the file system.
2. Can you make a DS8000 volume smaller? Why or why not?
Why they ask this: They want to see that you know a basic rule and also the reason behind it.
How you might answer: No. IBM doesn’t support shrinking, and neither the DS CLI nor the GUI can do it, because the host might have data at the end of the disk and the storage can’t know that, so a shrink could destroy data. If we really need a smaller LUN, the host copies its data to a new one and we delete the old one.
2–5 years experience
3. Walk me through how you would safely delete a LUN that a Linux server used until last week.
Why they ask this: This is where real outages happen, so they want a clear order of steps and proof that you check before you delete.
How you might answer: First I’d get the host owner to confirm in writing that the disk isn’t needed any more, and they’d unmount it and remove it from multipath and the OS. Then I’d unmap it from the host on the DS8000 and check that showfbvol shows volgrp -.
I’d make sure there are no Copy Services relationships and no I/O in the last 5 minutes before running rmfbvol -safe. If it refuses, I’d find out why rather than reach for -force, and at the end I’d check lsextpool to see the extents came back.
4. What’s the difference between rmfbvol with no flag, -safe and -force? When would you use each one?
Why they ask this: They’re checking that you know the safety levels and won’t reach for -force out of habit.
How you might answer: With no flag, the DS8000 only deletes volumes that aren’t in use, so no Copy Services relationship and no I/O in the last 5 minutes. -safe also refuses if any of the volumes is still in a user-defined volume group, and in that case it deletes nothing. -force skips the in-use check, and I’d only use it under an approved change once I’d proven the volume is dead; even then it can’t delete a volume in an active Safeguarded Copy relationship.
Senior level
5. A thin pool is at 88% and the VMware team says they deleted 5 TB of VMs. Why didn’t the pool go down, and what would you do?
Why they ask this: It shows whether you understand thin provisioning end to end, host behaviour included, and not only the DS8000 command.
How you might answer: Deleting files or VMs doesn’t free any extents on the array unless the host sends SCSI UNMAP, and on the DS8000 UNMAP only works for ESE volumes in pools with 16 MiB extents. So I’d check the pool’s extent size and whether VMFS space reclamation is turned on.
If a whole datastore is empty, the host team can remove it, and then I can release its space with initfbvol -action releasespace or delete it.
6. You need to grow a 3 TiB database LUN that’s in Metro Mirror to 5 TiB. How do you plan that change?
Why they ask this: A senior person has to spot hidden limits and plan the whole change, DR included, before starting.
How you might answer: Two things get in the way. The volume has to come out of Metro Mirror before it can grow, and Copy Services only support LUNs up to 4 TiB, so a 5 TiB LUN couldn’t be mirrored again. I’d push back and suggest adding a second LUN to the host’s volume group instead.
If they really need 5 TiB, I’d work out a new design with the DR team. If we only grow to 4 TiB, the change is to remove the pair, grow source and target to the same size, rebuild the pair with a full copy, and accept the DR gap while it copies.
Quick quiz
Q1. You run chfbvol -cap 50 on a 30 GiB volume. What size is it afterwards?
- 80 GiB
- 50 GiB
- 30 GiB, the command fails
- 20 GiB
Show answer
B: -cap is the new total size, so the volume becomes 50 GiB.
Q2. Which command can make a DS8000 FB volume smaller?
- chfbvol -cap with a smaller number
- chfbvol -shrink
- initfbvol -action releasespace
- None, volumes can only grow
Show answer
D: IBM doesn’t support shrinking; the DS CLI and GUI can only grow a volume.
Q3. When does the DS8000 treat an FB volume as in use?
- When it is larger than 4 TiB
- When it had I/O in the last 5 minutes or is in a Copy Services relationship
- When it is an ESE volume
- When the HMC is offline
Show answer
B: Recent I/O (5 minutes) or a Copy Services relationship puts an FB volume in use.
Q4. What does rmfbvol -safe do if one of the volumes is in a user-defined volume group?
- Deletes the others and keeps that one
- Deletes all of them
- Fails and deletes nothing
- Unmaps it first
Show answer
C: CMUC00253E, and no volumes are deleted.
Q5. What does initfbvol -action releasespace do?
- Grows an ESE volume
- Frees all extents of an ESE volume and loses its data
- Deletes a standard volume
- Moves a volume to another pool
Show answer
B: It returns every extent of an ESE volume to the pool, and the data is gone.
Quick recap
chfbvol -capandchckdvol -capgrow a volume online; the value is the new total size.- A DS8000 volume can never shrink, so if you have to, move the data to a new, smaller LUN.
- Remove Copy Services relationships before you expand. LUNs go up to 16 TiB, but Copy Services only support them up to 4 TiB.
- Once the DS8000 has grown a LUN, the host has to rescan every path and grow its partition and file system.
- Delete in this order: the host removes the disk, you unmap, wait 5 minutes, then run
rmfbvol -safe. Stay away from-force. initfbvol -action releasespacegives an ESE volume’s extents back and wipes it; UNMAP needs 16 MiB extents.
Next lesson
Lesson 18: FlashCopy and Safeguarded Copy hands-on → You make point-in-time copies, refresh them and learn what Safeguarded Copy really needs.
Further reading: DS8000 volume expansion
Want to go deeper into DS8000 volume expansion? IBM explains dynamic volume expansion and the delete checks in the IBM Storage DS8A00 Architecture and Implementation Guide (IBM Redbooks). To review how these volumes were made, go back to Lesson 13: Create FB volumes (mkfbvol).
You can also see the full plan for this course on the IBM DS8000 Implementation course page.
Try it yourself: open the DS8000 volume expansion command builder, type in the volume ID and the new size, and it gives you chfbvol with a showfbvol check before and after.