Does loopback-device-backed-LVM operations such as lvextend need call sync afterward?

Question

• There is an os image file say test.dd, and an LVM managed partition inside.
• Enlarge the os image file size, then enlarge the partition size to full.
• Create a loopback device for test.dd, then get the LVM managed partition device, such as /dev/loop0p1
• Activate the LVM VG(Volume Group), get an LV(Logical Volume) in it, such as /dev/dm-1
• Enlarge PV(Physical Volume) size by pvresize /dev/loop0p1
• Enlarge LV(Logical Volume) size by lvextend -l +100%FREE /dev/dm-1

My questions are (actually just one: how can I safely copy the test.dd out to somewhere else):

1. can I copy test.dd out safely? (I don't care whether test.dd in the disk has been physically flushed out, I just want to copy it out to somewhere else, either from disk or file buffer).
2. or should I call sync before copy?
3. or should I detach the loopback device before copy?
4. what if failed to detach the loopback device anyway?

EDIT: I am reluctant to call sync command because it sometimes it is very slow and become uninterruptible(i.e., kill -9 does not work then).

EDIT: The reason I ask the question is that I have experienced issues of data inconsistency related to loopback device and the backing file in other cases.

EDIT: For now, I use a script which call vgchange --activate n --select vg_uuid=$LVM_VG_UUID to deactivate the Volume Group, then losetup --detach /dev/loop0, followed by an udevadm settle then I started to copy the test.dd out. I just wonder whether I can copy the test.dd out without such hassle.

EDIT: sorry for wrong input for the order of command. It actually is vgchange --activate n --select vg_uuid=$LVM_VG_UUID -> udevadm settle -> losetup --detach /dev/loop0 -> cp test.dd ...

Answer 1

I don't really know. I would hope it's not necessary, but I'm not sure about LVM.

I expect if you deactivate the whole LVM VG, and anything else using the loop device, it would be safe.

In Linux administration, the usual norm seems to be that a final sync is redundant.

umount flushes the cache, fdisk calls fsync for you, etc.

Additionally, Linux has an implicit sync when the last user of a block device closes it. So if you've deactivated everything, you haven't really avoided running sync /dev/loop0 :-).

Though, I definitely agree with avoiding bare sync, i.e. flushing all devices.

And if you're deactivating everything, perhaps you can just as easily deactivate the loop device as well. Which could help provide assurance you haven't missed anything that's holding the loop device open, and still has unwritten data.

In case it helps make you happier, the kernel doesn't write (or read) this LVM metadata. It's all in userspace. And there is no LVM daemon holding writeback cache. lvmetad is a read-cache only.