Launchpad has imported 1 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=1671964.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2019-02-02T20:36:33+00:00 steved424 wrote: Description of problem: Extending an lvmraid(7) type1 mirror for the second time seems to result in the mirror legs not getting synced, *if* there is another type1 mirror in the vg. Version-Release number of selected component (if applicable): 2.02.176 (4.1ubuntu3) How reproducible: Seems to be reliably reproducible here on Ubuntu 18.04 at least. Steps to Reproduce: # quickly fill two 10G files with random data openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero | dd bs=$((1024*1024*1024)) count=10 of=pv1.img iflag=fullblock openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero | dd bs=$((1024*1024*1024)) count=10 of=pv2.img iflag=fullblock # change loop devices if you have loads of snaps in use losetup /dev/loop10 pv1.img losetup /dev/loop11 pv2.img pvcreate /dev/loop10 pvcreate /dev/loop11 vgcreate testvg /dev/loop10 /dev/loop11 lvcreate --type raid1 -L2G -n test testvg watch lvs -o +raid_sync_action,sync_percent,raid_mismatch_count testvg # wait for sync lvcreate --type raid1 -L2G -n test2 testvg watch lvs -o +raid_sync_action,sync_percent,raid_mismatch_count testvg # wait for sync # the following will sync OK, observe kernel message for output from md subsys noting time taken # lvextend -L+2G testvg/test2 watch lvs -o +raid_sync_action,sync_percent,raid_mismatch_count testvg # wait for sync # the following will FAIL to sync, the sync will seem to complete instantly, e.g: # Feb 02 15:22:50 asr-host kernel: md: resync of RAID array mdX # Feb 02 15:22:50 asr-host kernel: md: mdX: resync done. # lvextend -L+2G testvg/test2 lvchange --syncaction check testvg/test2 watch lvs -o +raid_sync_action,sync_percent,raid_mismatch_count testvg # observe error count Actual results: The sync after the final lvextend completes instantly, and a subsequent lvchange --syncaction check reports a high number for raid_mismatch_count Expected results: The sync after the final lvextend should take at least a few seconds, and a subsequent lvchange --syncaction check should not report any errors for raid_mismatch_count (unless the underlying hardware has failed.) Additional info: Launchpad bug: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1814389 Reply at: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1814389/comments/2 ** Changed in: lvm2 Status: Unknown => Confirmed ** Changed in: lvm2 Importance: Unknown => Undecided -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1814389 Title: Second extend of second lvmraid mirror does not sync Status in lvm2: Confirmed Status in lvm2 package in Ubuntu: New Bug description: This is a weird corner case. Extending an lvmraid(7) type1 mirror for the second time seems to result in the mirror legs not getting synced, *if* there is another type1 mirror in the vg. This reliably reproduces for me: # quickly fill two 10G files with random data openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero | dd bs=$((1024*1024*1024)) count=10 of=pv1.img iflag=fullblock openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero | dd bs=$((1024*1024*1024)) count=10 of=pv2.img iflag=fullblock # change loop devices if you have loads of snaps in use losetup /dev/loop10 pv1.img losetup /dev/loop11 pv2.img pvcreate /dev/loop10 pvcreate /dev/loop11 vgcreate testvg /dev/loop10 /dev/loop11 lvcreate --type raid1 -L2G -n test testvg watch lvs -o +raid_sync_action,sync_percent,raid_mismatch_count testvg # wait for sync lvcreate --type raid1 -L2G -n test2 testvg watch lvs -o +raid_sync_action,sync_percent,raid_mismatch_count testvg # wait for sync # the following will sync OK, observe kernel message for output from md subsys noting time taken # lvextend -L+2G testvg/test2 watch lvs -o +raid_sync_action,sync_percent,raid_mismatch_count testvg # wait for sync # the following will FAIL to sync, the sync will seem to complete instantly, e.g: # Feb 02 15:22:50 asr-host kernel: md: resync of RAID array mdX # Feb 02 15:22:50 asr-host kernel: md: mdX: resync done. # lvextend -L+2G testvg/test2 lvchange --syncaction check testvg/test2 watch lvs -o +raid_sync_action,sync_percent,raid_mismatch_count testvg # observe error count This may cause administrator alarm unnecessarily ... :/ For some reason the precise sizes with which the LVs are created, and are then extended by, do appear to matter. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: lvm2 2.02.176-4.1ubuntu3 ProcVersionSignature: Ubuntu 4.15.0-43.46-generic 4.15.18 Uname: Linux 4.15.0-43-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 Date: Sat Feb 2 15:33:16 2019 ProcEnviron: TERM=screen PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: lvm2 UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.lvm.lvm.conf: 2018-07-22T18:30:15.470358 To manage notifications about this bug go to: https://bugs.launchpad.net/lvm2/+bug/1814389/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
