GFS2 and Gentoo

[olli.bo]

Hi,

is there anywhere a HowTo or a Documentation how to install GFS2 especially on Gentoo. There doesn't seem to be any ebuilds for tools like mkfs.gfs2...!?
I tried to compile the sources found on sources.redhat.com but after getting several error I gave it up...
Is there anyone got it running?

thx
olli

[nixnut]

Moved from Installing Gentoo to Other Things Gentoo.
Not about getting gentoo installed, so moved here.
_________________
Please add [solved] to the initial post's subject line if you feel your problem is resolved. Help answer the unanswered

talk is cheap. supply exceeds demand

[thepustule]

Yes, well, GFS2 still isn't in Gentoo. It's been in the kernel for ages already - since 2.6.19. But according to https://bugs.gentoo.org/show_bug.cgi?id=184850 it is believed to be not production ready by gentoo devs. What gives?

[crquan]

wow, I have tried to work on gfs2-2.01.00.ebuild and the work not finished:

1. cluster-2.xx.xx series have too many differences with cluster-1.xx.xx, its homepage (http://sources.redhat.com/cluster/) recorded them as "Cluster Components - Old" and "Cluster Components - New", so could appear in the new gfs2-2.xx.xx.ebuild (and cman and others);
   
2. gfs2-2.01.00.ebuild (https://bugs.gentoo.org/show_bug.cgi?id=201132) could install the gfs2 component of redhat cluster now, only with ebuild xx.ebuid digest merge;
   
3. some gfs's dependencies such as gfs-header,cman-header is not needed any more, gfs2 has been merged into the mainline kernel and cman redesigned with openais library dependency, the original cman kernel module not needed any more;
   
4. openais-0.80.3.ebuild (https://bugs.gentoo.org/show_bug.cgi?id=160847) works;
   
5. while compiling the cluster-2.01.00, use 'make userland' instead of 'make all'; but there're still circular dependcies, cman depends on ccs, css depends on cman-lib, that's a part of cman;
   

[XioXouS]

Do you also have bug reports (and ebuilds) for the other packages - cman, ccs, fence, etc.

I was hoping to work on these as well, but if you've already got some work on them done I'd rather start from there.

The devs seem to want to keep things into separate ebuilds, which does seem to be more in the gentoo spirit. For instance, I don't really care about rgmanager, and so far as I know, I don't need it - sys-cluster/heartbeat will do the trick. I could also do without conga and the other gui stuff.

[crquan]

please pay attention on #184850, the resolution is neither simple nor deterministic, you could start your own and communicate.

[XioXouS]

So far today I got ccs, cman, cman-lib, dlm, fence (with group), gnbd, and rgmanager ebuilds all done.

The cman init script needs some checking, so when I get that done I'll add a bug report for all of them.

Also, I need to do the gfs2 one. Probably by the end of tomorrow I'll have something to share with everyone.

[XioXouS]

https://mywebspace.wisc.edu/bpkroth/web/gentoo/fs-cluster-ebuilds/fs-cluster_ebuilds.tar.bz2

I'll break these back out into bugs later on tonight.

I haven't tested rgmanager or any of the gnbd stuff.

Also, there's a note about how to get gfs-kernel working in one of the docs files. I haven't tested that yet either.

Everything builds though. I now have a gfs2 cluster up and running

[crquan]

refer to:
https://bugs.gentoo.org/show_bug.cgi?id=203916

But now I still have question on why not using a single ebuild for redhat cluster project?

Let's use the single gcc ebuild for example, all other distros provide gcc with multiple packages such as in RHEL:

[XioXouS]

Yeah, I won't argue with that. But one of the devs on one of the bugs related to this basically said, no to the single ebuild idea and I kinda would like this to be placed into portage (obviously not marked stable), just so others can start testing, so I thought I'd play along. I think part of the reason is to make upgrading from GFS(1) to GFS2 easier for those that are already using the spilt ebuild model. I know that the ondisk formats differ, but the userland tools are the same and compatible. In fact mount.gfs is just a symlink to mount.gfs2 by default.

BTW, I updated the init scripts in that tar of mine. It's not updated on the bug (#184850) yet.

[XioXouS]

FYI, there are still bugs in GFS2. I found at least one deadlock situation and RedHat's bugzilla is crawling with more. However, with these ebuilds the gfs-kernel module now builds against recent kernels (with an export symbols caveat found in usage.txt) and the tool set is the same so I've been testing GFS1 for the past several days instead. It seems to be pretty solid.

[EnderWiggin]

I'm a little confused by your ebuild tarball. You provide ebuilds for both sys-fs/gfs-2.01.00 and sys-fs/gfs2-2.01.00 which contain slightly different syntax, etc. Which ebuild are you using?

[XioXouS]

I'm personally using gfs-2.01.00. Like reiserfs is different from reiser4 and is not compatible, gfs2 is different from gfs. The trouble is that the cluster-1.x suite of userland tools that are required to use gfs and to build its kernel module (which is not included) don't build against newer kernels anymore. The cluster-2.x suite of tools is a newer framework for those tools that are compatible with both gfs and gfs2 and provides a kernel module for gfs that compiles against newer kernels. The reason for this is that it uses the dlm locking module which is now included in the mainline kernel. The only catch is that in order to use it you need to export a few extra symbols (see usage.txt for details). So in short, you're wondering why there are two separate ebuilds for gfs and gfs2. The answer is that they are two separate pieces of software.

Note: Unlike reiserfs and reiser4 (afaik) there happens to be a gfs2_convert tool that will make a gfs fs into a gfs2 fs. It works, but I've found deadlock situations with the locking code for gfs2, so I wouldn't use it in a production system yet. However, this does mean that when gfs2 becomes stable, you'll have an easy upgrade path.

[alexxy]

Hi all =)

Ive try to use gfs2 + clvm on cluster of 8 servers
lvm contains 2 volume groups
system ( not clustered )
data ( clustered )
unfortunately after i reboot this cluster it can't boot again
it stops booting on starting clvm
i try both locking types clustered internal and external
_________________
Gentoo Team Russia
Working on Gentoo for iPAQ hx4700

[thepustule]

I have a CoRAID device in my rack, and 3 Gentoo systems with aoe support ready to go, to test gfs2 the day it shows up in portage unstable.

.... waiting....

[zoltak]

What is the latest kernel GFS will compile against?

I really want to run GFS1 with Xen but the latest kernel won't compile against GFS1 and you need a fairly recent kernel for the most recent version of Xen!

[XioXouS]

With the ebuild tarball I posted earlier, I'm running GFS1 on hardened-sources-2.6.23-r4.

[zoltak]

[XioXouS]

I haven't tried. And given the recent kernel exploits, I'm quite happy to be running hardened. Report back your results though.

[zoltak]

[XioXouS]

usage.txt says it requires a kernel >= 2.6.19, so they should, but I really don't know. Give it a shot and let us know how it went. Don't forget to add the exported symbols.

BTW, on the linux-cluster mailing list the main GFS/GFS2 developer said they would be reworking the code in the future to remove that requirement. It sounded like it basically amounted to a copy and paste of the locking code that would have been provided by the exported symbols. I don't know when that will be released though.

[zoltak]

[XioXouS]

Sorry, I should have explained that better. It's in the /usr/share/docs/gfs* directory after you emerge the ebuilds. That link is just a set of ebuilds to be used in your portage overlay directory. Here's a link to get to it online:

http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/cluster/doc/usage.txt?rev=1.37&content-type=text/plain&cvsroot=cluster

[zoltak]

[XioXouS]

cman depends on openais now, so yes.

gnbd* and rgmanager are optional depending upon your setup.

You should really only need to do the following: