Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Speeding\s+up\s+XFS\s*$/: 36 ]

Total 36 documents matching your query.

1. Re: Speeding up XFS (score: 1)
Author: Andi Kleen <ak@xxxxxx>
Date: Sat, 01 May 2004 16:44:18 +0200
Did you try it with elevator=deadline ? Maybe you are just seeing elevator starvation. The default anticipatory elevator adds artificial latencies for better throughput. -Andi
/archives/xfs/2004-05/msg00000.html (7,582 bytes)

2. Re: Speeding up XFS (score: 1)
Author: Bruce Guenter <lists-linux-xfs@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 2 May 2004 15:06:48 -0600
All the tests were run with elevator=deadline, for exactly that reason. -- Bruce Guenter <bruceg@xxxxx> http://em.ca/~bruceg/ http://untroubled.org/ OpenPGP key: 699980E8 / D0B7 C8DD 365D A395 29DA 2
/archives/xfs/2004-05/msg00005.html (8,399 bytes)

3. Re: Speeding up XFS (score: 1)
Author: Tim Shimmin <tes@xxxxxxx>
Date: Wed, 5 May 2004 15:12:43 +1000
Up to 256Kb log buffers on Linux should work now. (i.e. 32K, 64K, 128K, 256K). If anyone still has problems with log striping then please let us (me in particular) know. Thanks, Tim.
/archives/xfs/2004-05/msg00047.html (8,537 bytes)

4. Re: Speeding up XFS (score: 1)
Author: lawalsh <xfs@xxxxxxxxx>
Date: Fri, 14 May 2004 11:05:12 -0700
Haven't tried 64 and 128 yet, but 256 made ugly ascii error messages on my screen (generic mount failed message). I'd increased the #buffs to 8 and the bufsize to 262144, and got failures on mounting
/archives/xfs/2004-05/msg00136.html (8,755 bytes)

5. Re: Speeding up XFS (score: 1)
Author: Chris Wedgwood <cw@xxxxxxxx>
Date: Sun, 16 May 2004 11:33:48 -0700
strace mount please and show the error code it gets from the kernel. --cw
/archives/xfs/2004-05/msg00141.html (7,842 bytes)

6. Re: Speeding up XFS (score: 1)
Author: lawalsh <xfs@xxxxxxxxx>
Date: Sun, 16 May 2004 14:42:18 -0700
Attaching traces for 64 (fail), 128(fail), 256(fail). 32 and 16 documented on the man page. Maybe it's a new security feature. xfs checks user's man page and enforces language in man page? :-) Al
/archives/xfs/2004-05/msg00142.html (9,138 bytes)

7. Re: Speeding up XFS (score: 1)
Author:
Date: Sat, 01 May 2004 16:44:18 +0200
Did you try it with elevator=deadline ? Maybe you are just seeing elevator starvation. The default anticipatory elevator adds artificial latencies for better throughput. -Andi
/archives/xfs/2004-05/msg00229.html (7,582 bytes)

8. Re: Speeding up XFS (score: 1)
Author:
Date: Sun, 2 May 2004 15:06:48 -0600
All the tests were run with elevator=deadline, for exactly that reason. -- Bruce Guenter <bruceg@xxxxx> http://em.ca/~bruceg/ http://untroubled.org/ OpenPGP key: 699980E8 / D0B7 C8DD 365D A395 29DA 2
/archives/xfs/2004-05/msg00234.html (8,399 bytes)

9. Re: Speeding up XFS (score: 1)
Author:
Date: Wed, 5 May 2004 15:12:43 +1000
Up to 256Kb log buffers on Linux should work now. (i.e. 32K, 64K, 128K, 256K). If anyone still has problems with log striping then please let us (me in particular) know. Thanks, Tim.
/archives/xfs/2004-05/msg00276.html (8,537 bytes)

10. Re: Speeding up XFS (score: 1)
Author:
Date: Fri, 14 May 2004 11:05:12 -0700
Haven't tried 64 and 128 yet, but 256 made ugly ascii error messages on my screen (generic mount failed message). I'd increased the #buffs to 8 and the bufsize to 262144, and got failures on mounting
/archives/xfs/2004-05/msg00365.html (8,755 bytes)

11. Re: Speeding up XFS (score: 1)
Author:
Date: Sun, 16 May 2004 11:33:48 -0700
strace mount please and show the error code it gets from the kernel. --cw
/archives/xfs/2004-05/msg00370.html (7,842 bytes)

12. Re: Speeding up XFS (score: 1)
Author:
Date: Sun, 16 May 2004 14:42:18 -0700
Attaching traces for 64 (fail), 128(fail), 256(fail). 32 and 16 documented on the man page. Maybe it's a new security feature. xfs checks user's man page and enforces language in man page? :-) Al
/archives/xfs/2004-05/msg00371.html (9,138 bytes)

13. a XFS boot partition (score: 1)
Author: Bruce Guenter <lists-linux-xfs@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 26 Apr 2004 10:51:55 -0600
I have been running a series of custom benchmarks to see what filesystems perform best for a maildir-based mail server. http://untroubled.org/benchmarking/2004-04/ So far, XFS with an external journ
/archives/xfs/2004-04/msg00199.html (8,674 bytes)

14. ition (score: 1)
Author: Chris Wedgwood <cw@xxxxxxxx>
Date: Mon, 26 Apr 2004 10:07:53 -0700
How large are the maildir's themselves (specifically how large are the new & cur directories)? --cw
/archives/xfs/2004-04/msg00200.html (8,089 bytes)

15. with mount and strace (score: 1)
Author: Bruce Guenter <lists-linux-xfs@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 26 Apr 2004 11:22:30 -0600
During the run of the above benchmark, they are typically small -- less than a dozen entries in each one, with filenames of about 23 characters. -- Bruce Guenter <bruceg@xxxxx> http://em.ca/~bruceg/
/archives/xfs/2004-04/msg00202.html (9,440 bytes)

16. e (score: 1)
Author: Glen Overby <overby@xxxxxxx>
Date: Mon, 26 Apr 2004 12:26:08 -0500 (CDT)
Some generic suggestions: - more log buffers than fewer (try 8) - It looks like you're doing a lot of metadata intense operations, so you should try a larger log buffer size which are available in ve
/archives/xfs/2004-04/msg00203.html (9,004 bytes)

17. S (score: 1)
Author: Bruce Guenter <lists-linux-xfs@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 26 Apr 2004 11:33:00 -0600
I'm already using: mount -t xfs -o noatime,logbufs=8,logbsize=65536 I'll try that. I did so: Filesystem partition: 72GB on a software RAID-1 array of Fujitsu SCSI 15kRPM disks. Is there any way to av
/archives/xfs/2004-04/msg00204.html (10,337 bytes)

18. S (score: 1)
Author: Chris Wedgwood <cw@xxxxxxxx>
Date: Mon, 26 Apr 2004 10:49:28 -0700
I don't think you are seeing that. You can avoid it by using fs' under 1TB or making your inodes larger (buys you a little). Or use a 64-bit CPU.
/archives/xfs/2004-04/msg00205.html (8,504 bytes)

19. S (score: 1)
Author: Bruce Guenter <lists-linux-xfs@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 26 Apr 2004 11:54:23 -0600
Well, that's solved -- the filesystem is only 72GB, and the benchmark is running on an Opteron (AMD 64-bit). -- Bruce Guenter <bruceg@xxxxx> http://em.ca/~bruceg/ http://untroubled.org/ OpenPGP key:
/archives/xfs/2004-04/msg00206.html (9,262 bytes)

20. S (score: 1)
Author: Glen Overby <overby@xxxxxxx>
Date: Mon, 26 Apr 2004 12:56:43 -0500 (CDT)
On Irix: mount -o inode64 On Linux: rewrite linux to use 64 bit inode numbers :-) With your filesystem, you should not be hitting the 32 bit inode problem. It kicks in a bit above a terabyte. I recen
/archives/xfs/2004-04/msg00207.html (9,213 bytes)

Current List: 1 - 20
Page: [1] [2]
This search system is powered by Namazu