RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 885273 - Old backup files in /etc/lvm/archive not being deleted
Summary: Old backup files in /etc/lvm/archive not being deleted
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.3
Hardware: Unspecified
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: LVM and device-mapper development team
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-08 01:46 UTC by Robert Nichols
Modified: 2012-12-10 14:58 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-10 14:58:28 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Robert Nichols 2012-12-08 01:46:48 UTC 
Description of problem:
In /etc/lvm/archive, old backup files in excess of retain_min and older than retain_days are never automatically deleted.

Version-Release number of selected component (if applicable):
lvm2-2.02.95-10.el6

How reproducible:
Always

Steps to Reproduce:
1. Perform several LVM configuration actions such that more than retain_min files are in the /etc/lvm/archive directory.
2. Wait until the oldest files are more than retain_days old.
3. Perform some more LVM configuration actions.
  
Actual results:
The old files are never deleted.

Expected results:
Files older than retain_days should be deleted until no more than retain_min files remain.

Additional info:
Comment 2 Robert Nichols 2012-12-08 06:45:30 UTC 
Never mind. Just found that the retain_min number is per vg. It would be nice if the comment in lvm.conf said that, though.
Comment 3 Peter Rajnoha 2012-12-10 11:54:04 UTC 
Yes, metadata are VG-based, man lvm.conf documents that already:

backup -- Configuration for metadata backups.

archive_dir -- Directory used for automatic metadata archives.  Backup copies of former metadata for each volume group are archived here.  Defaults to "/etc/lvm/archive".

 backup_dir -- Directory used for automatic metadata backups.  A single backup copy of the current metadata for each volume group is stored here.  Defaults to "/etc/lvm/backup".


However, did you have any problem with removing the metadata archive files? If you do any metadata change so that a new metadata is written/backed up/archived, the retain_min and retain_days should be applied!

What exactly did you mean with "3. Perform some more LVM configuration actions."? Which LVM commands did you use when you expected the old archive files to be removed?
Comment 4 Robert Nichols 2012-12-10 14:35:50 UTC 
This is on a machine used for loading drives to be installed on other systems, all with unique vg names based on the target host name, so the archive directory ends up cluttered with a few entries for each of those "foreign" volume groups. The LVM commands being used are mainly "pvcreate", "vgcreate", "lvcreate", and "vgexport". No individual vg ever has ever had more than 10 commands used, so nothing was ever deleted. There was, of course, no problem with manually deleting those unneeded files.

In retrospect, I don't see how software could better care automatically for this usage case. It's all working as designed, so this should probably be closed "NOTABUG".
Comment 5 Peter Rajnoha 2012-12-10 14:58:28 UTC 
OK, closing then. I just wanted to make sure there's no other problem related to this. Thanks.
Note You need to log in before you can comment on or make changes to this bug.