From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 0/7] decouple the in-memory from the on-disk log format
Date: Mon, 25 Nov 2013 19:54:15 +1100 [thread overview]
Message-ID: <20131125085415.GC8803@dastard> (raw)
In-Reply-To: <20131123151151.716201348@bombadil.infradead.org>
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...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-11-25 8:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-23 15:11 [PATCH 0/7] decouple the in-memory from the on-disk log format Christoph Hellwig
2013-11-23 15:11 ` [PATCH 1/7] xfs: let iop_format write directly into the linear buffer Christoph Hellwig
2013-11-25 9:15 ` Dave Chinner
2013-11-25 13:37 ` Christoph Hellwig
2013-11-25 20:45 ` Dave Chinner
2013-11-26 6:02 ` Christoph Hellwig
2013-11-23 15:11 ` [PATCH 2/7] xfs: remove the inode log format from the inode log item Christoph Hellwig
2013-11-23 15:11 ` [PATCH 3/7] xfs: remove the dquot log format from the dquot " Christoph Hellwig
2013-11-23 15:11 ` [PATCH 4/7] xfs: remove the quotaoff log format from the quotaoff " Christoph Hellwig
2013-11-23 15:11 ` [PATCH 5/7] xfs: defer EFI and EFD log formatting until iop_format time Christoph Hellwig
2013-11-24 9:18 ` Christoph Hellwig
2013-11-25 8:50 ` Dave Chinner
2013-11-25 13:40 ` Christoph Hellwig
2013-11-23 15:11 ` [PATCH 6/7] xfs: remove efi_next_extent Christoph Hellwig
2013-11-23 15:11 ` [PATCH 7/7] xfs: remove opencoded versions of xfs_bmap_cancel Christoph Hellwig
2013-11-25 8:54 ` Dave Chinner [this message]
2013-11-25 13:35 ` [PATCH 0/7] decouple the in-memory from the on-disk log format Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131125085415.GC8803@dastard \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox