Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*performance\s+over\s+multiple\s+disks\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*performance\s+over\s+multiple\s+disks\s*$/: 23 ]

Total 23 documents matching your query.

1. re: performance over multiple disks (score: 1): Author: Chris Tooley <ctooley@xxxxxxxx>; Date: 01 Nov 2002 09:41:05 -0600; Chalk it up to stupidity or just wanting to learn, but I don't understand the prime number rationale. I'm sure there is a perfectly legitimate reason, but I certainly don't know what it is. Could som; /archives/xfs/2002-11/msg00007.html (9,796 bytes)
2. : Question about kernel update (score: 1): Author: Chris Tooley <ctooley@xxxxxxxx>; Date: 01 Nov 2002 09:41:05 -0600; ho; /archives/xfs/2002-11/msg00460.html (9,796 bytes)
3. linux-2.5 tree changes? (score: 1): Author: ndeen <sandeen@xxxxxxx>; Date: Thu, 31 Oct 2002 10:49:47 -0700 (MST); ch has started locking up when I run my backup script. The script creates a LVM snapshot for each of 3 LVs in turn and then uses xfsdump to back them up. After the lockup, no; /archives/xfs/2002-10/msg00761.html (7,878 bytes)
4. emove VPURGE (score: 1): Author: h <james@xxxxxxxxxxxxx>; Date: Thu, 31 Oct 2002 10:16:42 -0800; 're in kdb... but if you're in X, you're stuck there. Blindly typing "go<enter>" may get you going again. I put a fix in recently that prevents XFS from generating a transac; /archives/xfs/2002-10/msg00762.html (8,154 bytes)
5. cmds (score: 1): Author: ndeen <sandeen@xxxxxxx>; Date: Thu, 31 Oct 2002 20:42:33 +0100; stored on disk. Would it be read faster; /archives/xfs/2002-10/msg00765.html (10,176 bytes)
6. s (score: 1): Author: xfs@xxxxxxxxxxxxxxxxxxx; Date: Thu, 31 Oct 2002 11:47:03 -0800; kernel does indeed allow my backup to run. It is obvious that you guys have made a number of improvements in XFS/LVS integration in the last several months. I'm looking forwa; /archives/xfs/2002-10/msg00766.html (8,550 bytes)
7. (score: 1): Author: ksimach@xxxxxxxxxxxxxx>; Date: Thu, 31 Oct 2002 21:13:32 +0100; single disk the read-time will be that of a single seek + file_size/transfer_rate (approxemately). If the file is spread over multiple disks the transfer-time will be reduc; /archives/xfs/2002-10/msg00768.html (9,969 bytes)
8. sks (score: 1): Author: ksimach@xxxxxxxxxxxxxx>; Date: Thu, 31 Oct 2002 12:28:41 -0800; will have slower writes obv; /archives/xfs/2002-10/msg00770.html (8,787 bytes)
9. disks (score: 1): Author: ksimach@xxxxxxxxxxxxxx>; Date: Thu, 31 Oct 2002 17:30:58 -0500; o be smart about MD devices and align things as a result of this. I'm not sure how well it works in practice though, I can test a little later... --cw P.S. You've got bogus 8-bit cruf; /archives/xfs/2002-10/msg00773.html (9,292 bytes)
10. l (score: 1): Author: sandeen@xxxxxxx>; Date: Thu, 31 Oct 2002 10:49:47 -0700 (MST); was done, since you h; /archives/xfs/2002-10/msg01540.html (7,878 bytes)
11. lurking compile error (score: 1): Author: ndeen@xxxxxxx>; Date: Thu, 31 Oct 2002 10:16:42 -0800; st changed the way CVS is exported, perhaps there is a problem. We'll look into it today. Eric, That message was supposed to be sent last night, but; /archives/xfs/2002-10/msg01541.html (8,154 bytes)
12. Re: linux-2.5 tree changes? (score: 1): Author: xxxxxxxxxxxxxxx>; Date: Thu, 31 Oct 2002 20:42:33 +0100; the lockup, no; /archives/xfs/2002-10/msg01544.html (10,176 bytes)
13. x-2.5 tree changes? (score: 1): Author: xxxxx>; Date: Thu, 31 Oct 2002 11:47:03 -0800; ting a transac; /archives/xfs/2002-10/msg01545.html (8,550 bytes)
14. Lockup with LVM snapshot (score: 1): Author: xxxxxx>; Date: Thu, 31 Oct 2002 21:13:32 +0100; be read faster; /archives/xfs/2002-10/msg01547.html (9,969 bytes)
15. performance over multiple disks (score: 1): Author: xxxxxxx; Date: Thu, 31 Oct 2002 12:28:41 -0800; wa; /archives/xfs/2002-10/msg01549.html (8,787 bytes)
16. : re[2]: Lockup with LVM snapshot (score: 1): Author: xxxxxx>; Date: Thu, 31 Oct 2002 17:30:58 -0500; writes obv; /archives/xfs/2002-10/msg01552.html (9,292 bytes)
17. performance over multiple disks (score: 1): Author: James Rich <james@xxxxxxxxxxxxx>; Date: Thu, 31 Oct 2002 10:49:47 -0700 (MST); On another mailing list a debate arose about performance over a single disk vs. multiple disks. It goes something like this: Suppose you have a 6 megabyte file stored on disk. Would it be read faster; /archives/xfs/2002-10/msg02319.html (7,878 bytes)
18. Re: performance over multiple disks (score: 1): Author: Chris Wedgwood <cw@xxxxxxxx>; Date: Thu, 31 Oct 2002 10:16:42 -0800; It depends.... but usually data over multiple disks reads faster, sometimes n-times the speed of a single disk (but not always). --cw; /archives/xfs/2002-10/msg02320.html (8,250 bytes)
19. Re: performance over multiple disks (score: 1): Author: Ragnar Kjørstad <xfs@xxxxxxxxxxxxxxxxxxx>; Date: Thu, 31 Oct 2002 20:42:33 +0100; If the file is stored on a single disk the read-time will be that of a single seek + file_size/transfer_rate (approxemately). If the file is spread over multiple disks the transfer-time will be reduc; /archives/xfs/2002-10/msg02323.html (10,313 bytes)
20. Re: performance over multiple disks (score: 1): Author: Chris Wedgwood <cw@xxxxxxxx>; Date: Thu, 31 Oct 2002 11:47:03 -0800; More disks -> more heads -> lower average seek time. If you experiment with this, you'll find eads over multiple disks and stripping is almost *always* faster. RAID4/RAID5 will have slower writes obv; /archives/xfs/2002-10/msg02324.html (8,656 bytes)

Current List: 1 - 20
Page: [1] [2]