| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
Thanks for your help. Stan On Fri, 2003-06-13 at 20:08, Dominik Vogt wrote: > (Moved this thread to the mailing list. Hope that is all right > with everybody.) > > On Fri, Jun 06, 2003 at 10:42:23AM -0700, Ben Cahill wrote: > > Two of my Intel colleagues in China, Fei and Stan, are interested in > > taking on some development work for OpenGFS . . . after an IRC chat with > > them a couple of evenings ago, they sent me a note describing their > > biggest interests, below. > > > > Of the long term suggestions, Luciano Chavez of IBM seems to be handling > > EVMS, and Becker(?) has been looking into 2.5 porting. > > > Dominik, could you use some help with the locking situation? Would it > > help to have Fei and Stan try to get OpenDLM working as a lock harness > > method, as a first step? > > Yes, perhaps we should just start OpenDLM integration to see what > abstractions we have to make in the current code. There are also > a couple of locking related bug reports in the bug tracker. > > > For the short term suggestions . . . > > > > . . . What do you think of the defrag tool idea? > > > -----Original Message----- > > From: Fei, Fei > > Sent: Thursday, June 05, 2003 9:35 PM > > To: Cahill, Ben M > > Cc: Wang, Stanley > > Subject: [OGFS] Long term interests and short workable items for us > > > > Yesterday, we two have a short talk after our IRC meeting and have some > > ideas merged here. In a nutshell, we have some long-term interests and > > some short-term items listed below. Hope you can help use review and > > clarify. > > > > > > > > Basically, there are three big areas we (Stan and Felix) feel interested > > in long term. > > > > 1. Lock Problem. > > > > Lock is always a big topic in OpenGFS. About this, we are interested in > > two domains, both of which are about re-design the arch. > > > > a. Separate lock part with FS. > > > > b. Using OpenDLM or something else as a lock protocol in OpenGFS > > > > 2. Volume Management. > > > > Since no-pool is the default configuration of OGFS, we need a new volume > > management layer in OGFS. > > > > Basically, we will try to enable > > > > a. EVMS > > > > b. LVM2 (in Kernel 2.5) > > > > as volume management layer. > > > > 3. Port to kernel 2.5 > > > > Port to new kernel can help us have the opportunity to reconstruct OGFS > > CVS directory. So we can have OGFS FS (kernel) and OGFS tools separated. > > Also this is the opportunity to have new lock layer involved in. > > > > > > > > > There are also some short-term works at hand which we are interested in. > > We find these *flaws* from project documents but not from code. So we > > are not sure whether is done or just disappeared. Could you please help > > to review for us? > > > > 1. If the system is short of free metadata block, some free data > > block will be converted to metadata block. But no reverse back if the > > metadata block is released. > > > > 2. If the selected resource group is short of free metadata block, > > the system should select some other resource group which has more free > > metadata block instead of convert the former one's data block into meta > > ones. This is actually connected with first item. > > > > 3. When the file is a tiny one, the inode and data will fit into > > one block. And then if will become a tree if file grows. But it will not > > be back anymore even the file is truncated small. > > > > 4. Extendible hashing table header will grow after dentry grows. > > Like from 2 bits (4 entries) to 3 bits (8 entries). But it never > > shrinks. > > > > 5. If the extendible hash table leaves spitted, it never merges > > again even it's shrunk. > > > > 6. Journal file system part will use transaction sequence number. > > If it rewinds, it will get some problem. > > > > 7. Dentry will have useless padding area if successor dentry was > > deleted. > > > > 8. write() length <= resource group size that is will be problem > > if the ogfs volume is small since the in one ogfs volume will have 10 > > resource group at least. > > > > 9. For 1, 3, 4, 5, 7 items, they are like *defrag* things. We plan > > to enhance the "ogfs_tool" to fulfill them. However, they should be > > available for mounted system since SAN system seldom umount file system. > > All these problems are still in the code. I have written the > design document which mentions most or all of them only recently. > For an up to date list of known problems, consult the bug tracking > system on sourceforge. > > Bye > > Dominik ^_^ ^_^ > > > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Opengfs-devel mailing list > Opengfs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opengfs-devel -- Opinions expressed are those of the author and do not represent Intel Corporation ------------------------------------------------------- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Opengfs-devel mailing list Opengfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opengfs-devel