Here's a patch for an idea to address an issue we have with log replay. The problem stems from the fact that not all changes to inodes result in transactions. Some changes (such as file size updates,
The problem with this is that the inode will be marked dirty during the transaction, so we'll never be able to clean an inode if we issue a transaction during inode writeback. Cheers, Dave. -- Dave C
David Chinner wrote: On Fri, Nov 23, 2007 at 06:04:39PM +1100, Lachlan McIlroy wrote: The easy solution is to log everything so that log replay doesn't need to check if the on-disk version is newer -
Wouldn't have made aany difference - the inode woul dbe marked dirty at transaction completion... I wouldn't worry too much about this problem right now - I'm working on moving the dirty state into t
David Chinner wrote: On Mon, Nov 26, 2007 at 11:19:57AM +1100, Lachlan McIlroy wrote: David Chinner wrote: On Fri, Nov 23, 2007 at 06:04:39PM +1100, Lachlan McIlroy wrote: The easy solution is to log
Trying to change XFS to logging all updates. Better inode writeback clustering. i.e. it's easy to find all the dirty inodes and then we can write them in larger contiguous chunks. The first "hack" at
David Chinner wrote: On Mon, Nov 26, 2007 at 12:29:36PM +1100, Lachlan McIlroy wrote: David Chinner wrote: On Mon, Nov 26, 2007 at 11:19:57AM +1100, Lachlan McIlroy wrote: David Chinner wrote: On Fri
Sorry, i wasn't particularly clear. What I mean was that i_update_core might disappear completely with the changes I'm making. Basically, we have three different methods of marking the inode dirty at
David Chinner wrote: On Mon, Nov 26, 2007 at 02:16:34PM +1100, Lachlan McIlroy wrote: David Chinner wrote: On Mon, Nov 26, 2007 at 12:29:36PM +1100, Lachlan McIlroy wrote: David Chinner wrote: On Mon
Maybe. Maybe not. Tell me - does xfs_ichgtime() do the right thing? [ I do know the answer to this question and there's a day of kdb tracing behind the answer. I wrote a 15 line comment to explain wh
David Chinner wrote: On Tue, Nov 27, 2007 at 02:30:25PM +1100, Lachlan McIlroy wrote: David Chinner wrote: Sorry, i wasn't particularly clear. What I mean was that i_update_core might disappear compl
Yup. When allocating a new inode, we mark the inode dirty when first setting the timestamps in xfs_dir_ialloc(). At the time this happens the inode is I_LOCK|I_NEW and hence mark_inode_dirty_sync() w
David Chinner wrote: On Wed, Nov 28, 2007 at 11:43:26AM +1100, Lachlan McIlroy wrote: David Chinner wrote: On Tue, Nov 27, 2007 at 02:30:25PM +1100, Lachlan McIlroy wrote: David Chinner wrote: Sorry,
No - removing the check is what lead me to understand why it was necessary. But we don't do that right now - we call xfs_ipinwait() in xfs_iflush() which forces the log. It's messy, and if we are log
Here's a patch for an idea to address an issue we have with log replay. The problem stems from the fact that not all changes to inodes result in transactions. Some changes (such as file size updates,
The problem with this is that the inode will be marked dirty during the transaction, so we'll never be able to clean an inode if we issue a transaction during inode writeback. Cheers, Dave. -- Dave C
David Chinner wrote: On Fri, Nov 23, 2007 at 06:04:39PM +1100, Lachlan McIlroy wrote: The easy solution is to log everything so that log replay doesn't need to check if the on-disk version is newer -
Wouldn't have made aany difference - the inode woul dbe marked dirty at transaction completion... I wouldn't worry too much about this problem right now - I'm working on moving the dirty state into t
David Chinner wrote: On Mon, Nov 26, 2007 at 11:19:57AM +1100, Lachlan McIlroy wrote: David Chinner wrote: On Fri, Nov 23, 2007 at 06:04:39PM +1100, Lachlan McIlroy wrote: The easy solution is to log
Trying to change XFS to logging all updates. Better inode writeback clustering. i.e. it's easy to find all the dirty inodes and then we can write them in larger contiguous chunks. The first "hack" at