Search String: Display: Description: Sort:

Results:

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

Total 11 documents matching your query.

1. XFS peculiar behavior (score: 1)
Author: Yannis Klonatos <klonatos@xxxxxxxxxxxx>
Date: Wed, 23 Jun 2010 10:37:19 +0300
Hi all! I have come across the following peculiar behavior in XFS and i would appreciate any information anyone could provide. In our lab we have a system that has twelve 500GByte hard disks (total c
/archives/xfs/2010-06/msg00278.html (8,307 bytes)

2. Re: XFS peculiar behavior (score: 1)
Author: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 23 Jun 2010 12:16:18 +0200
Interesting. I have no idea why this happens and would be interested in investigation too. As a quick help, maybe using allocsize=1G in the xfs mount options would help? How many AGs does the filesy
/archives/xfs/2010-06/msg00279.html (8,240 bytes)

3. Re: XFS peculiar behavior (score: 1)
Author: Andi Kleen <andi@xxxxxxxxxxxxxx>
Date: Wed, 23 Jun 2010 12:24:27 +0200
Why is that a problem? I don't know if it's the only reason, but XFS does a lot of data structure locking and updates per allocation group, so spreading to multiple AGs gives better scalability to ma
/archives/xfs/2010-06/msg00280.html (7,427 bytes)

4. Re: XFS peculiar behavior (score: 1)
Author: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 23 Jun 2010 17:04:55 +0200
This only helps if there are metadata operations, right? So in the case where you have one big database "file" of 50GB, it should be ordered sector-by-sector to get the maximum performance, and minim
/archives/xfs/2010-06/msg00281.html (9,058 bytes)

5. Re: XFS peculiar behavior (score: 1)
Author: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Wed, 23 Jun 2010 11:21:45 -0500
xfs_bmap output would be a lot nicer. Maybe you can paste that here to show exactly what the layout is. -Eric
/archives/xfs/2010-06/msg00282.html (8,837 bytes)

6. Re: XFS peculiar behavior (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 24 Jun 2010 09:17:00 +1000
The reasons for it being split are wide and varied. We need more information before trying to determie the reason. The output of "xfs_info <mntpt>" will tell us your filesystem geometry and the outpu
/archives/xfs/2010-06/msg00285.html (9,642 bytes)

7. Re: XFS peculiar behavior (score: 1)
Author: Yannis Klonatos <klonatos@xxxxxxxxxxxx>
Date: Thu, 24 Jun 2010 17:11:29 +0300
Hello again, First of all, thank you all for your quick replies. I attach all the information you requested in your responses. 1) The output of xfs_info is the following: meta-data=/dev/sdf isize=256
/archives/xfs/2010-06/msg00288.html (13,205 bytes)

8. Re: XFS peculiar behavior (score: 1)
Author: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 24 Jun 2010 10:21:17 -0500
The file started out in the last AG, and then had to wrap around, because it hit the end of the filesystem. :) It was then somewhat sequential in AGs 4,5,6,7 after that, though not perfectly so. This
/archives/xfs/2010-06/msg00289.html (15,258 bytes)

9. Re: XFS peculiar behavior (score: 1)
Author: Yannis Klonatos <klonatos@xxxxxxxxxxxx>
Date: Thu, 24 Jun 2010 18:35:42 +0300
First of all, thank you all for your quick replies. I attach all the information you requested in your responses. 1) The output of xfs_info is the following: meta-data=/dev/sdf isize=256 agcount=32,
/archives/xfs/2010-06/msg00290.html (16,692 bytes)

10. Re: XFS peculiar behavior (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 25 Jun 2010 10:46:30 +1000
For inode64, yes. For inode32, the first ag is derived from the /proc/sys/fs/xfs/rotorstep sysctl. Changing the value of the step will likely change the first AG location of the database in this test
/archives/xfs/2010-06/msg00294.html (14,122 bytes)

11. Re: XFS peculiar behavior (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 25 Jun 2010 10:58:36 +1000
XFS spreads allocation out over it's entire address space to enable utilisation of all the disks backing the filesystem (think linear concatenation of devices). This is sub-optimal for a small number
/archives/xfs/2010-06/msg00295.html (12,121 bytes)


This search system is powered by Namazu