Thread (15 messages) 15 messages, 5 authors, 2011-06-28

Re: mkfs.xfs error creating large agcount an raid

From: Eric Sandeen <hidden>
Date: 2011-06-27 15:10:09

On 6/27/11 8:04 AM, Paul Anderson wrote:
One thing this thread indicates is the need for a warning in mkfs.xfs
- according to several developers, there is, I think, linear increase
in allocation time to number of allocation groups.

It would be helpful for the end user to simply issue a warning stating
this when the AG count seems high with a brief explanation as to why
it seems high.  I would allow it, but print the warning.  Even a
simple linear check like agroups>500 should suffice for "a while".
I disagree.

There are all sorts of ways a user can shoot themselves in the foot with
unix commands.  Detecting and warning about all of them is a fool's errand.

======================================
= Warning!  mkfs.xfs detected insane =
=   option specification.  Cancel?   =
=                                    =
=      [   OK   ]     [ Cancel ]     =
======================================

-Eric
Paul

On Mon, Jun 27, 2011 at 4:55 AM, Stan Hoeppner [off-list ref] wrote:
quoted
On 6/26/2011 11:14 PM, Marcus Pereira wrote:
quoted
Em 27-06-2011 00:33, Stan Hoeppner escreveu:
quoted
I recommend 3 changes, one of which I previously mentioned:

1.  Use 8 mirror pairs instead of 4
2.  Don't use striping.  Make an mdraid --linear device of the 8 mirrors
3.  Format with '-d agcount=32' which will give you 4 AGs per spindle

Test this configuration and post your results.
I am thanks for all advices. I will make the tests and post, may take
some time.

About all other messages. My system may not be a Ferrari but its not a
Volks. I certainly do not have that many HDs in fiber channel, but the
sever is a dual core Xeon 6 cores with HT. Linux sees a total of 24
cores, total RAM is 24GB. The HDs are all SAS 15Krpm and the system runs
on SSD. They are dedicated to handle the maildir files and I have
several of those servers running nicely.
But I don’t want to make the thread about my system larger.
So you do or don't have the excessive head seek problem you previously
mentioned?  If not then use the mkfs.xfs defaults.
quoted
Yes, I don’t know much about XFS and Allocation groups, thanks for you
all to help me a bit.
You're welcome.  Google should turn up a decent amount of information
about XFS allocation groups if you're interested in further reading.
quoted
At the end the reason why I opened the thread it the error and the
developers should take some care about that.
quoted
Ok, no reason to use that many agcount but giving a "mkfs.xfs: pwrite64
failed: No space left on device" error for me stills seems a bug.
The definition of a software bug stipulates incorrect or unexpected
program behavior.  Error messages aren't bugs unless the wrong error
message is returned for a given fault condition, or no error is returned
when one should be.

Are you stipulating that the above isn't the correct error message for
the fault condition?  Or do you simply not understand the error message?
 If the latter, maybe you should simply ask what that error means before
saying the error message is a bug. :)

--
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help