On Mon, Jun 27, 2011 at 11:10 AM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: > 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. Clearly a philosophical difference. In managing complex software, it is far better for users if the software itself can simply report why something is a problem, without resorting to expecting users to read source code or ask developers why. There is nothing in the man page I see indicating what is good or bad regarding allocation groups - either document it there or warn in the software. If allocation algorithms are linear with respect to allocation groups, the something like this should be stated in the man pages. Doing neither leads to frustrated end users. If you answer is "use the defaults" then explain why and which parameters is applies to (again in the documentation). Also, it is not hard to do, and would have in this instance saved developer time. Since the issue has come up a few times the last month or so, it seems worthwhile to deal with. It's sort of like the story about giving a person a fish versus teaching them how to fish. Paul > > ====================================== > = Warning! mkfs.xfs detected insane = > = option specification. Cancel? = > = = > = [ OK ] [ Cancel ] = > ====================================== > > -Eric > >> Paul >> >> On Mon, Jun 27, 2011 at 4:55 AM, Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx> wrote: >>> 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 >>> >> >> _______________________________________________ >> xfs mailing list >> xfs@xxxxxxxxxxx >> http://oss.sgi.com/mailman/listinfo/xfs >> > > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
