Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*XFS\s+vs\s+Elevators\s+$was\s+Re\:\s+\[PATCH\s+RFC\]\s+nilfs2\:\s+continuous\s+snapshotting\s+file\s+system$\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*XFS\s+vs\s+Elevators\s+$was\s+Re\:\s+\[PATCH\s+RFC\]\s+nilfs2\:\s+continuous\s+snapshotting\s+file\s+system$\s*$/: 84 ]

Total 84 documents matching your query.

1. XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 21 Aug 2008 15:15:08 +1000; Ok, I thought it might be the tiny log, but it didn't improve anything here when increased the log size, or the log buffer size. Looking at the block trace, I think elevator merging is somewhat buste; /archives/xfs/2008-08/msg00320.html (20,318 bytes)
2. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: gus3 <musicman529@xxxxxxxxx>; Date: Wed, 20 Aug 2008 23:00:07 -0700 (PDT); [snip] [snip] I concur your observation, esp. w.r.t. XFS and CFQ clashing: http://gus3.typepad.com/i_am_therefore_i_think/2008/07/finding-the-fas.html CFQ is the default on most Linux systems AFAIK;; /archives/xfs/2008-08/msg00321.html (12,125 bytes)
3. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 21 Aug 2008 16:04:18 +1000; One thing I just found out - my old *laptop* is 4-5x faster than the 10krpm scsi disk behind an old cciss raid controller. I'm wondering if the long delays in dispatch is caused by an interaction wit; /archives/xfs/2008-08/msg00322.html (14,341 bytes)
4. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 21 Aug 2008 16:14:43 +1000; I'm wondering if these elevators are just getting too smart for their own good. w.r.t to the above test, deadline was about twice as slow as CFQ - it does immediate dispatch on SYNC_WRITE bios and so; /archives/xfs/2008-08/msg00323.html (13,540 bytes)
5. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Aaron Carroll <aaronc@xxxxxxxxxxxxxxxxxx>; Date: Thu, 21 Aug 2008 18:07:38 +1000; Dave Chinner wrote: One thing I just found out - my old *laptop* is 4-5x faster than the 10krpm scsi disk behind an old cciss raid controller. I'm wondering if the long delays in dispatch is caused b; /archives/xfs/2008-08/msg00325.html (23,440 bytes)
6. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 21 Aug 2008 18:25:32 +1000; Just to point out - this is not a new problem - I can reproduce it on 2.6.24 as well as 2.6.26. Likewise, my laptop shows XFS being faster than ext3 on both 2.6.24 and 2.6.26. So the difference is so; /archives/xfs/2008-08/msg00326.html (14,993 bytes)
7. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 21 Aug 2008 18:53:32 +1000; We've already got plenty of explicit unplugs in XFS to get stuff moving quickly - I'll just have to add another.... It's getting too bloody complex, IMO. What is right for one elevator is wrong for a; /archives/xfs/2008-08/msg00327.html (13,049 bytes)
8. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Martin Steigerwald <Martin@xxxxxxxxxxxx>; Date: Thu, 21 Aug 2008 13:02:50 +0200; Am Donnerstag 21 August 2008 schrieb Dave Chinner: Interesting. I switched from cfq to deadline some time ago, due to abysmal XFS performance on parallel IO - aptitude upgrade and doing desktop stuff; /archives/xfs/2008-08/msg00328.html (15,082 bytes)
9. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Martin Knoblauch <knobi@xxxxxxxxxxxx>; Date: Thu, 21 Aug 2008 04:05:21 -0700 (PDT); -- Original Message -- Hi Dave, just curious - which CCISS controller and and what kind of disk configuration are you using. Cheers Martin; /archives/xfs/2008-08/msg00329.html (10,575 bytes)
10. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Matthew Wilcox <matthew@xxxxxx>; Date: Thu, 21 Aug 2008 05:53:10 -0600; I don't think that's going to make a difference when using CFQ. I did some tests that showed that CFQ would never issue more than one IO at a time to a drive. This was using sixteen userspace threads; /archives/xfs/2008-08/msg00330.html (11,658 bytes)
11. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Chris Mason <chris.mason@xxxxxxxxxx>; Date: Thu, 21 Aug 2008 10:52:44 -0400; I did some compilebench runs with xfs this morning, creating 30 kernel trees on the same machine I posted btrfs and xfs numbers with last week. Btrfs gets between 60 and 75MB/s average depending on t; /archives/xfs/2008-08/msg00331.html (15,111 bytes)
12. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Martin Steigerwald <Martin@xxxxxxxxxxxx>; Date: Thu, 21 Aug 2008 17:00:29 +0200; Am Donnerstag 21 August 2008 schrieb Martin Steigerwald: wrote: Okay, some numbers attached: - On XFS: Barrier versus Nobarrier makes quite a difference with compilebench. Also on rm -rf'ing the larg; /archives/xfs/2008-08/msg00332.html (18,946 bytes)
13. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Fri, 22 Aug 2008 01:56:29 +1000; Not obviously the same sort of issue. The traces clearly show multiple nested dispatches and completions so CTQ is definitely active... Anyway, after a teeth-pulling equivalent exercise of finding th; /archives/xfs/2008-08/msg00333.html (14,143 bytes)
14. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Fri, 22 Aug 2008 01:59:25 +1000; Smart Array 5300, using a single 36GB 10krpm U3SCSI disk. Looks like most of the problems were caused by the firmware, and are not driver related. An upgrade to a newer (2002!) firmware appears to ha; /archives/xfs/2008-08/msg00334.html (9,089 bytes)
15. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Fri, 22 Aug 2008 03:08:54 +1000; That is the problem in a nutshell. Nobody can keep up with all the shiny new stuff that is being implemented,let alone the subtle behavioural differences that accumulate through such change... Yet th; /archives/xfs/2008-08/msg00335.html (13,642 bytes)
16. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Szabolcs Szakacsits <szaka@xxxxxxxxxxx>; Date: Thu, 21 Aug 2008 20:10:08 +0300 (MET DST); It's a laptop and has NCQ. It makes no difference if NCQ is enabled or disabled. The problem seems to be XFS only. XFS definitely stalls somewhere: stats show virtually no CPU usage and no time spent; /archives/xfs/2008-08/msg00336.html (14,153 bytes)
17. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Szabolcs Szakacsits <szaka@xxxxxxxxxxx>; Date: Thu, 21 Aug 2008 20:33:50 +0300 (MET DST); The 'nobarrier' mount option made a big improvement: MB/s Runtime (s) -- -- btrfs unstable 17.09 572 ext3 13.24 877 btrfs 0.16 12.33 793 nilfs2 2nd+ runs 11.29 674 ntfs-3g 8.55 865 reiserfs 8.38 966; /archives/xfs/2008-08/msg00338.html (12,850 bytes)
18. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Fri, 22 Aug 2008 12:24:59 +1000; INteresting. Barriers make only a little difference on my laptop; 10-20% slower. But yes, barriers will have this effect on XFS. If you've got NCQ, then you'd do better to turn off write caching on t; /archives/xfs/2008-08/msg00345.html (14,014 bytes)
19. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author: Martin Steigerwald <Martin@xxxxxxxxxxxx>; Date: Fri, 22 Aug 2008 08:49:37 +0200; Am Freitag 22 August 2008 schrieb Dave Chinner: See my other post with performance numbers: Barriers appear to make more than 50% difference on my laptop for some operations on some other operations; /archives/xfs/2008-08/msg00346.html (26,318 bytes)
20. Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) (score: 1): Author:; Date: Fri, 22 Aug 2008 15:44:29 +0300 (MET DST); Write cache off, nobarrier and AHCI NCQ lowered the XFS result: MB/s Runtime (s) -- -- btrfs unstable 17.09 572 ext3 13.24 877 btrfs 0.16 12.33 793 ntfs-3g unstable 11.52 673 nilfs2 2nd+ runs 11.29 6; /archives/xfs/2008-08/msg00350.html (12,584 bytes)

Current List: 1 - 20
Page: [1] [2] [3] [4] [5]