[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JFFS2 is broken
> The problem is that JFFS2 tries to be a good guy and tries its hand at
> GC'ing dirty flash, _from within a write() system call_
That in itself is probably fine, write should only hold the inode lock
for that file
> Unfortunately, there is a problem with this approach. If write() cannot
> find space and now we refuse to GC inside the write and return with
> -ENOSPC, a lot of stock programs may break. I am returning -ENSPC
> because I just didn't take the time to figure out how to return 0, which
One thing you can do here is to wake the gc thread and sleep politely on it
> The only solution, that I think will work, is to find a way to block the
> write() to JFFS2 but allow kernel schedduling to go on. I really don't
Well there are two things there.
1. You could wake the GC and sleep on it using sleep/wakeup or
2. Profile the kernel and find out where it is tight looping. I can't
see any reason for tight loops except for the compression itself
so it suggests a code bug.
Finally within the compression loops you can check current->need_resched and
if it is set call schedule() to allow the compression to switch to other
tasks at the point it has used its time slice.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org