Feature #56643
open
scrub: add one subcommand or option to add the missing objects back
Added by Xiubo Li almost 2 years ago.
Updated over 1 year ago.
Description
When we are scrub repairing the metadatas and some objects may get lost due to some reasons. After the repair finished, we can mount the clients and access to those damaged directories normally. And those lost objects will also could be added back when writing to the damaged directories later automatically by MDS.
But the MDS will report damaged health errors to monitor later.
Should we add one option or subcommand to repair the lost objects by force adding them ?
Xiubo Li wrote:
When we are scrub repairing the metadatas and some objects may get lost due to some reasons. After the repair finished, we can mount the clients and access to those damaged directories normally. And those lost objects will also could be added back when writing to the damaged directories later automatically by MDS.
But the MDS will report damaged health errors to monitor later.
Do you mean to allow I/O operations on damaged inodes?
Venky Shankar wrote:
Xiubo Li wrote:
When we are scrub repairing the metadatas and some objects may get lost due to some reasons. After the repair finished, we can mount the clients and access to those damaged directories normally. And those lost objects will also could be added back when writing to the damaged directories later automatically by MDS.
But the MDS will report damaged health errors to monitor later.
Do you mean to allow I/O operations on damaged inodes?
The damaged inodes may have lost some objects in the metadata pool, and for these damaged inodes if we create new dentries under them those objects will be created back but will report damaged health errors during that.
I mean could we add a subcommand to trigger to add them back manually to avoid the MDS to report health errors ?
Xiubo Li wrote:
Venky Shankar wrote:
Xiubo Li wrote:
When we are scrub repairing the metadatas and some objects may get lost due to some reasons. After the repair finished, we can mount the clients and access to those damaged directories normally. And those lost objects will also could be added back when writing to the damaged directories later automatically by MDS.
But the MDS will report damaged health errors to monitor later.
Do you mean to allow I/O operations on damaged inodes?
The damaged inodes may have lost some objects in the metadata pool, and for these damaged inodes if we create new dentries under them those objects will be created back but will report damaged health errors during that.
I mean could we add a subcommand to trigger to add them back manually to avoid the MDS to report health errors ?
OK, You mean to introduce a way to create these objects on-demand instead of forcefully creating dentries by creating files?
Venky Shankar wrote:
Xiubo Li wrote:
Venky Shankar wrote:
Xiubo Li wrote:
When we are scrub repairing the metadatas and some objects may get lost due to some reasons. After the repair finished, we can mount the clients and access to those damaged directories normally. And those lost objects will also could be added back when writing to the damaged directories later automatically by MDS.
But the MDS will report damaged health errors to monitor later.
Do you mean to allow I/O operations on damaged inodes?
The damaged inodes may have lost some objects in the metadata pool, and for these damaged inodes if we create new dentries under them those objects will be created back but will report damaged health errors during that.
I mean could we add a subcommand to trigger to add them back manually to avoid the MDS to report health errors ?
OK, You mean to introduce a way to create these objects on-demand instead of forcefully creating dentries by creating files?
Yeah, right!
Also available in: Atom
PDF