| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: xfs_iext_realloc_indirect and "XFS: possible memory allocation deadlock", Dave Chinner |
|---|---|
| Next by Date: | Re: [PATCH 08/17] mkfs: getbool is redundant, Dave Chinner |
| Previous by Thread: | Re: [PATCH] xfs: remote attribute headers contain an invalid LSN, Brian Foster |
| Next by Thread: | re:re:108pcs 3w led moving head light price, led prolight |
| Indexes: | [Date] [Thread] [Top] [All Lists] |