In Question $12,$ if we write new data to a newly$-$allocated data block data$[0],$ you need to write the inode $($I$),$ bitmap $($B$),$ and data block $($D$)$ to the disk $($If your answer misses any of them, you'd better go back to double check it$).$ If the system crashes during this process, it might result in data inconsistency. Data journaling could be used to resolve this issue: Before writing them to their final disk locations, we first write them to the journal like this: $($TxBegin$|$I$|$B$|$D$|$TxEnd$),$ where TxBegin and TxEnd are associated with a transaction ID$.$ Here are the detailed steps:

$-$ Journal write: Write the contents of the transaction $($TxBegin$|$I$|$B$|$D$)$ to the log; wait for writes to complete;

$-$ Journal commit: Write the transaction commit block $($TxEnd$)$ to the log; wait for writes to complete;

$-$ Checkpoint: Write the contents of $($I$|$B$|$D$)$ to the final locations; wait for writes to complete;

$-$ Free: Mark the transaction free in the journal.

Answer the following questions:

$1.$ During the step of checkpoint, there is a system crash in the middle of all updates. How does the journaling technique handle such crash to achieve data consistency?

$2.$ Journaling could add a lot of extra disk traffic such as double writings of I, B and D$.$ With metadata journaling, we can write D to the final locations first and then skip writing it into the journal. Explain why we could use this approach on D$,$ but not on I or B$.$

$3.$ We create two files in a row: $/$Prog$/$P$1.$pdf and $/$Prog$/$P$2.$pdf$.$ For P$1.$pdf$,$ even with metadata journaling, we need to commit metadata writes to the journal location, and all writes to the final location. Then for P$2.$pdf we performed the same two steps. We end up jumping between the journal location and the final destination location in completing these writes. Propose a solution to reduce such traveling cost without a need of a new hardware support.