| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
> -----Original Message----- > From: opengfs-users-admin@xxxxxxxxxxxxxxxxxxxxx > [mailto:opengfs-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf > Of Angela Palladino > Sent: Thursday, June 24, 2004 8:39 AM > To: opengfs-users@xxxxxxxxxxxxxxxxxxxxx > Subject: RE: [ogfs-users]kernel 2.4.24 > > Hi again :) > > Three things: > 1- I've patched 2.4.24 kernel with 2.4.22 patch, I got some > "hunk failed", > but I tried the same to campile it and it worked; then I > compiled openGFS > 0.3.0 with this kernel, installed it and it works great :). Thanks for the report, and congratulations. Can you tell us which hunks failed? Were you able to manually patch those hunks? (that is, did you manage to get all of the changes into the kernel source??) > 2- I have the need to mount four partitions of my disc array, > I have to do > the two little partitions (cluster information and external > journal) on > each one? In this case do I have to do a "ogfsconf -c > ogfscf.cf" for each disk? Do you mean that you are combining 4 partitions into a single filesystem? If so, you need a volume manager (e.g. EVMS, see HOWTO-evms, or the legacy "pool" volume manager, see HOWTO-generic) to combine the 4 partitions into a single virtual device ... OpenGFS must see the filesystem as a single device. Or do you mean that you need to create 4 fileystems? If so, then you *do* need a cidev for each filesystem. See below. For each separate OpenGFS fileystem, there needs to be one and *only one* cidev for the entire cluster. All partitions/devices (fileystem, journals, cidev) that OpenGFS uses are shared among all nodes in the cluster; for a single OGFS filesytem, there's no need for multiple cidevs, since all nodes can read a single cidev successfully and share its cluster config data. However, each filesystem (if you mount more than one OGFS filesystem at a time) is required to have its own cidev. OpenGFS/memexp uses the string of the path to the cidev as a unique identifier for each filesystem, therefore a single cidev may not be shared among multiple filesystems. OTOH, there needs to be one journal for each node in the cluster, for each filesystem. e.g. if you use 8 nodes (single filesystem), you must create 8 separate journals. They may reside within the filesystem device (internal journals), or on a separate device (external journals). The HOWTO-nopool tells how to set up a two-node cluster with one internal journal and one external journal. If you use more than two nodes, you must create more journals, but you don't need multiple copies of cidev or filesystem. If you have 8 nodes, and want to create 2 separate fileystems, you will need to create a total of 16 journals (and 2 cidevs, and 2 filesystem devices). BTW, I don't know if anyone has ever tried 8 nodes, it's just an example. Note that the filesystem device must appear as *one* device to the filesystem. If you have multiple partitions that comprise the filesystem, you must use some sort of volume manager to combine them into one virtual device. > 3- "memexpd" daemon can run on two servers simultaneosly? No. memexpd is the *single* lock storage server. It stores the lock data for the entire cluster. memexp (the lock module on each node) does not know how to use more than one lock storage server. Although, if you're mounting multiple OGFS filesystems, each filesystem *could* use a different memexpd server. But never more than one memexpd for a given filesystem. memexpd is a single point of failure (SPOF) that we're trying to overcome by using OpenDLM, instead of memexp, as the inter-node lock manager. See HOWTO-opendlm if you're interested in trying this out (most things are now in place, but still not very well tested, and currently slower than memexp). BTW, the cidev is not used by OpenDLM. memexp is an integrated lock/cluster-membership system, it relies on the cidev to tell it the cluster configuration. OpenDLM gets the cluster membership information from Linux-HA heartbeat or ccm services. Thanks for the progress report ... let us know if you have more questions. -- Ben -- Opinions are mine, not Intel's > > Thanks in advance > Angela > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Opengfs-users mailing list > Opengfs-users@xxxxxxxxxxxxxxxxxxxxx > https://lists.sourceforge.net/lists/listinfo/opengfs-users > > ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Opengfs-users mailing list Opengfs-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/opengfs-users