gpart resize vs. cache?

Ian Lepore ian at
Sun Feb 3 21:09:04 UTC 2013

On Sun, 2013-02-03 at 12:06 -0800, Tim Kientzle wrote:
> I'm tinkering with a disk image that automatically
> fills whatever media you put it onto.  But I'm having
> trouble with gpart resize failing.
> Disk layout:
>    MBR with two slices  mmcsd0s1 and mmcsd0s2
>    bsdlabel with one partition mmcsd0s2a
> Before I can use growfs, I have two gpart resize operations:
> 1)   gpart resize -i 2 mmcsd0
> 2)  gpart resize -i 1 mmcsd0s2
> Step 1 resizes mmcsd0s2 and always succeeds.
> Step 2 resizes mmcsd0s2a and always fails
> with "No space on device."
> BUT if I reboot between these steps, step #2
> always succeeds.
> I suspect that step #1 is updating the partition
> information on disk but that step #2 is somehow
> reading the old size of mmcsd0s2 and thus finding
> that there is no available space to grow the partition.
> gpart(1) doesn't say anything about caching of
> disk partiition info and "gpart list" does show the
> updated information after step #1.
> Is there some trick that will force the partition
> information in memory to be updated (short of
> a reboot or unmount/remount the root filesystem)?

This sounds like one of those situations where the "force re-taste"
incantation may work... just open/close the parent geom for write.  From
script, it's as easy as

  : >/dev/mmcsd0s2

If that doesn't work, try /dev/mmcsd0.

The re-taste trick is usually only needed on things like a usb sdcard
reader where it can't tell you changed media and tries to use the
in-memory info from the prior card.  Since you're using a geom-aware
tool to make a geom change, I wonder why it doesn't do the re-taste

-- Ian

More information about the freebsd-current mailing list