Hi Sage, Neha,
I agree that we should use bluestore.
(All customers will eventually migrate from filestore to bluestore.)
However, there is a problem that the migration takes time.
Currently my customer runs their system on hundreds of disks, and they cannot shut down the system.
So they need to carefully plan their migration and migrate only a few disks in a single migration.
Probably it will take more than a year to complete the migration of all the disks.
Therefore, I think it is necessary to consider code fixes or operational workarounds for the problems that are detected so that data loss does not occur again by the time the migration is complete. (I understand we should use bluestore, but I think there is still a need to maintain filestore for users who take a long time to migrate.)
Does such an idea make sense?
For example, I would like to consider the following ideas in detail.
1: In case of operational workarounds
We can scrub manually before osd in/out. However, this is an incomplete workaround, as it cannot be address if an automatic backfill occurs in the background.
2: In case of modifying the code.
There is no problem with `recovery`. So is it possible to adopt a part of mechanism of `recovery` into `backfill`? (We need to investigate the code in detail.)
I'm very happy If you have some idea to solve it.
Jin
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
