On 6/26/2011 11:14 PM, Marcus Pereira wrote: > Em 27-06-2011 00:33, Stan Hoeppner escreveu: >> >> 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. > 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. > At the end the reason why I opened the thread it the error and the > developers should take some care about that. > 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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
