[Top] [All Lists]

Re: [PATCH 0/7] decouple the in-memory from the on-disk log format

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 0/7] decouple the in-memory from the on-disk log format
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 25 Nov 2013 19:54:15 +1100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20131123151151.716201348@xxxxxxxxxxxxxxxxxxxxxx>
References: <20131123151151.716201348@xxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Sat, Nov 23, 2013 at 07:11:51AM -0800, Christoph Hellwig wrote:
> Since the introduction of the CIL we already have a layer of indirection
> between the physical log format and the data structure tracking the
> changes in memory.  But due to the way iop_format works we are still
> forced to keep a copy of everything that goes out to the log in memory
> even before copying it into the CIL.
> The first patch in this series changes iop_format so that the log items
> are free to store their in-memory data however they want before formatting
> them into the CIL, and the other patches take advantage of that by not
> keeping most log formats in memory all the time.  Especially the EFI and
> EFD related ones at the end start to show the benefit.

OK, it makes sense from that perspective - it should reduce the
memory footprint and simplify the code, if nothing else...

> What's missing from this series are larger changes to the in-core inode
> layout.  No needing the full struct icdinode at all times will be the
> biggest benefit of this change, but it will be large enough series of it's
> own.

Can you give us an outline of where you are taking this code and
what problems you are trying to solve? I'm missing the big picture
view that is driving this work - I think I know where you are going
to take it (i.e. closer integration with the vfs struct inode to
remove a bunch of duplicate information), but I'd like to know for
sure where this is going before looking at the code in real depth...


Dave Chinner

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