>> >> Interesting, thanks for the results, Mark. So, I guess don't tune unless > you have a very good reason to do so? Or, if you're really going to try to > squeeze all the performance possible, put your metadata on a separate FS with > a different alloc size (or no alloc size specified) so that metadata access > isn't adversely impacted by trying to tune data access? >> >> -Nick > > Well, the XFS guys certainly suggest default tuning in most cases... :) > > http://xfs.org/index.php/XFS_FAQ#Q:_I_want_to_tune_my_XFS_filesystems_for_.3 > Csomething.3E > > I think there is value in investigating things when you suspect a > problem though! > > We've tried putting the meta directory on alternate partitions (note: > this isn't a good idea with btrfs). It hasn't really done much in some > of the tests we've done, but we weren't looking at testing this specific > scenario. > > I think the bigger question is, what problem are you trying to solve? > Are you noticing lots of fragmentation? Slow performance with 4MB > writes? slow performance with small IO? > Agreed...and, since there's not really a problem I'm addressing at this point, sticking with the defaults is my best bet. I was merely curious as to how to get the maximum performance. If I see problems, maybe I'll dig into it a big, but, at this point, there's no reason to mess with the defaults, at least in my scenarios. -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
