Hi,
On Thu, 2009-09-24 at 18:04 +1000, yu song wrote:
> HI,
>
> I have been seeing a similar GFS2 performance issue.
>
> when I did a file copy (4.3G) from a node to another node's gfs2
> filesystem, it shows me 793.4KB/s . however, same file copy to the
> same node but non gfs2 file system, it
HI,
I have been seeing a similar GFS2 performance issue.
when I did a file copy (4.3G) from a node to another node's gfs2 filesystem,
it shows me *793.4KB/s* . however, same file copy to the same node but non
gfs2 file system, it gives me *53.6MB/s*.
not too sure why? it seems like gfs2 has a pe
Hi,
On Fri, 2009-07-10 at 09:07 -0700, Peter Schobel wrote:
> So, in your opinion, there are no known issues which would cause this
> particular problem and this poor performance while deleting files
> should be considered normal?
>
> Thanks,
>
> Peter
> ~
>
It depends just how bad it is... it
> -Original Message-
> From: linux-cluster-boun...@redhat.com
[mailto:linux-cluster-boun...@redhat.com]
> On Behalf Of Peter Schobel
> Sent: Friday, July 10, 2009 11:49 AM
> To: linux clustering
> Subject: Re: [Linux-cluster] rm -r on gfs2 filesystem is very slow
>
So, in your opinion, there are no known issues which would cause this
particular problem and this poor performance while deleting files
should be considered normal?
Thanks,
Peter
~
On Fri, Jul 10, 2009 at 8:56 AM, Steven Whitehouse wrote:
> Hi,
>
> On Fri, 2009-07-10 at 08:49 -0700, Peter Schobe
Hi,
On Fri, 2009-07-10 at 08:49 -0700, Peter Schobel wrote:
> The initial writing is done via the network by checking out source
> trees from a Perforce repository. Beyond that, source trees are
> compiled causing the creation of many object files.
>
> Multiple source trees will be compiled from
The initial writing is done via the network by checking out source
trees from a Perforce repository. Beyond that, source trees are
compiled causing the creation of many object files.
Multiple source trees will be compiled from the same node or from
multiple nodes.
This performance problem exhibit
Hi,
On Fri, 2009-07-10 at 07:42 -0700, Peter Schobel wrote:
> When we did our initial proof of concept, we did not notice any
> performance problem of this magnitude. We were using OS release 2. Our
> QA engineers passed approval on the performance stats of the gfs2
> filesystem and now that we ar
When we did our initial proof of concept, we did not notice any
performance problem of this magnitude. We were using OS release 2. Our
QA engineers passed approval on the performance stats of the gfs2
filesystem and now that we are in deployment phase they are calling it
unusable.
Have there been
We found with GFS2 on RHEL5.3 the same issue, and although we did not
resolve it (and are migrating to NFS+SAN instead), we were able to partially
mitigate it with several suggestions from either RedHat's support or from
the cluster list:
1. disable LS color output (http://kbase.redhat.com/faq/docs
I've just had bad experience all around with GFS2. You may want to try GFS1
and play with the tunable parameters.
On Wed, Jul 8, 2009 at 1:58 PM, Peter Schobel wrote:
> I am trying to set up a four node cluster but am getting very poor
> performance when removing large directories. A directory a
On Wed, Jul 08, 2009 at 01:58:30PM -0700, Peter Schobel wrote:
> I am trying to set up a four node cluster but am getting very poor
> performance when removing large directories. A directory approximately
> 1.6G in size takes around 5 mins to remove from the gfs2 filesystem
> but removes in aroun
I am trying to set up a four node cluster but am getting very poor
performance when removing large directories. A directory approximately
1.6G in size takes around 5 mins to remove from the gfs2 filesystem
but removes in around 10 seconds from the local disk.
I am using CentOS 5.3 with kernel 2.6
13 matches
Mail list logo
