sumitagrawl commented on PR #4817: URL: https://github.com/apache/ozone/pull/4817#issuecomment-1590795787
> > > Can we think of triggering quota repair at bucket level in Recon instead of CLI, will be more intuitive and user friendly as well > > > > > > How would OM learn about the repaired values? Right now information flows from OM to Recon, not the other way around. The proposed CLI would be run on each OM host, and would be provided the OM DB to operate on so it can run offline while OM is shut down. > > @errose28 thanks for clarifying, however in future we want to make Recon a tool which can trigger actions other way around as well, so if we can provide om db file path to recon while quota repair, would it make sense and push back the file to OM db file same path after repair ? Am I missing something? @devmadhuu There are below reason where this kind of operation normally is avoided, even from recon, 1. If customer have 1 billion keys, it will take 30 min as per current perf measurement for each bucket. It will lock the bucket for the duration and no write operation will be allowed. 2. This will be debug operation if count goes wrong where it make take this much time 3. If Recon integration is required, may need think another solution then CLI trigger from Recon as part of this. This can be discussed as part of [HDDS-8824](https://issues.apache.org/jira/browse/HDDS-8824) for CLI cases and further support. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
