Actions
Bug #22292
openmds: scrub may mark repaired directory with lost dentries and not flush backtrace
Status:
New
Priority:
High
Assignee:
-
Category:
fsck/damage handling
Target version:
-
% Done:
0%
Source:
Development
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
MDS, qa-suite
Labels (FS):
qa, scrub
Pull request ID:
Crash signature (v1):
Crash signature (v2):
Description
Simple reproducer (with selected output):
$ ../src/vstart.sh -d -b -l -n $ # mount at ./mnt $ cp -a /usr mnt ^C $ bin/ceph daemon mds.c flush journal $ bin/rados --pool=cephfs_metadata_a listomapkeys 1000000001c.00000000 site-functions_head $ bin/rados --pool=cephfs_metadata_a getxattr 1000000001c.00000000 parent � zsh]shareWlocaluusr+ $ bin/rados --pool=cephfs_metadata_a getxattr 1000000001d.00000000 parent �"site-functions zsh]shareWlocaluusr+ $ bin/rados --pool=cephfs_metadata_a rm 1000000001c.00000000 $ bin/ceph daemon mds.b scrub_path / recursive force repair $ grep -B2 'scrub complete' < out/mds.b.log 2017-11-30 18:11:42.798 7fe62a268700 10 log_client logged 2017-11-30 18:11:37.052016 mds.b mds.0 127.0.0.1:6839/1510709700 1 : cluster [WRN] bad backtrace on inode 0x1000000001c(/usr/local/share/zsh), rewriting it 2017-11-30 18:11:42.798 7fe62a268700 10 log_client logged 2017-11-30 18:11:37.052050 mds.b mds.0 127.0.0.1:6839/1510709700 2 : cluster [INF] Scrub repaired inode 0x1000000001c (/usr/local/share/zsh) 2017-11-30 18:11:42.798 7fe62a268700 10 log_client logged 2017-11-30 18:11:37.346361 mds.b mds.0 127.0.0.1:6839/1510709700 3 : cluster [INF] scrub complete $ bin/rados --pool=cephfs_metadata_a getxattr 1000000001c.00000000 parent # ???? I thought scrub would flush the backtrace? $ bin/ceph daemon mds.b flush journal $ bin/rados --pool=cephfs_metadata_a getxattr 1000000001c.00000000 parent � zsh]sharellocal�usr:pdo $ bin/rados --pool=cephfs_metadata_a listomapkeys 1000000001c.00000000 $
so "site-functions" dentry is lost but the directory is considered repaired.
Actions