headers
Pasi Kärkkäinen | 1 Dec 2008 09:59
Picon
Picon
Favicon

Re: GFS2 on CentOS v5.2

On Sun, Nov 30, 2008 at 07:12:07PM +0200, Mikko Partio wrote:
> On Sun, Nov 30, 2008 at 6:34 PM, Jos Vos <jos <at> xos.nl> wrote:
> 
> > On Sun, Nov 30, 2008 at 01:01:09PM +0100, Shaun Mccullagh wrote:
> >
> > > I'm setting a GFS cluster on CentOS v5.2 with latest rpms.
> > >
> > > I think gfs2 is still at the Technology Preview level.
> > >
> > > Does this mean I should use gfs in production at the moment?
> >
> > Yes, this is true for RHEL 5.2, but GFS2 is will be changed to
> > production level in RHEL 5.3 (now in beta).
> 
> 
> There has to be some drastic changes in GFS2 between 5.2 and 5.3 since I
> still haven't seen a single post in this list stating that GFS2 in 5.2 (or
> previous RHEL versions) is working for them. :)
> 

Then you haven't been paying enough attention ;) 

http://www.mail-archive.com/linux-cluster <at> redhat.com/msg04706.html

-- Pasi
Permalink | Reply | 4 comments |
headers
Jos Vos | 1 Dec 2008 10:03
Picon

Re: GFS2 on CentOS v5.2

On Mon, Dec 01, 2008 at 10:59:47AM +0200, Pasi Kärkkäinen wrote:

> On Sun, Nov 30, 2008 at 07:12:07PM +0200, Mikko Partio wrote:
> > 
> > There has to be some drastic changes in GFS2 between 5.2 and 5.3 since I
> > still haven't seen a single post in this list stating that GFS2 in 5.2 (or
> > previous RHEL versions) is working for them. :)
> > 
> 
> Then you haven't been paying enough attention ;) 
> 
> http://www.mail-archive.com/linux-cluster <at> redhat.com/msg04706.html

I don't see how this answer negates Mikko's statement...

--

-- 
--    Jos Vos <jos <at> xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204
Permalink | Reply | 3 comments |
headers
Geoff Galitz | 1 Dec 2008 10:29

GFS on Centos


We are investigating deploying GFS across a small pool of servers:

Centos 5.1 x86_64
GigE Networking

The data will consist of approximately 400GB of small JPG files accessed by
an inhouse java app.  The entire cluster is 50 machines but only 7 will
require access to this data repository.

GFS2 is not ready, yet... but my main question is, is it worth it to wait
for GFS2?  We are also looking at glusterfs.  

Our goal is:

- low administrative (sysadm) overhead
- good performance when accessing lots of small files (<100Mb)

Geoff Galitz
Blankenheim NRW, Deutschland
http://www.galitz.org
Permalink | Reply | 2 comments |
headers
Steven Whitehouse | 1 Dec 2008 10:29
Picon
Favicon

Re: GFS on Centos

Hi,

On Mon, 2008-12-01 at 10:29 +0100, Geoff Galitz wrote:
> 
> 
> We are investigating deploying GFS across a small pool of servers:
> 
> Centos 5.1 x86_64
> GigE Networking
> 
> The data will consist of approximately 400GB of small JPG files accessed by
> an inhouse java app.  The entire cluster is 50 machines but only 7 will
> require access to this data repository.
> 
> GFS2 is not ready, yet... but my main question is, is it worth it to wait
> for GFS2?  We are also looking at glusterfs.  
> 
> Our goal is:
> 
> - low administrative (sysadm) overhead
> - good performance when accessing lots of small files (<100Mb)

Depending on just how small the files are, then possilbly it might be
worth your while. A few tens of Mb is big enough to be considered
"large" I think, but if you are thinking of running something like an
email server with maildir spools, then it would certainly be worth
waiting for GFS2,

Steve.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven Whitehouse | 1 Dec 2008 10:32
Picon
Favicon

Re: GFS2 on CentOS v5.2

Hi,

On Mon, 2008-12-01 at 10:03 +0100, Jos Vos wrote:
> On Mon, Dec 01, 2008 at 10:59:47AM +0200, Pasi Kärkkäinen wrote:
> 
> > On Sun, Nov 30, 2008 at 07:12:07PM +0200, Mikko Partio wrote:
> > > 
> > > There has to be some drastic changes in GFS2 between 5.2 and 5.3 since I
> > > still haven't seen a single post in this list stating that GFS2 in 5.2 (or
> > > previous RHEL versions) is working for them. :)
> > > 
> > 
> > Then you haven't been paying enough attention ;) 
> > 
> > http://www.mail-archive.com/linux-cluster <at> redhat.com/msg04706.html
> 
> I don't see how this answer negates Mikko's statement...
> 
The reason that you've not seen reports from people running 5.2 and 5.1
(whether RHEL or CentOS) is that we've been discouraging people from
using those versions. The 5.3 beta version of RHEL is the best one for
eval purposes at the moment, also Fedora would be a good distro to test
if you want something thats most uptodate,

Steve.
Permalink | Reply | 2 comments |
headers
Shaun Mccullagh | 1 Dec 2008 10:59
Picon
Favicon

RE: GFS2 on CentOS v5.2

Many thanks for the clear info.

I've installed kmod-gfs and cman-2.0.84. I notice that kmod gfs2 is loaded when I start service cman.
I see that gfs2.ko is part of kernel-2.6.18-92.1.18.el5, which is the kernel in use on the system. 

Is this expected behaviour?

When I exec  service gfs start     should I expect gks.ko to be loaded?

Thx Again....

Shaun

-----Original Message-----
From: linux-cluster-bounces <at> redhat.com [mailto:linux-cluster-bounces <at> redhat.com] On Behalf Of
Steven Whitehouse
Sent: maandag 1 december 2008 10:32
To: linux clustering
Subject: Re: [Linux-cluster] GFS2 on CentOS v5.2

Hi,

On Mon, 2008-12-01 at 10:03 +0100, Jos Vos wrote:
> On Mon, Dec 01, 2008 at 10:59:47AM +0200, Pasi Kärkkäinen wrote:
> 
> > On Sun, Nov 30, 2008 at 07:12:07PM +0200, Mikko Partio wrote:
> > > 
> > > There has to be some drastic changes in GFS2 between 5.2 and 5.3 
> > > since I still haven't seen a single post in this list stating that 
> > > GFS2 in 5.2 (or previous RHEL versions) is working for them. :)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steven Whitehouse | 1 Dec 2008 11:07
Picon
Favicon

RE: GFS2 on CentOS v5.2

Hi,

On Mon, 2008-12-01 at 10:59 +0100, Shaun Mccullagh wrote:
> Many thanks for the clear info.
> 
> I've installed kmod-gfs and cman-2.0.84. I notice that kmod gfs2 is loaded when I start service cman.
> I see that gfs2.ko is part of kernel-2.6.18-92.1.18.el5, which is the kernel in use on the system. 
> 
> Is this expected behaviour?
> 
> When I exec  service gfs start     should I expect gks.ko to be loaded?
> 
> Thx Again....
> 
> Shaun
> 
That all sounds about right. GFS2 was made into a kmod and then more
recently its become part of the standard kernel again. So if you have an
uptodate kernel then it should be just like any other fs. GFS is a kmod
and will remain so.

The init scripts do load some of the modules early, and also in older
kernels there was a dependency between GFS and GFS2 since they both
shared the same lock modules. In recent kernels the lock modules are no
longer shared between GFS and GFS2, in fact in Fedora lock_nolock no
longer exists for GFS2 since its been merged into GFS2 itself. There is
a plan to merge lock_dlm into GFS2 as well which will solve a problem
thats been flagged up with selinux and init scripts (mount shouldn't
need to load modules directly, but GFS2's mount does have to do this
while lock_dlm is a separate module).
(Continue reading)

Permalink | Reply | 0 comments |
headers
NM | 1 Dec 2008 14:33
Picon
Gravatar

#462910 -- how's postgres-8.sh even supposed to work?


See https://bugzilla.redhat.com/show_bug.cgi?id=462910

Just wondering how that script is even supposed to work in the first 
place, and why it uses sudo instead of su. Any clues? I'm having a hard 
time with this trying to get it to work properly.
Permalink | Reply | 0 comments |
headers
Jeff Sturm | 1 Dec 2008 20:19
Favicon

RE: GFS on Centos

1) What is the ratio of file reads to writes/creates for your Java
application?

If this is very high (say 100:1 or more) GFS may work just fine.  In our
experience we have the most trouble with write contention, esp. on
shared directories.

2) How much time elapses (statistically speaking) between consective
reads of the same file on the same node?

If this is low enough you may be able to tune demote_secs such that
glocks can be reused for file accesses.  If you have too many files to
cache the inodes or glocks in memory, you may be better off tuning
demote_secs and glock_purge to keep the numbers small, and accept the
overhead that each file access is going to have to obtain a lock.

3) What does your directory layout look like?  How many files are you
placing in the same directory?

You'll probably want to avoid very large directories.  If e.g. all files
are kept in a single directory, you'll get write contention that would
effectively limit file creates to a single node at a time.

For directories with a high percentage of file creates, we've had better
luck establishing one directory per node, such that each node can read
files created by others, but only write to their own directory.  (And
session affinity to reduce the frequency of cross-node reads.)

Good luck.  The above advice is based on empirical evidence from our own
performance testing and other net wisdom, and the positive results we
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tiago Cruz | 1 Dec 2008 21:13
Gravatar

fence_vmware on rhel 5.3

Hello guys,

Someone can send me one use's example from fence_vmware?

This can't show on conga and I'm confuse to use it on command line...

It's not perl any more, python now :-)

[root <at> dcrs6037 ~]# fence_vmware -h
Usage:
        fence_vmware [options]
Options:
   -o <action>    Action: status, reboot (default), off or on
   -a <ip>        IP address or hostname of fencing device
   -l <name>      Login name
   -p <password>  Login password or passphrase
   -S <script>    Script to run to retrieve password
   -x             Use ssh connection
   -k <filename>  Identity file (private key) for ssh 
   -n <id>        Physical plug number on device or name of virtual machine
   -A <ip>        IP address or hostname of managed VMware ESX (default localhost)
   -L <name>      VMware ESX management login name
   -P <password>  VMware ESX management login password
   -B <script>    Script to run to retrieve VMware ESX management password
   -q             Quiet mode
   -v             Verbose mode
   -D <debugfile> Debugging to output file
   -V             Output version information and exit
   -h             Display this help and exit
(Continue reading)

Permalink | Reply | 4 comments |

Gmane