Re: Outage Notification - 2009-01-03 04:16 UTC
On Fri, 2 Jan 2009, Mike McGrath wrote: There is a current unscheduled outage starting at 2009-01-03 UTC, which will last for an unknown amount of time. Should be over now, tech replaced mobo and we're back in business. Happy new year all! -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
calling out for a sponsor
Hello list, im shouting out for a sponsor, is someone willing to sponsor me? -- Mit freundlichen Grüßen, / with kind regards, Sascha Thomas Spreitzer http://spreitzer.name/ ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: calling out for a sponsor
On 2009-01-03 10:29:18 PM, Sascha Thomas Spreitzer wrote: im shouting out for a sponsor, is someone willing to sponsor me? Hey, what type of things are you interested in working on (as in, what groups are you looking for sponsors for)? Thanks, Ricky pgpI0yml9d2n4.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Disk IO issues
On Wed, Dec 31, 2008 at 02:42:27PM -0600, Mike McGrath wrote: Lets pool some knowledge together because at this point, I'm missing something. I've been doing all measurements with sar as bonnie, etc, causes builds to timeout. Problem: We're seeing slower then normal disk IO. At least I think we are. This is a PERC5/E and MD1000 array. When I try to do a normal copy cp -adv /mnt/koji/packages /tmp/ I get around 4-6MBytes/s That's sucky. When I do a cp of a large file cp /mnt/koji/out /tmp/ I get 30-40MBytes/s. If I cat /dev/sde /dev/null I get between 225-300MBytes/s read. That's about what I would expect for straight block reads. The above tests are pretty consistent. /dev/sde is a raid5 array, hardware raid. Remember, RAID 5's worst performance is for writes. In your 14-drive array, it has to calculate parity across all the drives, then write the data across all the drives. As long as it's pure writes (e.g. not read/modify/write) it's not so bad, but still slower than you might think. What ext3 journaling options are enabled (e.g. what does 'mount' say)? If it's data=ordered (the default), that's OK. If it's data=journal, then all the data gets written twice (first to the journal, then the journal to the disk), which is really really slow, and the size of the journal would really make a difference too. RAID controllers also tend to benefit from using the noop scheduler, which effectively defers the scheduling to the RAID controller. Note that cp doesn't fdatasync(), so the I/Os will be scheduled, but not necessarily completed, when cp returns. Which might make your numbers even more optimistic than they really are. :-( -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Disk IO issues
On Sat, Jan 03, 2009 at 06:32:38PM -0600, Matt Domsch wrote: What ext3 journaling options are enabled (e.g. what does 'mount' say)? If it's data=ordered (the default), that's OK. If it's data=journal, then all the data gets written twice (first to the journal, then the journal to the disk), which is really really slow, and the size of the journal would really make a difference too. For an NFS server (assuming that you aren't exporting as async) data=journal can give you better performance than anything else actually. The NFS howto has a brief note in the performance section about this. Kostas ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Disk IO issues
On Sun, Jan 04, 2009 at 03:02:55AM +, Kostas Georgiou wrote: On Sat, Jan 03, 2009 at 06:32:38PM -0600, Matt Domsch wrote: What ext3 journaling options are enabled (e.g. what does 'mount' say)? If it's data=ordered (the default), that's OK. If it's data=journal, then all the data gets written twice (first to the journal, then the journal to the disk), which is really really slow, and the size of the journal would really make a difference too. For an NFS server (assuming that you aren't exporting as async) data=journal can give you better performance than anything else actually. The NFS howto has a brief note in the performance section about this. Yes, if the slowness is seen by applications on the client side of the NFS server, data=journal on the NFS server can help. Mike, your tests were all on the local file system, not across an NFS connection, right? data=journal can only buffer up to the size of the journal. Given the comments about speed with large files, unless the journal is specifically tuned to be large enough to handle them, no dice. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
