Rescanning and growing block devices - when the kernel still sees the old size · Linux

The storage team grew the LUN from 2 TB to 4 TB an hour ago and sent you the ticket. lsblk still says 2 TB. Nothing is broken and nothing needs a reboot - the kernel simply caches a device’s capacity and its partition table, and neither is re-read spontaneously.

The work is a chain of layers, each of which has to be told separately, and each of which will happily report success while the layer above it is still stale.

The chain

Layer	Refreshed by	Read back with
SCSI device capacity	`echo 1 > /sys/block/sdb/device/rescan`	`blockdev --getsize64 /dev/sdb`
Multipath map	`sudo multipathd resize map mpatha`	`multipath -ll`
Partition table	`sudo partx -u /dev/sdb`	`lsblk /dev/sdb`
Partition size	`sudo growpart /dev/sdb 1`	`lsblk /dev/sdb1`
LVM physical volume	`sudo pvresize /dev/sdb1`	`sudo pvs -o pv_name,pv_size,pv_free`
Logical volume	`sudo lvextend -L +1T vg0/data`	`sudo lvs`
Filesystem	`sudo xfs_growfs /srv/data` or `resize2fs`	`df -h /srv/data`

Every step is additive and none of them destroys data - with two exceptions marked below, which is why the exceptions get the attention.

Step 1: make the kernel re-read the capacity

Read-only / Safethe two size views— blockdev --getsize64 reports bytes: 2 TiB here. /sys/block/sdb/size is always in 512-byte units regardless of the device logical sector size, so 4294967296 x 512 is the same 2 TiB. That 512 is a fixed convention of the sysfs interface and not a statement about the device - on a 4Kn disk the number is still 512-byte units, which trips up anyone who multiplies it by LOG-SEC.

$ blockdev --getsize64 /dev/sdb; cat /sys/block/sdb/size

2199023255552
4294967296

Illustrative output

Configuration changerescan one SCSI device— Asks the SCSI layer to re-issue READ CAPACITY to this device. It affects only the named device, does not disturb in-flight I/O, and is the correct first step for a LUN that grew. The tee prints the value it wrote, which is not a result - confirm with blockdev --getsize64 and with a kernel message about the capacity change.

$ echo 1 | sudo tee /sys/block/sdb/device/rescan

Read-only / Safeconfirm the kernel agreed— 'detected capacity change' is the line that proves the rescan did something. Its absence means the array has not actually presented the new size to this initiator yet, and every subsequent step will fail for a reason that looks unrelated. Stop here and go back to the storage team rather than escalating to partprobe.

$ sudo dmesg -T | tail -3

[Tue Aug 11 14:22:07 2026] sd 6:0:0:1: [sdb] 8589934592 512-byte logical blocks: (4.40 TB/4.00 TiB)
[Tue Aug 11 14:22:07 2026] sd 6:0:0:1: [sdb] 4096-byte physical blocks
[Tue Aug 11 14:22:07 2026] sdb: detected capacity change from 2199023255552 to 4398046511104

Illustrative output

For a new LUN that does not yet have a device node, the device-level rescan has nothing to act on. Scan the host bus instead, or use the sg3_utils wrapper that walks every host:

for h in /sys/class/scsi_host/host*/scan; do
  echo '- - -' | sudo tee "$h" > /dev/null
done

# the packaged equivalent, which also handles removals
sudo rescan-scsi-bus.sh

The three dashes are channel target lun, each wildcarded. Scanning a bus is safe but not free: on a large fabric it produces a burst of discovery I/O, so do it once rather than in a loop.

Multipath needs telling twice

On a multipathed LUN, each path is its own SCSI device. Rescan every path - sdb, sdd, sdf, sdh - and then resize the map that sits on top of them:

multipath -ll mpatha
sudo multipathd resize map mpatha

Skipping the map resize is the classic version of this problem: blockdev --getsize64 /dev/sdb reports the new size, the /dev/mapper/mpatha device still reports the old one, and every tool you run afterwards is looking at the multipath device. The symptom is pvresize reporting no change with no error.

Step 2: re-read the partition table

Three commands do overlapping things, and choosing the wrong one is how a resize turns into an outage.

Command	Mechanism	With partitions in use
`blockdev --rereadpt`	`BLKRRPART` ioctl - drops and re-adds every partition	Fails with `EBUSY`
`partprobe`	Tries `BLKRRPART`, falls back to per-partition updates	Usually works, sometimes silently partial
`partx -u`	`BLKPG` ioctl per partition - updates in place	Works

Configuration changeupdate partitions in place— partx --update tells the kernel the new geometry of each existing partition without removing and re-adding it, so it works on a disk whose partitions are mounted and in use. This is the right tool on a running production host. partx -s /dev/sdb lists what the kernel now believes, which is the check to run immediately afterwards.

$ sudo partx -u /dev/sdb

blockdev --rereadpt returning EBUSY is protecting you

BLKRRPART removes every partition device and re-adds it from the on-disk table. The kernel refuses when any partition is mounted, is an active LVM PV, or is open by any process - because completing the operation would invalidate the block device that a mounted filesystem is sitting on.

The wrong response is to unmount production to make the command work. partx -u achieves the same refresh without the remove-and-re-add, on a live system, with no unmount.

Find out what is holding it before doing anything at all:

lsblk /dev/sdb
sudo fuser -vm /dev/sdb1
sudo lsof /dev/sdb1

Step 3: the GPT backup header is now in the middle of the disk

GPT stores a primary header at the start of the disk and a backup header in the last sector. Grow the disk and the backup is suddenly thousands of sectors short of the end, where nothing looks for it.

Read-only / Safediagnose the stale backup GPT— sgdisk --verify reports problems and corrects nothing. This exact wording is what a grown disk produces, and it is not damage: the primary table is intact and the partitions are fine. Nothing will fail today. It fails on the day the primary header is lost and the recovery reads a backup that describes a smaller disk.

$ sudo sgdisk --verify /dev/sdb

Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

Identified 1 problems!

Illustrative output

Data-loss riskmove the backup GPT to the new end of disk— sgdisk -e / --move-second-header relocates the secondary GPT structures to the end of the enlarged disk. It writes to the partition table, so back the table up first with 'sudo sgdisk --backup=/root/sdb-gpt.bin /dev/sdb' and 'sudo sfdisk --dump /dev/sdb > /root/sdb.sfdisk'. Confirm afterwards with sgdisk --verify reporting no problems.

$ sudo sgdisk --move-second-header /dev/sdb

Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or partx(8)
The operation has completed successfully.

Never let parted ask you to Fix this interactively during an incident

parted and fdisk both notice the same condition and both offer to repair it with a prompt:

Warning: Not all of the space available to /dev/sdb appears to be used,
you can fix the GPT to use all of the space (an extra 4294967296 blocks)
or continue with the current setting?
Fix/Ignore?

Answering Fix here is usually correct and occasionally catastrophic, because the same prompt appears when the disk did not grow and the table is genuinely inconsistent - a half-finished clone, a disk imaged from a larger one, a LUN presented from the wrong snapshot. In that case Fix rewrites the table to match the device rather than the data.

Never answer it from muscle memory, and never run parted without -s inside a script where the prompt can be answered by whatever the next line of stdin happens to be. Use sgdisk --verify to see the problem read-only, decide deliberately, and apply the specific fix with sgdisk --move-second-header.

Step 4: grow the partition

Read-only / Safesee the change before making it— growpart -N prints the sfdisk dump it would write and changes nothing. Check two things: the start sector is unchanged - a growpart that moves the start would orphan the filesystem - and the new size ends where you expect. This dry run is the single most valuable guard rail in the whole procedure and it costs one flag.

$ sudo growpart --dry-run /dev/sdb 1

CHANGE: partition=1 start=2048 old: size=4294965248 end=4294967296 new: size=8589932544 end=8589934592
# === old sfdisk -d ===
label: gpt
/dev/sdb1 : start=2048, size=4294965248, type=E6D6D379-F507-44C2-A23C-238F2A3DF928
# === new sfdisk -d ===
label: gpt
/dev/sdb1 : start=2048, size=8589932544, type=E6D6D379-F507-44C2-A23C-238F2A3DF928

Illustrative output

Drop --dry-run to apply it. growpart rewrites the partition entry in place, keeping the start sector, and then asks the kernel to update. The alternative - deleting the partition in fdisk and recreating it larger - works only if you recreate it at exactly the same start sector, and is how filesystems get orphaned by people who were sure they remembered the number.

Step 5 onwards: PV, LV, filesystem

sudo pvresize /dev/sdb1 - the PV metadata records its own size and does not follow the partition automatically. Confirm with sudo pvs -o pv_name,pv_size,pv_free.
sudo lvextend -r -L +2T vg0/data - the -r flag is equivalent to --fs resize and calls the filesystem-specific resize command in the same step, which removes the window where the LV is larger than the filesystem and nobody has noticed.
df -h /srv/data - the only check that matters to the person who filed the ticket.

xfs_growfs /srv/data and resize2fs /dev/vg0/data are the manual forms if you prefer to do the two steps separately. Both grow online. Both are additive.

The two operations in this chain that destroy data

Everything above grows. Two things shrink, and shrinking is where the data goes.

lvreduce that does not shrink the filesystem first. Removing extents from the end of a logical volume while the filesystem inside still believes it owns them produces a corrupt filesystem, not a smaller one - and growing the LV back does not undo it, because the extents may already have been reallocated.

man 8 lvreduce documents four --fs modes for exactly this question, and the one to know is the warning it attaches to ignore: “using ignore when reducing the LV size may destroy the file system”. Recent LVM defaults to checksize, which refuses the reduction if the filesystem is using the space, but do not rely on which default your version has. Pass -r (equivalent to --fs resize) explicitly so the filesystem is shrunk first, and take a verified backup before a shrink even then.

resize2fs to a size the data does not fit in. ext4 can shrink, but only offline, and only to a size that can hold the existing data after relocation. Run sudo e2fsck -f first - resize2fs requires it - and check the used space with df before choosing a target.

XFS cannot shrink at all. There is no xfs_shrinkfs. The only way to make an XFS filesystem smaller is to create a new smaller one and restore into it. Plan XFS volumes on the assumption that every gigabyte you give them is permanent.

Why nothing re-reads capacity on its own

A block device’s capacity is read once, at discovery, with a READ CAPACITY command, and cached in the gendisk structure. The partition table is parsed once at the same time and turned into partition block devices.

Neither is re-read spontaneously, and that is deliberate. Re-reading capacity means an I/O to the device; re-reading the partition table means invalidating block devices that mounted filesystems are using. A kernel that did either on a timer would be a kernel that occasionally pulled a mounted filesystem out from under a running database.

So the refresh is explicit, and each layer keeps its own idea of size:

lsblk -b -o NAME,SIZE,TYPE /dev/sdb        # kernel view of device and partitions
sudo pvs -o pv_name,dev_size,pv_size       # dev_size vs pv_size shows a stale PV
sudo lvs -o lv_name,lv_size vg0
df -B1 --output=source,size /srv/data      # filesystem view

Reading all four and finding four different numbers is not a fault. It is the normal intermediate state of this procedure, and it is why you check after every step rather than only at the end.

The chain

Step 1: make the kernel re-read the capacity

Step 2: re-read the partition table

Step 3: the GPT backup header is now in the middle of the disk

Step 4: grow the partition

Step 5 onwards: PV, LV, filesystem

Knowledge check