| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
On Wed, 2003-09-24 at 00:59, Cahill, Ben M wrote: > > -----Original Message----- > > From: Luciano Chavez [mailto:lnx1138@us.ibm.com] > > Sent: Tuesday, September 23, 2003 12:05 PM > > > > > > Ben, > > > > As I mentioned yesterday I have some initial code in the evms cvs for > > the ogfs fsim. It can be found under evms2/engine/plugins/ogfs. The > > initial probing and claiming of ogfs volume was easy. I did rely on > > existing functions from the fs ondisk and cluster ondisk sources. I > > think I only changed one of the ogfs sources when I copied to remove a > > #ifdef #else section. Otherwise, they are intact. > > That sounds great! > > Which files or directories are you talking about with "fs ondisk and cluster ondisk sources"? > src/locking/modules/memexp/cluster_config.h src/locking/modules/memexp/cluster_ondisk.c src/include/global.h src/include/osi_endian.h src/fs/ogfs_ondisk.h src/fs/ondisk.c src/stomith/module/stomith.h I copied the above sources pretty much unmodified except for a #if defined(HELPER_PROGRAM) in ondisk.c but I think I'll use the original version and just define HELPER_PROGRAM in the makefile. The ogfs sources were copied to the evms2/engine/plugins/ogfs directory to allow building the FSIM independent of having opengfs source. I was very pleased that the sources I needed to probe for metadata was this limited and clean to use. The functions I use in the above source are mainly to identify on-disk meta and not update it (unmkfs will be an exception). I want to do what the other FSIMs do and look for the external tools and use them for such things as expand and mkfs as this offers the most flexibility and the least duplication of code. > Are you able to use the user-space mkfs.ogfs, ogfs_expand, etc. utilities in their entirety, or are you getting inside the utilities, extracting "existing functions" as needed, from within the utilities (i.e. I'm not quite sure I understand what you mean by "existing functions" -- just a few functions, or the entire utilities)? > > Do you need to somehow build them within the EVMS context, or do they work straight out of the OGFS build environment (you mentioned "copying")?? <snip> > You're right. cidev is a memexp-exclusive thing. OpenDLM may use something else (although Stan's initial implementation *does* use a cidev ... I'm hoping that we can get away from doing that). > > You could perhaps draw the line and say that the cidev is "cluster" (which it really is), rather than "disk volume" configuration, and not worry about it from the EVMS point of view ... just a thought. > > We still have some thinking to do about journal assignments with a non-memexp setup. The burning question: Is journal assignment a "cluster" thing, or a "filesystem" thing? It's both, of course. It's where the worlds collide. Keep thinking about whether/how EVMS could handle that. (comments from others??) > > Slightly OT: I've been thinking that journal selection could be part of the mount command line (like the hostdata= info). Specify it if you want a particular journal (particularly for external journals), or leave it out if you'll accept dynamic assignment. With this approach, maybe we wouldn't need to worry about colliding worlds. It would probably work best if *all* machines specified it, or *all* machines did not. Otherwise, a particular journal might get grabbed by another machine. Just some thoughts ... probably some gotchas in there somewhere. I think to start with, I will just handle only filesystem configuration and not cluster related config which means limiting the capability to mkfs, unmkfs (nuking the fs), expand, claiming OGFS volumes so they can not be mistakingly used or mounted (in the case of journals and the cidev) and possibly offering additional function like reclaiming freemeta blocks as offered through ogfs_tool. <snip> > OGFS can only expand. I don't think anybody cares about the difficult job of shrinking (do they?). And, the fs must be *mounted* in order to do it via ogfs_expand (see man page). Likewise for ogfs_jadd. The fs can be online and in use when the expansion/jadd occurs (executed by only one node, of course), and is automatically detected by the fs code (ogfs.o) on each node (including the one executing the expansion). > Cool. It would still require a volume rediscover afterwards on the other nodes by executing evms_activate I believe. In the hopefully near future, the engine will initiate the rediscover of volumes on other nodes for an expand. > > > > So, in short the easiest part of recognizing the various OGFS > > volumes is > > done and now to figure out how to configure new ones is next. Any > > thoughts on what you expect in terms of the extent of what the FSIM > > should offer for OGFS configuration. In other words, do you think it > > should offer everything the command line does, a subset or more? > > As mentioned above, I think *you* know more about what EVMS likes to, or should, handle. Comments from others? > I'll use my judgement but wanted to field questions to determine your expectations. -- regards, Luciano Chavez lnx1138@us.ibm.com http://evms.sourceforge.net ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opengfs-devel mailing list Opengfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opengfs-devel