Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[Patch\]\s+unique\s+per\-AG\s+inode\s+generation\s+number\s+initialisation\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[Patch\]\s+unique\s+per\-AG\s+inode\s+generation\s+number\s+initialisation\s*$/: 18 ]

Total 18 documents matching your query.

1. [Patch] unique per-AG inode generation number initialisation (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Wed, 2 Apr 2008 09:18:15 +1000; Don't initialise new inode generation numbers to zero When we allocation new inode chunks, we initialise the generation numbers to zero. This works fine until we delete a chunk and then reallocate it; /archives/xfs/2008-04/msg00012.html (13,606 bytes)
2. Re: [Patch] unique per-AG inode generation number initialisation (score: 1): Author: Niv Sardi <xaiki@xxxxxxxxxxxxx>; Date: Wed, 02 Apr 2008 15:02:42 +1100; <HAT type=DMAPI> Appart from the bit of overhead all seems good. -- Niv Sardi; /archives/xfs/2008-04/msg00017.html (15,937 bytes)
3. Re: [Patch] unique per-AG inode generation number initialisation (score: 1): Author: Hans-Peter Jansen <hpj@xxxxxxxxx>; Date: Fri, 4 Apr 2008 11:08:42 +0200; Dear David, Am Mittwoch, 2. April 2008 schrieb David Chinner: Is this patch ready for production systems? Did it went through QA already? If it's ready, shouldn't it go to the Linux stable team then,; /archives/xfs/2008-04/msg00086.html (16,038 bytes)
4. n in forced unmount (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Mon, 7 Apr 2008 08:57:38 -0400; here. Could probably be a separate patch. Otherwise this looks fine.; /archives/xfs/2008-04/msg00106.html (8,306 bytes)
5. vent disk spindown? (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Tue, 8 Apr 2008 07:52:03 +1000; logprint produces output like the one shown below, so it does indeed look like it's writing to the journal. But why should it need to keep writing to the journal when there have been no updates t; /archives/xfs/2008-04/msg00109.html (10,529 bytes)
6. redirection in 091 (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Thu, 10 Apr 2008 14:34:32 +1000; d Chinner wrote: Fix the filtering of xfsinfo by punting stdout to /dev/null. Signed-off-by: Dave Chinner <dgc@xxxxxxx> -- xfstests/091 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index:; /archives/xfs/2008-04/msg00216.html (11,456 bytes)
7. : [Patch] Per iclog callback chain lock (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Wed, 2 Apr 2008 09:18:15 +1000; ce an iclog callback chain lock. Rather than use the icloglock for protecting the iclog completion callback chain, use a new per-iclog lock so that walking the callback chain doesn't require h; /archives/xfs/2008-04/msg00608.html (13,606 bytes)
8. rove XFS error checking and propagation (score: 1): Author: Niv Sardi <xaiki@xxxxxxxxxxxxx>; Date: Wed, 02 Apr 2008 15:02:42 +1100; hinner wrote: On Mon, Mar 31, 2008 at 03:45:28PM -0700, Michael Nishimoto wrote: The comment for XFS_DQUOT_LOGRES states that we need to reserve space for 3 dquots. I can't figure out why we n; /archives/xfs/2008-04/msg00613.html (15,937 bytes)
9. og_t (score: 1): Author: Hans-Peter Jansen <hpj@xxxxxxxxx>; Date: Fri, 4 Apr 2008 11:08:42 +0200; leen wrote: On Thu, Apr 03, 2008 at 08:23:47AM +1000, David Chinner wrote: For the dynamic allocation you would rather need to make sure it starts at a cache line boundary explicitely because t; /archives/xfs/2008-04/msg00682.html (16,038 bytes)
10. chain lock (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Mon, 7 Apr 2008 08:57:38 -0400; /target' to `SCRATCH_MNT/nosymlink/source': Operation not permitted -- not sure where the double to comes f; /archives/xfs/2008-04/msg00702.html (8,306 bytes)
11. d Linux kernel 2.6.24.4 (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Tue, 8 Apr 2008 07:52:03 +1000; eally like this. The chance to hit a previously used generation seems to high. What about making the first few bits of each generation number a per-ag counter that's incremented anytime we d; /archives/xfs/2008-04/msg00705.html (10,529 bytes)
12. direction in 091 (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Thu, 10 Apr 2008 14:34:32 +1000; tering of xfsinfo by punting stdout to /dev/null. Signed-off-by: Dave Chinner <dgc@xxxxxxx> -- xfstests/091 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: xfs-cmds/xfstests/09; /archives/xfs/2008-04/msg00812.html (11,456 bytes)
13. [Patch] unique per-AG inode generation number initialisation (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Wed, 2 Apr 2008 09:18:15 +1000; Don't initialise new inode generation numbers to zero When we allocation new inode chunks, we initialise the generation numbers to zero. This works fine until we delete a chunk and then reallocate it; /archives/xfs/2008-04/msg01204.html (13,606 bytes)
14. Re: [Patch] unique per-AG inode generation number initialisation (score: 1): Author: Niv Sardi <xaiki@xxxxxxxxxxxxx>; Date: Wed, 02 Apr 2008 15:02:42 +1100; <HAT type=DMAPI> Appart from the bit of overhead all seems good. -- Niv Sardi; /archives/xfs/2008-04/msg01209.html (16,005 bytes)
15. Re: [Patch] unique per-AG inode generation number initialisation (score: 1): Author: Hans-Peter Jansen <hpj@xxxxxxxxx>; Date: Fri, 4 Apr 2008 11:08:42 +0200; Dear David, Am Mittwoch, 2. April 2008 schrieb David Chinner: Is this patch ready for production systems? Did it went through QA already? If it's ready, shouldn't it go to the Linux stable team then,; /archives/xfs/2008-04/msg01278.html (16,106 bytes)
16. Re: [Patch] unique per-AG inode generation number initialisation (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Mon, 7 Apr 2008 08:57:38 -0400; I don't really like this. The chance to hit a previously used generation seems to high. What about making the first few bits of each generation number a per-ag counter that's incremented anytime we d; /archives/xfs/2008-04/msg01298.html (8,374 bytes)
17. Re: [Patch] unique per-AG inode generation number initialisation (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Tue, 8 Apr 2008 07:52:03 +1000; The chance to hit an existing generation number is almost non-existant. The counter is incremented on every allocation and not just when inode chunks are allocated on disk. Hence a series of "allocat; /archives/xfs/2008-04/msg01301.html (10,623 bytes)
18. Re: [Patch] unique per-AG inode generation number initialisation (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Thu, 10 Apr 2008 14:34:32 +1000; Ping? Any further concerns on this? I'd like to get this resolved quickly..... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group; /archives/xfs/2008-04/msg01408.html (11,588 bytes)

Current List: 1 - 18
Page: [1]