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. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
