keyboardbobo commented on issue #3524: URL: https://github.com/apache/bookkeeper/issues/3524#issuecomment-1282126901
> I can't say anything about data loss, I assume you'd notice that. TBH I doubt that. > > As I said earlier, i'd look into two possibilities: > > 1. xfs prealloc (can be reconfigured if it is a problem) or similar file system magic: shut down the bookie gracefully, don't bring it up. If the disk space released at this point I'd start poking into prealloc configuration. > 2. GC configuration. Major GC is too aggressive, tries to compact entry logs that don't have a lot of space to save (especially without this change [[Issue 3389] Prioritize compaction of entry logs with the lowest amount of remaining usable data #3390](https://github.com/apache/bookkeeper/pull/3390)) with verifyMetadataOnGC=false - it rewrites entry log with ledgers that deleted already but were live when GC started. When you restart the bookie it re-reads ledgers data and lots of entry logs can be deleted without having to go through the compaction, this releases a lot of space quickly. > > in the second case I'd try verifyMetadataOnGC=true (a bit more requests to ZK during compaction), set minorCompactionMaxTimeMillis to 30-60min, majorCompactionMaxTimeMillis to an e.g. 2x of that, cherry-pick PR I mentioned above into the build you are running (if you can). Thanks for your suggestion, I'll give it a try @dlg99 -- 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]
