1
  • 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 ...

Improve this question
6
  • What do you mean by "get an LG in it"? Do you mean VG? Commented May 24, 2023 at 5:19
  • 1
    Sorry, typo. LG should be LV, logical volume. VG means Volume Group, both are LVM terms. Commented May 24, 2023 at 5:33
  • Is it LV mounted and in some I/O operations? Commented May 24, 2023 at 6:11
  • The LV is not mounted. Commented May 24, 2023 at 6:20
  • If you do not extend the filesystem located in LV, the operation of lvextend is very fast (it just replace (more or less) one value) so you can copy the loop file after lvextend command ends. Commented May 24, 2023 at 6:24

1 Answer 1

Reset to default
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.

Improve this answer
4
  • thank you. Your answer is still helpful. Never mind, this is not an obvious thing. For now, I just trust the result by following way: umount all things, losetup --detach all things. I dare not trust sync /dev/loop0 for my case. Commented May 24, 2023 at 11:07
  • 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. Commented May 24, 2023 at 11:11
  • Added more EDIT, see my current solution, pretty close to what you have said. Commented May 24, 2023 at 11:18
  • 1
    Thanks very much for taking a detail look to it. Exactly udevadm setttle after losetup --detach ... is unnecessary. I typed wrong order, actually the script is vgchange --activate n --select vg_uuid=$LVM_VG_UUID -> udevadm settle -> losetup --detach /dev/loop0, I remember that udevadm settle matters after any partition related device changes, otherwise I got "device busy" error sometimes. Commented May 25, 2023 at 4:16

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.