search

trynd / wren

Linux boot platform that provides a portable, multi-system, run-in-memory Linux environment.
GNU General Public License v3.0
0 stars 1 forks source link

BUG: Cannot take LVM snapshots #2

Closed codewithmichael closed 9 years ago

codewithmichael commented 9 years ago

Addressed by PR #12

As noted in the comments of version 0.1.0, copy/save.sh, lines 222-235, LVM snapshots don't work (they completely hang the system) when using overlayfs filesystems in Ubuntu 14.04.

# determine whether to use a snapshot
use_snapshot=0
###
### DISABLED: Snapshots with udev/overlayfs are currently broken in Ubuntu 14.04
###
#test -e "$LVM_PATH_LV_SAVE" \
#    && lvm_save_image_path=`getLvmSaveImagePath` \
#    && test -f "$lvm_save_image_path" \
#    && lvm_snapshot_image_path=`getLvmSnapshotImagePath` \
#    && use_snapshot=1 \
#    || echo "Snapshot not possible - falling back to standard copy mode"
###
### END DISABLED
###

There's an open bug on Launchpad covering the issue, but (as of this posting) the last comment was on July 14, 2014.

The code that enables snapshots in save.sh has been disabled (commented out) but that means saves are copied from the live file system — that's certainly not ideal. If there commonly associated files are being simultaneously updated when the save begins, there's a good chance that they'll be saved out of sync.

I've tested against 14.04 kernels 3.13.0-32-generic and 3.13.0-44-generic. As noted in the ticket on Launchpad, this also seems to be a problem with the kernel from Ubuntu 13.10 (kernels 3.11.0-xx). I went back and tested against 12.04 (kernels 3.2.0-29-generic-pae and 3.2.0-48-generic-pae) and the bug was not present, so the issue began some time after that. Unfortunately there are too many kernel and package revisions in between there to go sifting through them without more information as to exactly what's causing the hang.

Random speculation: I've come across both regular logical volume and snapshot volume hangs in the past due to problems/conflicts in udev — that might be a starting point for someone(?). In this case it's more detrimental than my past experiences, as the hang occurs on the running file system and locks the active OS after a couple of seconds (logins, su, sudo, etc. stop working and then all new processes hang), so it's hard to troubleshoot. Unfortunately, I'm not sure how to go about disabling the udev service in this case, since it handles all of the device mapper interaction.

Without some work from the guys upstream, I don't know that there is anything we can do about this one directly. But, if anyone knows a workaround it'd be very appreciated.

codewithmichael commented 9 years ago

Marked as wontfix because the switch to Btrfs in v0.2.0 (PR #12) will remedy the situation for our purposes.