This is the mail archive of the ecos-patches@sources.redhat.com mailing list for the eCos project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> -----Original Message----- > From: Andrew Lunn [mailto:andrew@lunn.ch] > Sent: Friday, December 31, 2004 11:09 AM > We received the copyright assignment. Thanks. Do you have time to > change the Patch to use filesystem locking instread of locking the > inode cache? > I have updated my patch. I solved the problem with a reference to the mte by saving a reference at mount time and make sure that this reference is valid after umount in case of multiple mount/umount (Not tested). It is maybe not the best solution but it seams to work. I believe that my initial implementation with a SUPERBLOCK mutex is not safe enough. The introduction of a gcthread without holding a file system lock requires that the spinlock.h and wait.h (functions spin_lock_init, spin_lock, spin_unlock, sleep_on_spinunlock, and wake_up) works and implements synchronisation of the lower level inocache. > > I also publish my temporary fix for a previously reported problem with > the > > garbage collection. (jffs2_write_fix). This fix is needed if garbage > > collection hits the erase block that the "write" is currently appending > data > > to. Jffs2 will otherwise report BUG in gc.c on line 1161. > > It's a workaround for the problem until someone can find the correct > > solution. > > Do you have any more ideas about this? No, I have not spent time on it. My workaround works... /Per
Attachment:
jffs2_gc_patch_v2
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |