On Mon, Sep 30, 2019 at 04:27:25PM -0400, Josef Bacik wrote: > We've historically had reports of being unable to mount file systems > because the tree log root couldn't be read. Usually this is the "parent > transid failure", but could be any of the related errors, including > "fsid mismatch" or "bad tree block", depending on which block got > allocated. > > The modification of the individual log root items are serialized on the > per-log root root_mutex. This means that any modification to the > per-subvol log root_item is completely protected. > > However we update the root item in the log root tree outside of the log > root tree log_mutex. We do this in order to allow multiple subvolumes > to be updated in each log transaction. > > This is problematic however because when we are writing the log root > tree out we update the super block with the _current_ log root node > information. Since these two operations happen independently of each > other, you can end up updating the log root tree in between writing out > the dirty blocks and setting the super block to point at the current > root. > > This means we'll point at the new root node that hasn't been written > out, instead of the one we should be pointing at. Thus whatever garbage > or old block we end up pointing at complains when we mount the file > system later and try to replay the log. > > Fix this by copying the log's root item into a local root item copy. > Then once we're safely under the log_root_tree->log_mutex we update the > root item in the log_root_tree. This way we do not modify the > log_root_tree while we're committing it, fixing the problem. > > cc: stable@xxxxxxxxxxxxxxx > Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx> > Reviewed-by: Chris Mason <clm@xxxxxx> Added to 5.4 queue, thanks.
