[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Killing JFFS under 2.2

On Fri, 28 Jul 2000, Alexander Larsson wrote:
> Yes, I've written that. But the original flash_erase_region can also
> sleep (as can any MTD call too):

Ok it is probably those flash acquire things that can screw up the
sequential log ordering. 

While one task acquires the lock and sleeps for the erase to complete,
another can enter the kernel, enter jffs, allocate a node to write, but
will be halted when it tries to do acquire. When the erase finishes and
releases the lock, there is a race between the task doing the erase to
actually write data somewhere, and the other task to do the same thing.

The result should be ok in any situation except the power-fail case where
the race would be noticeable.

This is a standard example of the extreme caution needed when hacking
filesystems I think :) 

In order to maintain log-ordering on flash without "holes", you need a
flash lock on a higher level - a partition-lock or filesystem-lock or
whatever you want to call it. A log-lock. Any operation that will
allocate/insert structures in the in-core representation and then do
something on the flash (or the other way around) need to assure atomicity
of those operations using a lock.

The safe_acquire locks are still necessary because you only need to
protect the partition with the log for multiple jffs paths, not the entire

So we need a new lock in an appropriate structure (the partition
structure) and lock/unlocks in the right places... 


> int
> flash_erase_region(kdev_t dev, __u32 offset, __u32 size)
> {
>  ...
> 	flash_safe_acquire(part);
> 	do {
> 		flash_init_erase(erase_start, size);
> 		while (flash_is_busy((flashptr)part->chip->start)) {
> 			current->state = TASK_INTERRUPTIBLE;
> 			current->timeout = jiffies + HZ / 2;
> 			schedule();
> 		}
> / Alex