Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+xfs

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+xfs_repair\:\s+multithread\s+phase\s+2\s*$/: 13 ]

Total 13 documents matching your query.

1. [PATCH] xfs_repair: multithread phase 2 (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Tue, 4 Jan 2011 17:13:08 +1100; Running some recent repair tests on broken filesystem meant running phase 1 and 2 repeatedly to reproduce an issue at the start of phase 3. Phase 2 was taking approximately 10 minutes to run as it pr; /archives/xfs/2011-01/msg00027.html (28,453 bytes)
2. Re: [PATCH] xfs_repair: multithread phase 2 (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Tue, 4 Jan 2011 05:02:40 -0500; Shouldn't we have at least an option to allow tuning this value, similar to the ag_stride? In fact I wonder why phase 3/4 should use different values for it than phase2. Please make this a void *pri; /archives/xfs/2011-01/msg00032.html (10,557 bytes)
3. Re: [PATCH] xfs_repair: multithread phase 2 (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Tue, 4 Jan 2011 23:00:49 +1100; Phase 3/4/5 use agressive prefetch to try to maximise throughput, while phase 2 has no prefetch and uses synchronous reads. Effectively the use of lots of parallelism simply keeps multiple IOs in fli; /archives/xfs/2011-01/msg00033.html (9,926 bytes)
4. Re: [PATCH] xfs_repair: multithread phase 2 (score: 1): Author: Alex Elder <aelder@xxxxxxx>; Date: Wed, 05 Jan 2011 17:42:14 -0600; This is great. And evidently not very hard at all. It should have been done a long time ago... I had a few of the same comments Christoph had (though I didn't know about the the workqueues). I'll rei; /archives/xfs/2011-01/msg00061.html (12,931 bytes)
5. [PATCH] xfs_repair: multithread phase 2 (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Mon, 10 Jan 2011 11:44:08 +1100; Running some recent repair tests on broken filesystem meant running phase 1 and 2 repeatedly to reproduce an issue at the start of phase 3. Phase 2 was taking approximately 10 minutes to run as it pr; /archives/xfs/2011-01/msg00121.html (30,326 bytes)
6. Re: [PATCH] xfs_repair: multithread phase 2 (score: 1): Author: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>; Date: Mon, 10 Jan 2011 08:57:52 +0100; Is the fixed 32-way number reasonable, or shouldn't that be "number of available cpu cores"-way? Why threading when you have a single core cpu? -- mit freundlichen Grüssen, Michael Monnerie, Ing. BSc; /archives/xfs/2011-01/msg00122.html (9,300 bytes)
7. Re: [PATCH] xfs_repair: multithread phase 2 (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Mon, 10 Jan 2011 19:41:22 +1100; Sure, 32-way is reasonable on a single disk and CPU. Pretty much every sata disk supports NCQ these days, and default to a depth of 32, which means we can have 32 concurrent reads in progress at once; /archives/xfs/2011-01/msg00124.html (9,298 bytes)
8. Re: [PATCH] xfs_repair: multithread phase 2 (score: 1): Author: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>; Date: Mon, 10 Jan 2011 14:25:47 +0100; This is interesting. Did you measure this with a rotating single disk? Is the idle time between two synchronous reads bigger than the time needed to move the disk head to another cylinder and read a; /archives/xfs/2011-01/msg00130.html (10,333 bytes)
9. Re: [PATCH] xfs_repair: multithread phase 2 (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Mon, 10 Jan 2011 13:55:22 -0500; Looks good except for some trivial nitpicks below, Reviewed-by: Christoph Hellwig <hch@xxxxxx> Btw, your previous patch used just "repair:" as the Subject prefix, while this one uses xfs_repair. I do; /archives/xfs/2011-01/msg00134.html (9,885 bytes)
10. Re: [PATCH] xfs_repair: multithread phase 2 (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Mon, 10 Jan 2011 14:17:57 -0500; The default queue depth for ATA NCQ actually is 31, not 32 for some odd reason.; /archives/xfs/2011-01/msg00135.html (10,135 bytes)
11. Re: [PATCH] xfs_repair: multithread phase 2 (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Mon, 10 Jan 2011 14:18:26 -0500; Take a look at the patch description.; /archives/xfs/2011-01/msg00136.html (9,658 bytes)
12. Re: [PATCH] xfs_repair: multithread phase 2 (score: 1): Author: Matthias Schniedermeyer <ms@xxxxxxx>; Date: Mon, 10 Jan 2011 22:53:51 +0100; AFAIR the original discussion it's because Depth 0 and 32 use the same value. And the knowledge that (HDD-)firmware tends to be buggy, so it was decided to stay on the safe side and not use "0/32". B; /archives/xfs/2011-01/msg00149.html (11,080 bytes)
13. Re: [PATCH] xfs_repair: multithread phase 2 (score: 1): Author: Alex Elder <aelder@xxxxxxx>; Date: Tue, 01 Feb 2011 17:39:10 -0600; This looks good. Sorry I didn't say so earlier (I signed off on your first one). Reviewed-by: Alex Elder <aelder@xxxxxxx>; /archives/xfs/2011-02/msg00015.html (8,251 bytes)

Current List: 1 - 13
Page: [1]