sijie commented on issue #1283: Issue #1282: call to appendLedgersMap in flushCompactionLog URL: https://github.com/apache/bookkeeper/pull/1283#issuecomment-376622093 @reddycharan > I'm not sure what you meant by "What if we flush the log channel successfully but not the ledger map?". In which case can it happen? Are you saying that this scenario is not handled completely? so @yzang was asking if the flush ordering at line 494 ``` // flush the internal buffer back to filesystem but not sync disk // so the readers could access the data from filesystem. logChannel.flush(); logChannel.flush(); // Append ledgers map at the end of entry log appendLedgersMap(logChannel); ``` @yzang : the `flush` here is writing all the buffer data back to filesystem. it is *NOT* flushing to disk. so the order at line 494 is correct: we write the buffer back to filesystem and append the ledger map after that. then checkpoint logic will fsync the entry log file (via flushAndForceWrite) (which happens at flushCurrentLog and flushRotatedLogs). > Also shall we move line 494 to before line 841 instead? It makes more sense to append the ledger map in flush function than when creating a new log? @yzang `flushRotatedLogs` only happens when checkpointing happen. The reason we put `appendLedgerMap()` at line 494 instead of before line 841 is a performance consideration. you can append ledger map into filesystem without fsync, so between you append ledger map and the real checkpoint happen, filesystem might already 'pdflush' the dirty pages back to disk. when the real fsync happen, there is no blocking I/O happening. @reddycharan @yzang hope this clarify the questions.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
