Project

General

Profile

Bug #13782

Snapshotted files not properly purged

Added by John Spray about 3 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
11/12/2015
Due date:
% Done:

0%

Source:
other
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
MDS
Labels (FS):
Pull request ID:

Description

Bad behaviour shown up by test TestStrays.test_snapshot_remove on this branch:
https://github.com/ceph/ceph-qa-suite/tree/wip-snap-strays

It seems like there is a premature purge happening when the head revision is unlinked, the stray dentry for the file (file_a in the test) goes away at that point, and subsequently when the snapshot is deleted we are not purging anything. If you let it pass by the assertion that the purge shouldn't happen after unlink and run to the end of the test, you'll also see that the number of objects in the data pool does not fall to zero.


Related issues

Related to fs - Bug #13777: Ceph file system is not freeing space Resolved 11/12/2015

Associated revisions

Revision 511435f5 (diff)
Added by Yan, Zheng about 3 years ago

client: avoid creating orphan object in Client::check_pool_perm()

Fixes: #13782
Signed-off-by: Yan, Zheng <>

History

#1 Updated by John Spray about 3 years ago

NB the difference between this and #13777 is that in the other bug, we are seeing strays getting stuck (never getting purged) whereas here we are seeing purge go ahead but objects not being properly cleaned up

#2 Updated by John Spray about 3 years ago

  • Related to Bug #13777: Ceph file system is not freeing space added

#3 Updated by Zheng Yan about 3 years ago

John Spray wrote:

It seems like there is a premature purge happening when the head revision is unlinked, the stray dentry for the file (file_a in the test) goes away at that point, and subsequently when the snapshot is deleted we are not purging anything. If you let it pass by the assertion that the purge shouldn't happen after unlink and run to the end of the test, you'll also see that the number of objects in the data pool does not fall to zero.

this behaviour is expect. When modifying a regular inode with nlink == 1, we create a separate snap inode. If we delete unlink the head inode, it get purged. (snapshotted directory inode does not get purged until all snapshots are removed)

I ran commands in your test manually, number of objects in data pool did go to zero.

#4 Updated by John Spray about 3 years ago

I've pushed an updated test branch which removes the mid-test assertions to avoid confusion.

Not only are the snapshot parts not purged, but there is also a HEAD instance of the file_a 0th object visible at the end of the test.

#5 Updated by Zheng Yan about 3 years ago

the head object is created by Client::check_pool_perm().(we should skip the check for reading snapshot). the reason of old snapshots not get purged is the same as #13777. (mds does not have capability to remove snapshot)

#6 Updated by John Spray about 3 years ago

  • Status changed from New to Resolved

#7 Updated by Greg Farnum over 2 years ago

  • Component(FS) MDS added

Also available in: Atom PDF