| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
> -----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"? 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")?? > > I've had many thoughts on what and how I am going to support the > configuration options for ogfs. > > Most of the other FSIMs simply present options to a user for > things like > mkfs and exec the mkfs or resize tools with the proper command line > options. OGFS is somewhat unique in that besides mkfs.ogfs to just > create a filesystem (and the fact that it reads a file for additional > info) it's only part of the configuration process since > ogfsconf is also > needed to configure cluster information. Yes. See below. > > Asking the user for the input for the conf files will be tricky as it > may be difficult to be as flexible as the conf files when asking. For > example, I can present a multi-selection list of possible external > journals but not sure how to specify the node index for each on input > for the mkfs. Also, not sure how to be flexible enough to > also deal with > a mix of internal and external journals. I guess a lot depends on how much you want EVMS to cover. Do you want it to do *everything*, or allow some of the configuration to be done outside of EVMS? I think you're in a better position to make that kind of judgment than I am, since I'm still an EVMS novice (very low hours .... sorry about that!). See below. > > Asking for the other things like the choice for the cidev and lock > protocol and that is easy enough. > > The same problem comes with configuring the cidev. datadev, lockdev, > cbport, timeout, stomith, name seem easy enough. The node: > entries with > all their separate fields are a different story. Still scratching my > head on that one. > > The other thing that kind of bothered me was the cidev seemingly too > coupled with memexp. How will configuration be handled to deal with > opendlm or something else instead? 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 am currently reading the ondisk documents and the other > files in docs > in order to understand gathering statistics to provide simple > information such as current, minimum, and maximum filesystem size for > expand and shrink (can ogfs shrink) and what things must be done for > resize (offline only?). 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). > > 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? > > Oh, and thanks for the nice documentation in the docs directory. That > certainly helps. Thanks for saying so. I'm glad it's getting some use. Lots more to do. Make sure you check those man pages, too. -- Ben -- Opinions are mine, not Intel's > > -- > regards, > > Luciano Chavez > > lnx1138@us.ibm.com > http://evms.sourceforge.net > >
<<winmail.dat>>