xfs
[Top] [All Lists]

Re: [PATCH] xfs: remote attribute headers contain an invalid LSN

To: Brian Foster <bfoster@xxxxxxxxxx>
Subject: Re: [PATCH] xfs: remote attribute headers contain an invalid LSN
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 30 Jun 2015 09:11:40 +1000
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150625124643.GA36162@xxxxxxxxxxxxxxx>
References: <1434948369-13931-1-git-send-email-david@xxxxxxxxxxxxx> <20150624131228.GC1888@xxxxxxxxxxxxxxx> <20150624212643.GJ22807@dastard> <20150625124643.GA36162@xxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Jun 25, 2015 at 08:46:44AM -0400, Brian Foster wrote:
> So as noted above, were this treated as a typical metadata block, the
> corresponding buffer would be logged and thus everything would be
> ordered appropriately with respect to the log. It is not a logged buffer
> in this case, so we drop XFS_BMAPI_METADATA flag from the allocation
> which would cause any previous frees of this block to be flushed to the
> ail.

Yes.

> I don't see anything explicit that "handles" the case of being written
> before the allocation transaction is committed. By "handles," do you
> simply mean the aforementioned log force? In other words, we're
> implicitly saying it's fine that the block is written out of order from
> the allocation, so long as the block is marked free on-disk.

Yes and yes.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>