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

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*xfs\s+performance\s+problem\s*$/: 26 ]

Total 26 documents matching your query.

1. xfs performance problem (score: 1): Author: Benjamin Schindler <bschindler@xxxxxxxxxxx>; Date: Tue, 26 Apr 2011 21:44:04 +0200; Hi Since upgrading to newer kernels I have serious problems with xfs performance on my root fs. It runs on a software raid 0 with 2 disks. On the same two disks, there are two more partitions running; /archives/xfs/2011-04/msg00347.html (7,375 bytes)
2. Re: xfs performance problem (score: 1): Author: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>; Date: Tue, 26 Apr 2011 17:12:01 -0500; Benjamin Schindler put forth on 4/26/2011 2:44 PM: The kernel config isn't the problem. You haven't enabled the delayed logging feature. Add 'delaylog' to your fstab mount options for XFS devices, re; /archives/xfs/2011-04/msg00355.html (8,218 bytes)
3. Re: xfs performance problem (score: 1): Author: Benjamin Schindler <bschindler@xxxxxxxxxxx>; Date: Wed, 27 Apr 2011 01:23:23 +0200; Hi Thanks for the hint. I remounted the root filesystem with delaylog. Even though it improves the situation, it doesn't feel like the performance is where it used to be on may be 2.6.32 or so. Remov; /archives/xfs/2011-04/msg00356.html (9,063 bytes)
4. Re: xfs performance problem (score: 1): Author: Benjamin Schindler <bschindler@xxxxxxxxxxx>; Date: Wed, 27 Apr 2011 01:59:41 +0200; Hi I thought I would do a real measurement to have some numbers. On my raid-1 ext3, extracting a kernel archive: benjamin@metis ~/software $ time tar xfj /usr/portage/distfiles/linux-2.6.38.tar.bz2 r; /archives/xfs/2011-04/msg00357.html (9,623 bytes)
5. Re: xfs performance problem (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Wed, 27 Apr 2011 12:35:34 +1000; more than likely your problem is that barriers have been enabled for MD/DM devices on the new kernel, and they aren't on the old kernel. XFS uses barriers by default, ext3 does not. Hence XFS perform; /archives/xfs/2011-04/msg00359.html (8,185 bytes)
6. Re: xfs performance problem (score: 1): Author: Michael Weissenbacher <mw@xxxxxxxxxxxx>; Date: Wed, 27 Apr 2011 09:55:45 +0200; schrieb Stan Hoeppner: If you are really adventurous and don't care about the data on your root fs use the following mount options: logbsize=256k,delaylog,nobarrier Personally i would only enable "no; /archives/xfs/2011-04/msg00363.html (8,477 bytes)
7. Re: xfs performance problem (score: 1): Author: Benjamin Schindler <bschindler@xxxxxxxxxxx>; Date: Wed, 27 Apr 2011 10:09:52 +0200; Hi Or stop using raid-0 all together. The performance gain is more than offset by the barriers and it seems using xfs on just a single disk would improve performance a lot more than using raid-0 (wit; /archives/xfs/2011-04/msg00364.html (9,670 bytes)
8. Re: xfs performance problem (score: 1): Author: pg_xf2@xxxxxxxxxxxxxxxxxx (Peter Grandi); Date: Fri, 29 Apr 2011 16:00:35 +0100; [ ... ] [ ... ] [ ... ] Indeed, and as some other commenters have tried to explain, in most cases the wrong number is the one for 'ext3' on RAID1 (way too small). Even the number for XFS and RAID0 'd; /archives/xfs/2011-04/msg00408.html (9,249 bytes)
9. Re: xfs performance problem (score: 1): Author: Martin Steigerwald <Martin@xxxxxxxxxxxx>; Date: Fri, 29 Apr 2011 18:27:34 +0200; Am Mittwoch, 27. April 2011 schrieb Dave Chinner: But didn't 2.6.38 replace barriers by explicit flushes the filesystem has to wait for - mitigating most of the performance problems with barriers? --; /archives/xfs/2011-04/msg00410.html (9,614 bytes)
10. Re: xfs performance problem (score: 1): Author: Martin Steigerwald <Martin@xxxxxxxxxxxx>; Date: Fri, 29 Apr 2011 18:28:45 +0200; sorry, forgot to cc. Am Mittwoch, 27. April 2011 schrieb Dave Chinner: But didn't 2.6.38 replace barriers by explicit flushes the filesystem has to wait for - mitigating most of the performance probl; /archives/xfs/2011-04/msg00411.html (8,815 bytes)
11. Re: xfs performance problem (score: 1): Author: pg_xf2@xxxxxxxxxxxxxxxxxx (Peter Grandi); Date: Fri, 29 Apr 2011 20:51:49 +0100; That's an example of the 'O_PONIES' attitude: because there are no performance problems with barriers as such. There is something completely different: a tradeoff between levels of safety (whether y; /archives/xfs/2011-04/msg00415.html (8,989 bytes)
12. Re: xfs performance problem (score: 1): Author: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>; Date: Sat, 30 Apr 2011 22:36:39 +0200; Although I understand your arguing, the OP just said that with ext3 the process returns after 22s, while on xfs he has to wait 2m20s to have the command prompt back. That's not a benchmark, but user; /archives/xfs/2011-04/msg00427.html (10,406 bytes)
13. Re: xfs performance problem (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Sun, 1 May 2011 18:49:19 +1000; Of course it can. Why? Because the allocator is optimised to pack small files written at the same time together on disk, and the elevator will merge them into one large IO when they are finally writt; /archives/xfs/2011-05/msg00001.html (9,880 bytes)
14. Re: xfs performance problem (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Sun, 1 May 2011 18:52:46 +1000; IIRC, it depends on whether the hardware supports FUA or not. If it doesn't then device cache flushes are used to emulate FUA and so performance can still suck. Christoph will no doubt correct me if; /archives/xfs/2011-05/msg00002.html (9,153 bytes)
15. Re: xfs performance problem (score: 1): Author: pg_xf2@xxxxxxxxxxxxxxxxxx (Peter Grandi); Date: Sun, 1 May 2011 14:33:14 +0100; [ ... ] That's a "real measurement" of *something*, and it does give "some numbers", but to me the numbers are not that interesting as it is far from clear what they are about. So I happen to have an; /archives/xfs/2011-05/msg00007.html (17,012 bytes)
16. Re: xfs performance problem (score: 1): Author: pg_xf2@xxxxxxxxxxxxxxxxxx (Peter Grandi); Date: Sun, 1 May 2011 15:38:25 +0100; [ ... Extracting a kernel 'tar' with GNU tar on 'ext3': ] [ ... Extracting a kernel 'tar' with GNU tar on XFS: ] % mount -t ext3 -o relatime /dev/sdb /mnt/sdb % time sh -c 'cd /mnt/sdb; star -x -b 2; /archives/xfs/2011-05/msg00008.html (14,112 bytes)
17. Re: xfs performance problem (score: 1): Author: pg_xf2@xxxxxxxxxxxxxxxxxx (Peter Grandi); Date: Sun, 1 May 2011 16:08:44 +0100; [ ... ] [ ... ] [ ... ] Just for confirmation here is the fantastic "performance" of 'ext3' with EatMyData: % mount -t ext3 -o relatime /dev/sdb /mnt/sdb % time sh -c 'cd /mnt/sdb; eatmydata star -x; /archives/xfs/2011-05/msg00009.html (10,077 bytes)
18. Re: xfs performance problem (score: 1): Author: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>; Date: Sun, 1 May 2011 17:32:51 +0200; Before people run aroung peeing each other on the leg, I'd like to bring this back from "benchmarking" to "user experience". The OP didn't benchmark, he just noticed that on ext3 unpacking the kernel; /archives/xfs/2011-05/msg00011.html (10,093 bytes)
19. Re: xfs performance problem (score: 1): Author: pg_xf2@xxxxxxxxxxxxxxxxxx (Peter Grandi); Date: Sun, 1 May 2011 17:32:28 +0100; To summarize some previous detailed discussion the actual "performance" difference is either a factor of around 2 (12m for 'ext3', 24m for XFS) in the regular case or a factor of around 1.2 (27s for; /archives/xfs/2011-05/msg00012.html (8,591 bytes)
20. Re: xfs performance problem (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Sun, 1 May 2011 12:55:46 -0400; Mitigating most of the barrier performance issues is a bit of a strong word. Yes, it remove useless ordering requirements, but fundamentally you still have to flush the disk cache to the physical med; /archives/xfs/2011-05/msg00013.html (10,129 bytes)

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