OpenSolaris

Printable Version Enter a New Search
Bug ID 6765294
Synopsis Refactor replay
State 10-Fix Delivered (Fix available in build)
Category:Subcategory kernel:zfs
Keywords
Responsible Engineer Neil Perrin
Reported Against
Duplicate Of
Introduced In solaris_nevada
Commit to Fix snv_105
Fixed In snv_105
Release Fixed solaris_nevada(snv_105) , solaris_10u8(s10u8_01) (Bug ID:2176236)
Related Bugs 6798298
Submit Date 29-October-2008
Last Update Date 17-December-2008
Description
After 2 recent bugs (6736324 & 6761624) relating to ZIL replay
we thought: there must be a better way.

The problems come about because the ZIL holds a transaction
open around the call to replay the transaction. Nested transactions
are allowed but the embedded transaction is restricted to not starting
more than 2 txgs past the replay transaction. So the environment
for replay is not identical to normal non-replay transactions.
Some recent changes to remove/truncate files fell over this
restriction.

The only reason we create an replay transaction is to ensure we
replay the transaction and mark the fact that we've replayed it
atomically. Mark suggested that we remove the replay tx and increment the
log header sequence number (which marks the replay done) within the  
function that normally creates the replay record (e.g. zfs_log_link()).

This takes a little bit of re-aranging but in general cleans up the
code considerably - a net deletion of code. We can remove
the two kludgy fixes for 6736324 & 6761624, plus steamline the 
replay record call code. It also means we remove the strangeness where the
replay function is called twice - once with a bad txg number
to assign just to test it fails under this situation.
Any interaction between this CR and 6730441 (which the encrypted ZIL depends on).
Work Around
N/A
Comments
N/A