xfs
[Top] [All Lists]

Re: [PATCH 15/71] xfs: create refcount update intent log items

To: "Darrick J. Wong" <darrick.wong@xxxxxxxxxx>
Subject: Re: [PATCH 15/71] xfs: create refcount update intent log items
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 6 Sep 2016 10:03:19 -0700
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, david@xxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20160906164341.GD16696@xxxxxxxxxxxxxxxx>
References: <147216791538.867.12413509832420924168.stgit@xxxxxxxxxxxxxxxx> <147216801436.867.13017543869659604138.stgit@xxxxxxxxxxxxxxxx> <20160906151603.GI24287@xxxxxxxxxxxxx> <20160906164341.GD16696@xxxxxxxxxxxxxxxx>
User-agent: Mutt/1.6.1 (2016-04-27)
On Tue, Sep 06, 2016 at 09:43:41AM -0700, Darrick J. Wong wrote:
> <shrug> I'm relatively indifferent either way, though I noticed that
> EFIs have a separate copy_format function in xfs_extfree_item.c which
> reduces the amount of clutter in xfs_log_recover.c.  It seemed more
> neat to keep all the log item functions corralled within a separate
> file rather than putting them in xfs_log_recover.c, so I maintained
> that pattern for the rui/cui/bui items.

The big difference with the EFI is that we had packing problems with
them so we might have to do a few different conversions.

> In a semi-related side note I've been toying with turning on LTO in
> xfsprogs to see how much it shrinks all the XFS code.  Code size goes
> down considerably (repair shrinks by nearly 1MB!) but wow the
> resulting tangle can be a PITA to debug.  :(

Yes. LTO is a nightmare for debugging.

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