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.

1. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 27 Jan 2011 14:30:11 +1100
[Please cc xfs@xxxxxxxxxxx on XFS bug reports. Added.] Please post the output of xfs_info <mtpt> so we can see what you filesystem configuration is. I can't say I've seen this. Can you capture a blkt
/archives/xfs/2011-01/msg00409.html (11,133 bytes)

2. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 27 Jan 2011 14:43:14 +1100
Not to me. You can check this simply by looking at the output of top while the problem is occurring... Well, yeah - XFS check reads all the metadata in the filesystem, so of course it's going to thra
/archives/xfs/2011-01/msg00410.html (12,616 bytes)

3. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Mark Lord <kernel@xxxxxxxxxxxx>
Date: Wed, 26 Jan 2011 22:49:03 -0500
/dev/sdb1 on /var/lib/mythtv type xfs (rw,noatime,allocsize=64M,logbufs=8,largeio) [~] xfs_info /var/lib/mythtv meta-data=/dev/sdb1 isize=256 agcount=7453, agsize=65536 blks = sectsz=512 attr=2 data
/archives/xfs/2011-01/msg00411.html (11,741 bytes)

4. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Mark Lord <kernel@xxxxxxxxxxxx>
Date: Wed, 26 Jan 2011 22:53:17 -0500
.. Top doesn't show anything interesting, since disk I/O uses practically zero CPU. I find it interesting that the mount takes zero-time, as if it never actually reads much from the filesystem. Somet
/archives/xfs/2011-01/msg00412.html (10,541 bytes)

5. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Mark Lord <kernel@xxxxxxxxxxxx>
Date: Wed, 26 Jan 2011 23:54:01 -0500
I've rebuilt the kernel with the various config options to enable blktrace and XFS_DEBUG, but in the meanwhile we have also watched and deleted a few GB of recordings. The result is that the mysterio
/archives/xfs/2011-01/msg00422.html (11,613 bytes)

6. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Date: Wed, 26 Jan 2011 23:17:13 -0600
Mark Lord put forth on 1/26/2011 9:49 PM: That's probably a bit high Mark, and very possibly the cause of your problems. striped disk drives. You said it's a single 2TB drive right? The default agcou
/archives/xfs/2011-01/msg00423.html (8,289 bytes)

7. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Mark Lord <kernel@xxxxxxxxxxxx>
Date: Thu, 27 Jan 2011 10:12:23 -0500
This is great info, exactly the kind of feedback I was hoping for! The filesystem is about a year old now, and I probably used agsize=nnnnn when creating it or something. So if this resulted in what
/archives/xfs/2011-01/msg00424.html (10,643 bytes)

8. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx>
Date: Thu, 27 Jan 2011 10:40:31 -0500 (EST)
agcount=7453 That's probably a bit high Mark, and very possibly the cause of your problems. striped disk drives. You said it's a single 2TB drive right? The default agcount for a single drive filesy
/archives/xfs/2011-01/msg00427.html (11,462 bytes)

9. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Mark Lord <kernel@xxxxxxxxxxxx>
Date: Thu, 27 Jan 2011 11:03:49 -0500
.. .. .. I am concerned with fragmentation on the very special workload in this case. I'd really like the 20GB files, written over a 1-2 hour period, to consist of a very few very large extents, as m
/archives/xfs/2011-01/msg00428.html (10,561 bytes)

10. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Date: Thu, 27 Jan 2011 13:40:06 -0600
Mark Lord put forth on 1/27/2011 10:03 AM: For XFS that's actually not a special case workload but an average one. XFS was conceived at SGI for use on large supercomputers where typical single file d
/archives/xfs/2011-01/msg00432.html (14,136 bytes)

11. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: david@xxxxxxx
Date: Thu, 27 Jan 2011 12:11:54 -0800 (PST)
Rather than hundreds or thousands of "tiny" MB sized extents. I wonder what the best mkfs.xfs parameters might be to encourage that? You need to use the mkfs.xfs defaults for any single drive filesy
/archives/xfs/2011-01/msg00433.html (13,482 bytes)

12. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: "John Stoffel" <john@xxxxxxxxxxx>
Date: Thu, 27 Jan 2011 15:24:25 -0500
Hmmm, should the application be pre-allocating the disk space then, so that the writes get into nice large extents automatically? Isn't this what the fallocate() system call is for? Doesn't MythTV u
/archives/xfs/2011-01/msg00434.html (12,249 bytes)

13. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Mark Lord <kernel@xxxxxxxxxxxx>
Date: Thu, 27 Jan 2011 16:56:20 -0500
But it did not do the right thing when I used the defaults. Big files ended up with tons of (exactly) 64MB extents, ISTR. With the increased number of ags, I saw much less fragmentation, and the driv
/archives/xfs/2011-01/msg00435.html (11,853 bytes)

14. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 28 Jan 2011 10:34:09 +1100
My point is that xfs_check doesn't use zero cpu or memory - it uses quite a lot of both, so if it is not present in top output while the disk is being thrashed, it ain't running... Sure, for a clean
/archives/xfs/2011-01/msg00439.html (11,110 bytes)

15. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 28 Jan 2011 10:39:29 +1100
7453 AGs means that the first write coud cause up to ~7500 disk reads to occur as the AGF headers are read in to find where the best free space extent for allocation lies. That'll be your problem. Ch
/archives/xfs/2011-01/msg00440.html (11,697 bytes)

16. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 28 Jan 2011 10:41:52 +1100
http://xfs.org/index.php/XFS_FAQ#Q:_I_want_to_tune_my_XFS_filesystems_for_.3Csomething.3E And perhaps you want to consider the allocsize mount option, though that shouldn't be necessary for 2.6.38+..
/archives/xfs/2011-01/msg00441.html (12,128 bytes)

17. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Date: Thu, 27 Jan 2011 17:53:18 -0600
david@xxxxxxx put forth on 1/27/2011 2:11 PM: Visit http://xfs.org There you will find: Users guide: http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide//tmp/en-US/html/index.html File system structur
/archives/xfs/2011-01/msg00442.html (13,546 bytes)

18. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 28 Jan 2011 11:17:35 +1100
Because your AG size is 64MB. An extent can't be larger than an AG. Hence you are fragmenting your large files unnecessarily, as extents can be up to 8GB in size on a 4k block size filesystem. The al
/archives/xfs/2011-01/msg00443.html (13,382 bytes)

19. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Mark Lord <kernel@xxxxxxxxxxxx>
Date: Thu, 27 Jan 2011 19:59:51 -0500
.. That entry says little beyond "blindly trust the defaults". But thanks anyway (really). That's a good tip, thanks. Maybe that allocsize value could be increased though. Perhaps something on the or
/archives/xfs/2011-01/msg00445.html (11,142 bytes)

20. Re: xfs: very slow after mount, very slow at umount (score: 1)
Author: Mark Lord <kernel@xxxxxxxxxxxx>
Date: Thu, 27 Jan 2011 20:22:48 -0500
Maybe. But what I read from the paragraph above, is that the documentation could perhaps explain things better, and then people other than the coders might understand how best to tweak it. How AGs ar
/archives/xfs/2011-01/msg00446.html (13,150 bytes)


This search system is powered by Namazu