Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*xfs\:\s+very\s+slow\s+after\s+mount\,\s+very\s+slow\s+at\s+umount\s*$/: 34 ]

Total 34 documents matching your query.

21. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Mark Lord <kernel@xxxxxxxxxxxx>
Date: Thu, 27 Jan 2011 20:36:26 -0500
By the way, the documentation is excellent, for a developer who wants to work on the codebase. It describes the data structures and layouts etc.. better than perhaps any other Linux filesystem. But i
/archives/xfs/2011-01/msg00447.html (12,797 bytes)

22. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: david@xxxxxxx
Date: Thu, 27 Jan 2011 18:09:58 -0800 (PST)
david@xxxxxxx put forth on 1/27/2011 2:11 PM: how do I understand how to setup things on multi-disk systems? the documentation I've found online is not that helpful, and in some ways contradictory.
/archives/xfs/2011-01/msg00450.html (16,143 bytes)

23. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: David Rees <drees76@xxxxxxxxx>
Date: Thu, 27 Jan 2011 20:14:50 -0800
As suggested before - why are you messing with AGs instead of allocsize? I suspect that with the default configuration, XFS was trying to maximize throughput by reducing seeks with multiple processes
/archives/xfs/2011-01/msg00451.html (13,717 bytes)

24. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 28 Jan 2011 18:31:19 +1100
A simple google search turns up discussions like this: http://oss.sgi.com/archives/xfs/2009-01/msg01161.html Where someone reads the docco and asks questions to fill in gaps in their knowledge that t
/archives/xfs/2011-01/msg00457.html (15,295 bytes)

25. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sat, 29 Jan 2011 00:56:29 +1100
Only depending on block device capacity. Once at the maximum AG size (1TB), mkfs has to add more AGs. So once above 4TB for hardware RAID LUNs and 16TB for md/dm devices, you will get an AG per TB of
/archives/xfs/2011-01/msg00461.html (19,846 bytes)

26. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Mark Lord <kernel@xxxxxxxxxxxx>
Date: Fri, 28 Jan 2011 09:22:18 -0500
Who said "instead of"? I'm using both. Cheers
/archives/xfs/2011-01/msg00462.html (12,182 bytes)

27. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Mark Lord <kernel@xxxxxxxxxxxx>
Date: Fri, 28 Jan 2011 09:33:02 -0500
"in the long term we still expect fragmentation to degrade the performance of XFS file systems" Other than that, no hints there about how changing agcount affects things. Well, I've got 2/3 of those
/archives/xfs/2011-01/msg00463.html (14,005 bytes)

28. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Martin Steigerwald <Martin@xxxxxxxxxxxx>
Date: Fri, 28 Jan 2011 20:18:11 +0100
Am Thursday 27 January 2011 schrieb Stan Hoeppner: With one addition: Use a recent xfsprogs! ;) Earlier ones created more AGs, didn't activate lazy super block counter (likely no issue here) and what
/archives/xfs/2011-01/msg00470.html (11,111 bytes)

29. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: david@xxxxxxx
Date: Fri, 28 Jan 2011 11:26:00 -0800 (PST)
Picking the perfect mkfs.xfs parameters for a hardware RAID array can be somewhat of a black art, mainly because no two vendor arrays act or perform identically. if mkfs.xfs can figure out how to do
/archives/xfs/2011-01/msg00471.html (14,335 bytes)

30. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sat, 29 Jan 2011 10:58:47 +1100
"so we intend to add an on-line file system defragmentation utility to optimize the file system in the future" You are quoting from the wrong link - that's from the 1996 whitepaper. And sure, at the
/archives/xfs/2011-01/msg00476.html (15,139 bytes)

31. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sat, 29 Jan 2011 16:40:21 +1100
I'm going to be blunt - XFS is not a filesystem suited to use by clueless noobs. XFS is a highly complex filesystem designed for high end, high performance storage and therefore has the configurabili
/archives/xfs/2011-01/msg00479.html (14,840 bytes)

32. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: david@xxxxxxx
Date: Fri, 28 Jan 2011 22:08:42 -0800 (PST)
Picking the perfect mkfs.xfs parameters for a hardware RAID array can be somewhat of a black art, mainly because no two vendor arrays act or perform identically. if mkfs.xfs can figure out how to do
/archives/xfs/2011-01/msg00480.html (16,958 bytes)

33. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sat, 29 Jan 2011 18:35:54 +1100
Just because we can't do it right now doesn't mean it is not possible. Array/raid controller vendors need to implement the SCSI block limit VPD page, and if they do then stripe unit/stripe width may
/archives/xfs/2011-01/msg00481.html (18,858 bytes)

34. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon, 31 Jan 2011 14:17:20 -0500
I have access to a few big vendor arrays that export it, but I think they are still running beta firmware versions.
/archives/xfs/2011-01/msg00499.html (12,554 bytes)


This search system is powered by Namazu