tools/cephfs: add scan_links command which fixes linkages errors #11446
Conversation
ukernel
force-pushed
the
wip-cephfs-scan-links
branch
from
e6837e4
to
e0a1012
Compare
ukernel
changed the title
ukernel
force-pushed
the
wip-cephfs-scan-links
branch
2 times, most recently
from
49bffd6
to
186c772
Compare
There was a problem hiding this comment.
Okay, so at a high level this:
- iterates through all metadata objects and creates an in-memory map of ino numbers in use.
- iterates through all metadata objects a second time and compares them to the in-memory map.
- Keeps enough data around to delete "bad" copies (either from un-reintegrated stray entries or incompletely-split/merged dirfrags) and write the inode into the "good" location.
But if we think we can hold it all in-memory, why do we need two disk passes?
Is there a situation in which we expect to need this tool? I know you wrote it in response to a user getting a bunch of un-reintegrated strays, but in that case it was the result of specific behavior patterns and it seems like you'd want to fix it more precisely. (eg, being able to scan a single directory and compare against the stray dir.)
I just don't quite get the usage model where this makes sense.
| @@ -34,6 +34,7 @@ void DataScan::usage() | |||
| << " cephfs-data-scan scan_extents [--force-pool] <data pool name>\n" | |||
| << " cephfs-data-scan scan_inodes [--force-pool] [--force-corrupt] <data pool name>\n" | |||
| << "\n" | |||
| << " cephfs-data-scan scan_links\n" | |||
There was a problem hiding this comment.
This should be prior the extra new-line.
| } | ||
|
|
||
| if (!valid_ino(dir_ino)) { | ||
| dout(10) << "Not a difrag (invalid ino): '" << oid << "'" << dendl; |
|
Two passes design is for reduce memory usage. Scan metadata pool is fast in most case. This tool is for repair linkage errors, such as incorrect inode link count, duplicated primary dentries. (Similar to pass 3/4 of fsck.ext4 -fv /dev/xxx) The online scrub can't fix this type of error easily. |
ukernel
force-pushed
the
wip-cephfs-scan-links
branch
from
186c772
to
a94a0e9
Compare
|
I don't know what 'scan a single directory and compare against the stray dir' can do? find bad remote link,force stray reintegration? both can be done easily by scrub |
|
You were suggesting this on the mailing list as a solution for reintegrating strays into their new locations, and I'm not sure this is a very efficient way of doing that. The other cases aren't very likely but are definitely worth being able to repair. Please write some tests demonstrating this works. |
|
Also I'm really not thrilled about the in-memory map of all inodes; that's going to put some serious limits on scalability. But it will do for getting on with (although we should also add a tracker ticket about it). |
|
On Wed, Oct 19, 2016 at 1:05 PM, Gregory Farnum notifications@github.com
No, I didn't suggest the user to use this tool for reintegrating strays.
|
|
@ukernel, I will merge this when you add tests. I don't see any. :) |
Signed-off-by: Yan, Zheng <zyan@redhat.com>
ukernel
force-pushed
the
wip-cephfs-scan-links
branch
from
a94a0e9
to
9e3471c
Compare
|
Test case fixed (only tested by vstart runner) |
Signed-off-by: Yan, Zheng zyan@redhat.com