Moving a Volume

Apart from the ownership marker, nothing about the serving host is written to the bucket. Moving a volume is a detach on one host and an attach on the other.

Planned move

1. On the old host, stop cleanly, then detach.

   sudo flexblock detach /dev/nvme1n1p1

   detach releases ownership and clears the local cache. The volume’s data in the bucket is left intact.

2. On the new host, install the same grant and make credentials available, then attach and start.

   sudo flexblock attach /dev/nvme0n1p2
   sudo flexblock start /dev/nvme0n1p2 --ublk-dev-id 0

The new host’s cache starts empty and warms on demand. It can be a different size and kind of device: only the volume’s geometry carries across.

If detach refuses

detach refuses while the cache holds dirty data or pending discards, or after an unclean stop (exit code 16), because that data exists nowhere else. The fix is to start the daemon, let it flush, and stop it cleanly; wait for flexblock_cache_dirty_slots and flexblock_discard_deletes_pending to reach 0 if you are watching metrics. Then run detach again.

detach --allow-dirty-loss discards that data instead. Prefer flushing.

Taking over from an unreachable host

If the old host is gone and cannot detach, take ownership from the new host.

sudo flexblock attach /dev/nvme0n1p2 --take-ownership
sudo flexblock start /dev/nvme0n1p2 --ublk-dev-id 0

--take-ownership replaces the old host’s ownership marker. What happens next:

• If the old daemon is somehow still running, it stops writing to the bucket within its 45-second lease, and stops without flushing at its next ownership check.
• The first start on the new host waits 285 seconds before serving, so the old owner can no longer write by the time the new one does.

Data loss

Taking ownership abandons whatever the old host had not flushed. That data stays on the old cache device, invisible to the new owner. What the bucket holds is not a point-in-time copy: recent writes to different chunks may be only partly present, so expect the filesystem to replay its journal or need a repair (xfs_repair, fsck), and verify databases before trusting them. Take ownership only when the old host is really gone; otherwise stop the daemon and detach there.

Handling the old cache afterward

The forced stop leaves the old host’s cache unclean and superseded, so nothing on it can be flushed. If the old host comes back:

• detach refuses the old cache with exit code 13. Give it up with detach --allow-dirty-loss.
• To reuse that host to serve the volume again, run attach --take-ownership --overwrite, which lays out a fresh cache.

Related

• Ownership
• Where Data Can Be Lost
• flexblock attach reference
• flexblock detach reference