Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+4\/5\]\s+repair\:\s+don\'t\s+cache\s+large\s+blkmap\s+allocations\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+4\/5\]\s+repair\:\s+don\'t\s+cache\s+large\s+blkmap\s+allocations\s*$/: 7 ]

Total 7 documents matching your query.

1. [PATCH 4/5] repair: don't cache large blkmap allocations (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Mon, 10 Oct 2011 10:11:49 +1100; We currently use thread local storage for storing blkmap allocations from one inode to another as a way of reducing the number of short term allocations we do. However, the stored allocations can onl; /archives/xfs/2011-10/msg00157.html (9,682 bytes)
2. Re: [PATCH 4/5] repair: don't cache large blkmap allocations (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Sun, 9 Oct 2011 19:48:09 -0400; 100k extents still seems like a fairly high number. Otherwise looks okay. (If only we had a non-sucky threaded memory allocator in userspace..); /archives/xfs/2011-10/msg00160.html (9,673 bytes)
3. Re: [PATCH 4/5] repair: don't cache large blkmap allocations (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Mon, 10 Oct 2011 11:14:00 +1100; But not unreasonable for a filesystem full of torrents ;) Perhaps we should look at the talloc code from ccan? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx; /archives/xfs/2011-10/msg00164.html (9,887 bytes)
4. [PATCH 4/5] repair: don't cache large blkmap allocations (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Mon, 10 Oct 2011 12:08:34 +1100; We currently use thread local storage for storing blkmap allocations from one inode to another as a way of reducing the number of short term allocations we do. However, the stored allocations can onl; /archives/xfs/2011-10/msg00173.html (10,240 bytes)
5. Re: [PATCH 4/5] repair: don't cache large blkmap allocations (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Mon, 10 Oct 2011 09:22:33 -0400; I'm just wondering if it's still the right memory / overhead tradeoff at that point. I'm not sure the interface is compatible enough with the kernel style allocator we use in libxfs. Except for that; /archives/xfs/2011-10/msg00187.html (10,147 bytes)
6. Re: [PATCH 4/5] repair: don't cache large blkmap allocations (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Mon, 10 Oct 2011 10:15:43 -0400; Looks reasonable. Reviewed-by: Christoph Hellwig <hch@xxxxxx> Although as said my gut feeling is that the cutoff should be lower. We'd probably need measurements to decide where to go.; /archives/xfs/2011-10/msg00192.html (9,354 bytes)
7. Re: [PATCH 4/5] repair: don't cache large blkmap allocations (score: 1): Author: Alex Elder <aelder@xxxxxxx>; Date: Thu, 13 Oct 2011 04:57:57 -0500; Looks good. Reviewed-by: Alex Elder <aelder@xxxxxxx>; /archives/xfs/2011-10/msg00272.html (10,368 bytes)

Current List: 1 - 7
Page: [1]