On Thu, Oct 31, 2019 at 07:36:40AM -0400, Brian Foster wrote: > Dropped linux-fsdevel from cc. There's no reason to spam -fsdevel with > low level XFS patches. > > On Wed, Oct 30, 2019 at 09:37:11PM +0800, Pingfan Liu wrote: [...] > > I'm not following how this is possible. The CIL push above, under It turns out not to be a bug as I replied to Dave's mail in this thread. > exclusive lock, removes each log item from ->xc_cil and pulls the log > vectors off of the log items to form the lv chain on the CIL context. > This means that the transB commit either updates the lv attached to the > log item from transA with the latest in-core version or uses the new > shadow buffer allocated in the commit path of transB. Either way is fine > because there is no guarantee of per-transaction granularity in the Yes, no guarantee of per-transaction granularity, but there is a boundary placed on several effect-merged transactions. That is what xc_ctx_lock and private chain ctx->lv_chain guarantee. > on-disk log. The purpose of the on-disk log is to guarantee filesystem > consistency after a crash. > > All in all, I can't really tell what problem you're describing here. If > you believe there's an issue in this code, I'd suggest to either try and > instrument it manually to reproduce a demonstrable problem and/or > provide far more detailed of a description to explain it. > Sorry that I raise a false alarm. But thank you all for helping me to figure out through this. Regards, Pingfan
