| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
> -----Original Message----- > From: opengfs-devel-admin@lists.sourceforge.net > [mailto:opengfs-devel-admin@lists.sourceforge.net]On Behalf Of Luciano > Chavez > Sent: Wednesday, September 24, 2003 11:40 AM > To: opengfs-devel@lists.sourceforge.net > Subject: Re: [ogfs-dev]FW: ogfs fsim > > > 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 > > > > 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. Thanks for the details ... all sounds good. Since those are on-disk things, they should not need to change with time, *unless* we change some on-disk formats. But I don't think we're planning to do anything like that soon. > > 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. Sounds very good. > > > 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. Just to clarify, OpenGFS does not require this *directly*. OpenGFS has no awareness of how a *volume* is made up, and does not need notification from the volume manager when a volume expands. OpenGFS determines that the *filesystem* has expanded, when it discovers that the version number on the resource group index file has changed. Of course, if EVMS/DM doesn't get set up correctly in a timely way (before OpenGFS discovers the new rindex), OpenGFS will expect to see a disk area that isn't visible to it yet! So, the safe thing to do would be to propagate *volume* expansion to all nodes before initiating *filesystem* expansion (and make sure that you initiate journal addition, if any, before filesystem expansion -- important for internal journals). > > I'll use my judgement but wanted to field questions to determine your > expectations. It sounds to me like you're on the right track. Thanks! -- Ben -- Opinions are mine, not Intel's > > -- > 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