Re: Killing JFFS under 2.2

[Alexander Larsson <alex@xxxxxxx.se>]

On Fri, 28 Jul 2000, Bjorn Wesen wrote:

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

 That seems plausible.
 
> 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
> flash.
> 
> So we need a new lock in an appropriate structure (the partition
> structure) and lock/unlocks in the right places... 

The safe_acquire stuff has been removed from the MTD version (the calls
are there, but flash_safe_acquire is just an empty define). This is ok as
the underlying MTD device guarantee the correct locking (or whatever
concurrency handling needed) for flash read/write and erases.

But I think you're right that there need to be an filesystem-wide lock
that serializes writes to the log.

/ Alex