Escalated to Bugzilla from IssueTracker
Hello when doing mkswap /dev/dm-xx then pvcreate /dev/dm-xx the swap label is still there, because pvcreate does only wipe the first 2 Kbytes of a device(means md and other lvm headers). It should also wipe swap headers (4Kbytes) See pvcreate.c Line 238 lvm version 2.02.27. We destroyed a productive Filesystem, because our rescue image (fedora live cd) took all swap partition with a valid label online. But the device was a lvm volume with data on it. pvcreate should therefore guarantee that the swap label is removed. This event sent from IssueTracker by dejohnso [Support Engineering Group] issue 190871
you are correct, parts of the swap header are above 2k: 00000ff0 00 00 00 00 00 00 53 57 41 50 53 50 41 43 45 32 |......SWAPSPACE2| I've done some tests with a loop device, rhel4.5 does not allow you to do a swapon after the pvcreate: [root@dhcp-1-31 tmp]# cat /etc/redhat-release Red Hat Enterprise Linux AS release 4 (Nahant Update 5) [root@dhcp-1-31 tmp]# uname -a Linux dhcp-1-31.fab.redhat.com 2.6.9-55.ELxenU #1 SMP Fri Apr 20 17:30:23 EDT 2007 i686 i686 i386 GNU/Linux [root@dhcp-1-31 tmp]# dd of=loopfile bs=1M count=0 seek=204 0+0 records in 0+0 records out [root@dhcp-1-31 tmp]# losetup /dev/loop0 loopfile [root@dhcp-1-31 tmp]# mkswap /dev/loop0 Setting up swapspace version 1, size = 213905 kB [root@dhcp-1-31 tmp]# swapon /dev/loop0 [root@dhcp-1-31 tmp]# swapoff /dev/loop0 [root@dhcp-1-31 tmp]# pvcreate /dev/loop0 Physical volume "/dev/loop0" successfully created [root@dhcp-1-31 tmp]# swapon /dev/loop0 swapon: /dev/loop0: Invalid argument I've transfered the loopback file to a fc9 installation, same result: [root@localhost tmp]# cat /etc/redhat-release Fedora release 9 (Sulphur) [root@localhost tmp]# losetup -d /dev/loop0 [root@localhost tmp]# losetup /dev/loop0 loopfile [root@localhost tmp]# swapon /dev/loop0 swapon: /dev/loop0: Invalid argument
General Escalation Information 1. Provide time and date of the problem - 07-10-2008 01:17pm CEST 2. Provide clear and concise problem description as it is understood at the t ime of escalation * Observed behavior - The customer used some devices as swapspace in the past. Later they used them as PV (ran pvcreate). After booting the rhel4.5 system with a fedora live rescue cd, those PV devices were brought up as swapspace, resulting in data loss. I could not reproduce that, see my last post, but the customer thinks that pvcreate should wipe not only the first 2k but 4k of the device. * Desired behavior - pvcreate should wipe enough bytes to completely remove any swap headers. 3. State specific action requested of SEG - please clarify if we should wipe more than 2k 4. State whether or not a defect in the product is suspected - I don't really know. I could not reproduce it, but pieces of the swap header are still there after pvcreate: 00000ff0 00 00 00 00 00 00 53 57 41 50 53 50 41 43 45 32 |......SWAPSPACE2| Provide supporting info 1. State other actions already taken in working the problem: - Tried to reproduce the issue, verified pvcreate.c, talked to another TAM, did a fulltext search. Please look at BZ 443062
Hi, This is indeed an issue. The problem is in the lvm2 library.. lib/label/label.c with the function.. int label_remove(struct device *dev) This function writes zeros to the size of LABEL_SIZE not taking into account larger labels such as swap. A simple fix would be to write 0s to the size of LABEL_SIZE * 2 but I am not sure that development would agree so I am creating a BZ. Debbie This event sent from IssueTracker by dejohnso [Support Engineering Group] issue 190871
label_remove() is correct as it is: It is purely concerned with LVM labels. What we can do is add specific code in pvcreate.c to recognise a swap signature and ask the user whether or not to remove it - same as we do if we see a software raid md superblock. Ultimately this code should use a central library (shared with all the other apps that format devices) to deal with these cases.
Yes, this is just a RHEL4 dupe of BZ443062. The proposed stop-gap measure is to clear a page-sized area of the device to catch swap signatures. I am not convinced detection is necessary, although it might be marginally useful. Anyway, I will look into the issue.
From man mkswap: > Linux knows about two styles of swap areas, old style and new style. The > last 10 bytes of the first page of the swap area distinguishes them: old > style has ‘SWAP_SPACE’, new style has ‘SWAPSPACE2’ as signature. Alasdair says he wants an interactive prompt and only erase the swap signature when it's present, not touching the optional 2K wipe. This means we need to check on a few places for "SWAP_SPACE" or "SWAPSPACE2", ie. on all useful page-size boundaries (4096, 8192 at very least, maybe sparc can use 64K-paged swap). The other option would be to defer to a more general label-detection library (I believe there's one being worked on by someone). I'll report back when I know more about that.
This has been checked into upstream codebase on 17th of March, so this has been part of 2.02.46 already. I.e. good to go.
Fixed in lvm2-2.02.42-8.el4.
Marking verified in the latest rpms. 2.6.9-94.ELsmp lvm2-2.02.42-9.el4 BUILT: Thu Oct 21 15:49:57 CDT 2010 lvm2-cluster-2.02.42-10.el4 BUILT: Tue Jan 18 06:17:17 CST 2011 device-mapper-1.02.28-3.el4 BUILT: Thu Mar 4 14:48:16 CST 2010 cmirror-1.0.2-1.el4 BUILT: Thu Feb 26 15:29:27 CST 2009 cmirror-kernel-2.6.9-43.14.el4 BUILT: Wed Dec 22 16:24:19 CST 2010 [root@grant-01 ~]# mkswap /dev/sdb1 Setting up swapspace version 1, size = 36569554 kB [root@grant-01 ~]# dd if=/dev/sdb1 count=8 r;¡þw0LÔ\Ë©°SWAPSPACE28+0 records in 8+0 records out [root@grant-01 ~]# pvcreate /dev/sdb1 Wiping swap signature on /dev/sdb1 Physical volume "/dev/sdb1" successfully created [root@grant-01 ~]# dd if=/dev/sdb1 count=8 LABELONEÜ" LVM2 001nLuBkFAeK8ehmEXxgsHPK4BmZvV3QtHP>·ð8+0 records in 8+0 records out
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: This update ensures that the pvcreate utility correctly detects and conditionally wipes swap space signatures.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0236.html