[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
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
.. 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
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
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
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
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
.. .. .. 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
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
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
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
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
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
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
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+..
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
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
.. 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
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