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


On Fri, Dec 10, 2004 at 11:31:43AM +0100, Per Hedblom wrote:
> > I would probably move the mutex initialisation into jffs2_mount rather
> > than hide it inside the GC code. I missed it the first time i read the
> > code. The mutex does not belong to GC, it belongs more to the
> > cache. So put it there the linked list is initialised.
> 
> Actual my first attempt was to use the cyg_fs_lock to protect the cache
> during gc but I didn't succeed. Lately I discovered that I get strange
> pointer errors in the iput/ilockup/ievict code when I access the filesystem
> from different threads without the gc thread. It seams to work correct if I
> turn on my implementation of the cache lock (without gc thread).
> 
> After rechecking the cyg_fs_lock and the syncmode used for jffs2 it seams
> that my problem(s) could be related to the use of CYG_SYNCMODE_IO_FILE
> instead of CYG_SYNCMODE_IO_FILESYSTEM. It takes some time to run a test to
> see if it works better so it would be helpful with some comments on this
> before trying. 

That would make sense. One file could cause another files inode to be
removed from the cache when its full. CYG_SYNCMODE_IO_FILESYSTEM
should prevent this. 

> I still believe that it should work to use cyg_fs_lock to protect the
> filesystem during gc. Comments? 

With filesystem locking, yes, that should work.

> > You also seem to of missed icache_evict() which needs locking.
> > 
> ... the call from jffs2_umount.

Its also called from jffs2_iput().

        Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]