On Mon, Nov 25, 2013 at 07:54:15PM +1100, Dave Chinner wrote:
> 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...
There's no problem per se, it's just the requiring the in-memory copy
of the logged data is hugely inefficient. We already see that with the
three patches dropping the trivial log format, and it will be even
bigger for the inode. Basically the next step is to get rid of
struct icdinode - the structure will still exist sa struct xfs_log_inode
or similar, but only inside the log item. The other fields will get
merged into struct xfs_inode. Most of them will then go away in favour
of using exist VFS inode fields or moving into struct xfs_ifork so
that a lot of data vs attribute fork special casing can go away.