Feature #18509: MDS: damage reporting by ino number is useless - CephFS - Ceph

Actions

Copy link

Feature #18509

closed

MDS: damage reporting by ino number is useless

Added by Greg Farnum over 7 years ago. Updated over 6 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

Category:

fsck/damage handling

Target version:

% Done:

Source:

Tags:

Backport:

jewel, kraken

Reviewed:

Affected Versions:

Component(FS):

MDS

Labels (FS):

Pull request ID:

Description

We had two damaged directories on the long-running cluster, but examining the directories in question (other than through raw RADOS) is pretty difficult.

[{"damage_type":"dir_frag","id":106068496,"ino":1099586093270,"frag":"*"},{"damage_type":"dir_frag","id":2243167668,"ino":1099586138404,"frag":"*"}]

When we generate a damage report a little more info is sent to clog, but we can't find any entries and think it was so long ago the files have been logrotated into nothingness.

In a reasonably healthy cluster one could also look at the raw RADOS objects, but assuming I've done the name translation correctly, we actually have lost these objects!

Related issues 2 (0 open — 2 closed)

Actions

Copy link

Updated by John Spray over 7 years ago

The log message reporting the path is still there:

/var/log/ceph/ceph.log.3.gz:2017-01-10 04:29:24.415773 mds.0 172.21.5.114:6816/1992312860 363 : cluster [ERR] dir 100047040d6 object missing on disk; some files may be lost (/teuthology-archive/teuthology-2014-10-18_19:33:01-upgrade:dumpling-firefly-x:stress-split-giant-distro-basic-multi)

Not that it wouldn't still be reasonable to add an informational field to the damage entries, shall we just make it a path string or can we think of other advisory metadata that might be useful?

Actions

Copy link