Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\,\s+RFC\]\s+Delayed\s+logging\s+of\s+file\s+sizes\s*$/: 28 ]

Total 28 documents matching your query.

1. [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author:
Date: Fri, 23 Nov 2007 18:04:39 +1100
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,
/archives/xfs/2007-11/msg00241.html (14,873 bytes)

2. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author:
Date: Mon, 26 Nov 2007 09:59:28 +1100
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
/archives/xfs/2007-11/msg00260.html (9,212 bytes)

3. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author:
Date: Mon, 26 Nov 2007 11:19:57 +1100
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 -
/archives/xfs/2007-11/msg00263.html (10,234 bytes)

4. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author:
Date: Mon, 26 Nov 2007 12:10:44 +1100
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
/archives/xfs/2007-11/msg00265.html (10,747 bytes)

5. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author:
Date: Mon, 26 Nov 2007 12:29:36 +1100
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
/archives/xfs/2007-11/msg00267.html (11,599 bytes)

6. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author:
Date: Mon, 26 Nov 2007 13:15:15 +1100
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
/archives/xfs/2007-11/msg00269.html (12,478 bytes)

7. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author:
Date: Mon, 26 Nov 2007 14:16:34 +1100
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
/archives/xfs/2007-11/msg00270.html (13,911 bytes)

8. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author:
Date: Mon, 26 Nov 2007 16:03:00 +1100
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
/archives/xfs/2007-11/msg00272.html (14,455 bytes)

9. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author:
Date: Tue, 27 Nov 2007 14:30:25 +1100
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
/archives/xfs/2007-11/msg00276.html (16,488 bytes)

10. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author:
Date: Tue, 27 Nov 2007 21:53:58 +1100
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
/archives/xfs/2007-11/msg00279.html (15,052 bytes)

11. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author:
Date: Wed, 28 Nov 2007 11:43:26 +1100
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
/archives/xfs/2007-11/msg00288.html (18,571 bytes)

12. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author:
Date: Wed, 28 Nov 2007 13:01:36 +1100
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
/archives/xfs/2007-11/msg00289.html (18,950 bytes)

13. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author:
Date: Wed, 28 Nov 2007 15:18:54 +1100
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,
/archives/xfs/2007-11/msg00291.html (22,233 bytes)

14. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author:
Date: Wed, 28 Nov 2007 20:07:37 +1100
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
/archives/xfs/2007-11/msg00292.html (14,075 bytes)

15. [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author: >
Date: Fri, 23 Nov 2007 18:04:39 +1100
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,
/archives/xfs/2007-11/msg00557.html (14,873 bytes)

16. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author: >
Date: Mon, 26 Nov 2007 09:59:28 +1100
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
/archives/xfs/2007-11/msg00576.html (9,212 bytes)

17. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author: >
Date: Mon, 26 Nov 2007 11:19:57 +1100
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 -
/archives/xfs/2007-11/msg00579.html (10,234 bytes)

18. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author: >
Date: Mon, 26 Nov 2007 12:10:44 +1100
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
/archives/xfs/2007-11/msg00581.html (10,747 bytes)

19. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author: >
Date: Mon, 26 Nov 2007 12:29:36 +1100
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
/archives/xfs/2007-11/msg00583.html (11,599 bytes)

20. Re: [PATCH, RFC] Delayed logging of file sizes (score: 1)
Author: >
Date: Mon, 26 Nov 2007 13:15:15 +1100
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
/archives/xfs/2007-11/msg00585.html (12,478 bytes)


This search system is powered by Namazu