| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
So if I understand correctly, as long as the user has the DM patch (whether it be part of my big patch, or something else), then the patch below will work. I don't know about the rest of the guys, but I don't have a problem making the dm patch a requirement (it is right now anyways by virtue of EVMS being the only cluster aware vol mgr). Ben, Dominik, everybody else? dm is in 2.5+ mainline, and I heard rumor of it possibly getting into 2.4 mainline, but if not, there are plenty of patchsets out there that include it, or the users can get it separately. --Brian Jackson On Tuesday 10 June 2003 04:41 pm, Luciano Chavez wrote: > On Mon, 2003-06-09 at 14:13, Cahill, Ben M wrote: > > Good snooping, Luciano. > > > > Would you be willing to investigate the extent of the problem (does it > > happen in yet other places?), and propose/implement a solution to this? > > > > If so, we can set you up as a developer. > > > > -- Ben -- > > Ben, > > After talking to Kevin Corry, he indicated this issue with a FS > accessing b_private for an active buffer head had come up before in the > jbd code used by ext3. > > It looks like the DM guys patched the jbd code to use a new void * field > they added to the buffer_head struct called b_journal_head. I wish they > had called it something more generic such as b_fs_data to indicate > filesystem dependent data. They replaced all references in the jdb code > for b_private with b_journal_head. > > Since I had applied the ogfs3 patch that included the DM patches, I made > the following changes to the ogfs source to use the b_journal_head > rather than b_private: > > Index: dio_arch.c > =================================================================== > RCS file: /cvsroot/opengfs/opengfs/src/fs/arch_linux_2_4/dio_arch.c,v > retrieving revision 1.9 > diff -r1.9 dio_arch.c > 63a64 > > > bh->b_journal_head = NULL; > > 216a218 > > > bh->b_journal_head = NULL; > > 487c489 > < bh->b_private = bd; > --- > > > bh->b_journal_head = bd; > > Index: dio_arch.h > =================================================================== > RCS file: /cvsroot/opengfs/opengfs/src/fs/arch_linux_2_4/dio_arch.h,v > retrieving revision 1.6 > diff -r1.6 dio_arch.h > 26c26 > < #define BH_BUFDATA(bh) ((ogfs_bufdata_t *)(bh)->b_private) > --- > > > #define BH_BUFDATA(bh) ((ogfs_bufdata_t *)(bh)->b_journal_head) > > This ended up fixing the oops problems I was running into with just one > node doing any significant I/O to the /ogfs volume. I need to add > another node and do further testing but this looks promising. > > What we now have to decide is who maintains the patch or if you want to > add your own field for your private data or use the DM one but with a > more generic name. Your input is needed. > > Let me know how I can help further. -- OpenGFS -- http://opengfs.sourceforge.net Home -- http://www.brianandsara.net ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ Opengfs-devel mailing list Opengfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opengfs-devel