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]

RE: eCos jffs2 garbage collection thread + fix


> -----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]